Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon RDS for PostgreSQL
Amazon RDS mendukung instans DB yang menjalankan beberapa versi PostgreSQL. Untuk daftar versi yang tersedia, lihat [Versi basis data PostgreSQL yang tersedia](PostgreSQL.Concepts.General.DBVersions.md).
Anda dapat membuat instance DB dan snapshot DB, point-in-time mengembalikan, dan membuat cadangan. Instans DB yang menjalankan PostgreSQL mendukung deployment Multi-AZ, replika baca, IOPS yang Tersedia, dan dapat dibuat di dalam cloud privat virtual (VPC). Anda juga dapat menggunakan Lapisan Soket Aman (SSL) untuk terhubung ke instans DB yang menjalankan PostgreSQL.
Sebelum membuat instans DB, selesaikan langkah-langkah di [Menyiapkan lingkungan Amazon RDS Anda](CHAP_SettingUp.md).
Anda dapat menggunakan aplikasi klien SQL standar apa pun untuk menjalankan perintah terhadap instans dari komputer klien. Aplikasi tersebut mencakup pgAdmin, alat pengembangan dan administrasi Sumber Terbuka yang populer untuk PostgreSQL, atau psql, utilitas baris perintah yang merupakan bagian dari instalasi PostgreSQL. Untuk memberikan pengalaman layanan terkelola, Amazon RDS tidak memberikan akses host ke instans DB. Hal tersebut juga membatasi akses ke prosedur dan tabel sistem tertentu yang membutuhkan hak istimewa tingkat lanjut. Amazon RDS mendukung akses ke basis data di instans DB menggunakan aplikasi klien SQL standar. Amazon RDS tidak mengizinkan akses host langsung ke instans DB dengan menggunakan Telnet atau Secure Shell (SSH).
Amazon RDS for PostgreSQL memenuhi banyak standar industri. Misalnya, Anda dapat menggunakan basis data Amazon RDS for PostgreSQL untuk membangun aplikasi yang sesuai dengan HIPAA dan untuk menyimpan informasi terkait perawatan kesehatan. Ini termasuk penyimpanan informasi kesehatan yang dilindungi (PHI) berdasarkan Perjanjian Rekanan Bisnis (BAA) lengkap dengan AWS. Amazon RDS for PostgreSQL juga memenuhi persyaratan keamanan Federal Risk and Authorization Management Program (FedRAMP). Amazon RDS for PostgreSQL telah menerima Otoritas Sementara FedRAMP Joint Authorization Board (JAB) untuk Beroperasi (P-ATO) di FedRAMP HIGH Baseline di Wilayah. AWS GovCloud (US) Untuk informasi selengkapnya tentang standar kepatuhan yang didukung, lihat [kepatuhan cloud AWS](https://aws.amazon.com/compliance/).
Untuk mengimpor data ke dalam instans DB, ikuti informasi di bagian [Mengimpor data ke PostgreSQL di Amazon RDS](PostgreSQL.Procedural.Importing.md).
**penting**
Jika Anda mengalami masalah dengan instans RDS untuk PostgreSQL DB, agen dukungan AWS Anda mungkin memerlukan informasi lebih lanjut tentang kesehatan database Anda. Tujuannya adalah untuk memastikan bahwa AWS Support mendapatkan informasi yang diperlukan sesegera mungkin.
Anda dapat menggunakan PG Collector untuk membantu mengumpulkan informasi database yang berharga dalam file HTML terkonsolidasi. Untuk informasi lebih lanjut tentang PG Collector, cara menjalankannya, dan cara mengunduh laporan HTML, lihat [PG Collector](https://github.com/awslabs/pg-collector).
Setelah berhasil diselesaikan, dan kecuali dinyatakan lain, skrip mengembalikan output dalam format HTML yang dapat dibaca. Skrip ini dirancang untuk mengecualikan data atau detail keamanan apa pun dari HTML yang mungkin membahayakan bisnis Anda. Skrip ini juga tidak melakukan modifikasi pada basis data Anda atau lingkungannya. Namun, jika Anda menemukan informasi apa pun dalam HTML yang tidak nyaman Anda bagikan, jangan ragu untuk menghapus informasi yang bermasalah sebelum mengunggah HTML. Jika HTML dapat diterima, unggah menggunakan bagian lampiran dalam detail kasus kasus dukungan Anda.
**Topics**
+ [Tugas manajemen umum untuk Amazon RDS for PostgreSQL](CHAP_PostgreSQL.CommonTasks.md)
+ [Menggunakan lingkungan Pratinjau Basis Data](working-with-the-database-preview-environment.md)
+ [Versi basis data PostgreSQL yang tersedia](PostgreSQL.Concepts.General.DBVersions.md)
+ [Memahami RDS untuk proses rilis inkremental PostgreSQL](PostgreSQL.Concepts.General.ReleaseProcess.md)
+ [Versi ekstensi PostgreSQL yang didukung](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
+ [Menggunakan fitur PostgreSQL yang didukung oleh Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ [Menghubungkan ke instans DB yang menjalankan mesin basis data PostgreSQL](USER_ConnectToPostgreSQLInstance.md)
+ [Mengamankan koneksi ke RDS for PostgreSQL dengan SSL/TLS](PostgreSQL.Concepts.General.Security.md)
+ [Menggunakan autentikasi Kerberos dengan Amazon RDS for PostgreSQL](postgresql-kerberos.md)
+ [Menggunakan server DNS kustom untuk akses jaringan keluar](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
+ [Upgrade RDS untuk mesin PostgreSQL DB](USER_UpgradeDBInstance.PostgreSQL.md)
+ [Meningkatkan versi mesin snapshot DB PostgreSQL](USER_UpgradeDBSnapshot.PostgreSQL.md)
+ [Menggunakan replika baca untuk Amazon RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md)
+ [Meningkatkan performa kueri untuk RDS for PostgreSQL dengan Amazon RDS Optimized Reads](USER_PostgreSQL.optimizedreads.md)
+ [Mengimpor data ke PostgreSQL di Amazon RDS](PostgreSQL.Procedural.Importing.md)
+ [Mengekspor data dari instans DB RDS for PostgreSQL ke Amazon S3](postgresql-s3-export.md)
+ [Memanggil AWS Lambda fungsi dari](PostgreSQL-Lambda.md)
+ [Tugas DBA umum untuk Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md)
+ [Menyetel dengan peristiwa tunggu di RDS for PostgreSQL](PostgreSQL.Tuning.md)
+ [DevOps](PostgreSQL.Tuning_proactive_insights.md)
+ [Menggunakan ekstensi PostgreSQL dengan Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)
+ [Bekerja dengan pembungkus data asing yang didukung untuk Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)
+ [Bekerja dengan Ekstensi Bahasa Tepercaya untuk PostgreSQL](PostgreSQL_trusted_language_extension.md)
# Tugas manajemen umum untuk Amazon RDS for PostgreSQL
Berikut adalah tugas manajemen umum yang Anda lakukan dengan instans DB Amazon RDS for PostgreSQL, dengan tautan ke dokumentasi yang relevan untuk setiap tugas.
| Area tugas | Dokumentasi terkait |
| --- | --- |
| **Menyiapkan Amazon RDS untuk penggunaan pertama kali** Sebelum Anda dapat membuat instans DB, pastikan untuk menyelesaikan beberapa prasyarat. Misalnya, instans DB dibuat secara default dengan firewall yang mencegah akses ke instans DB tersebut. Oleh karena itu, Anda harus membuat grup keamanan dengan alamat IP dan konfigurasi jaringan yang benar untuk mengakses instans DB. | [Menyiapkan lingkungan Amazon RDS Anda](CHAP_SettingUp.md) |
| **Memahami instans DB Amazon RDS** Jika membuat instans DB untuk tujuan produksi, Anda harus memahami cara kerja kelas instans, jenis penyimpanan, dan pekerjaan IOPS yang Tersedia di Amazon RDS. | [ DB](Concepts.DBInstanceClass.md) [Jenis penyimpanan Amazon RDS](CHAP_Storage.md#Concepts.Storage) [Penyimpanan SSD IOPS yang Tersedia](CHAP_Storage.md#USER_PIOPS) |
| **Menemukan versi PostgreSQL yang tersedia** Amazon RDS mendukung beberapa versi PostgreSQL. | [Versi basis data PostgreSQL yang tersedia](PostgreSQL.Concepts.General.DBVersions.md) |
| **Menyiapkan ketersediaan tinggi dan dukungan failover** Instans DB produksi harus menggunakan deployment Multi-AZ. Deployment Multi-AZ memberikan peningkatan ketersediaan, durabilitas data, dan toleransi kesalahan untuk instans DB. | [Mengonfigurasi dan mengelola penyebaran Multi-AZ untuk Amazon RDS](Concepts.MultiAZ.md) |
| **Memahami jaringan Amazon Virtual Private Cloud (VPC)** Jika AWS akun Anda memiliki VPC default, maka instans DB Anda secara otomatis dibuat di dalam VPC default. Dalam beberapa kasus, akun Anda mungkin tidak memiliki VPC default, dan Anda mungkin menginginkan instans DB di VPC. Dalam kasus ini, buat grup VPC dan subnet sebelum Anda membuat instans DB. | [Menggunakan instans DB di VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **Mengimpor data ke Amazon RDS PostgreSQL** Anda dapat menggunakan berbagai alat untuk mengimpor data ke dalam instans DB PostgreSQL di Amazon RDS. | [Mengimpor data ke PostgreSQL di Amazon RDS](PostgreSQL.Procedural.Importing.md) |
| **Menyiapkan replika baca hanya baca (primer dan siaga)** RDS untuk PostgreSQL mendukung replika baca di Wilayah yang AWS sama dan di Wilayah yang berbeda dari instance utama. AWS | [Menggunakan replika baca instans DB](USER_ReadRepl.md) [Menggunakan replika baca untuk Amazon RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md) [Membuat replika baca di tempat yang berbeda Wilayah AWS](USER_ReadRepl.XRgn.md) |
| **Memahami grup keamanan** Secara default, instans DB dibuat dengan firewall yang mencegah akses ke instans tersebut. Untuk menyediakan akses melalui firewall tersebut, edit aturan masuk untuk grup keamanan VPC yang terkait dengan VPC yang meng-hosting instans DB. | [Mengontrol akses dengan grup keamanan](Overview.RDSSecurityGroups.md) |
| **Menyiapkan grup parameter dan fitur** Untuk mengubah parameter default instans DB Anda, buat grup parameter DB kustom dan ubah pengaturannya. Jika melakukannya sebelum membuat instans DB, Anda dapat memilih grup parameter DB kustom ketika membuat instans. | [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md) |
| **Menghubungkan ke sampel instans DB PostgreSQL** Setelah membuat grup keamanan dan mengaitkannya ke instans DB, Anda dapat menghubungkan ke instans DB menggunakan aplikasi klien SQL standar seperti `psql` atau `pgAdmin`. | [Menghubungkan ke instans DB yang menjalankan mesin basis data PostgreSQL](USER_ConnectToPostgreSQLInstance.md) [Menggunakan SSL dengan instans DB PostgreSQL](PostgreSQL.Concepts.General.SSL.md) |
| **Mencadangkan dan memulihkan instans DB** Anda dapat mengonfigurasi instans DB Anda untuk melakukan pencadangan otomatis, atau melakukan snapshot manual, kemudian memulihkan instans dari cadangan atau snapshot. | [Mencadangkan, memulihkan, dan mengekspor data](CHAP_CommonTasks.BackupRestore.md) |
| **Memantau performa instans DB** Anda dapat memantau instans PostgreSQL DB dengan menggunakan metrik CloudWatch Amazon RDS, peristiwa, dan pemantauan yang disempurnakan. | [Melihat metrik di konsol Amazon RDS](USER_Monitoring.md) [Melihat RDS acara Amazon](USER_ListEvents.md) |
| **Meningkatkan versi basis data PostgreSQL** Anda dapat melakukan peningkatan versi utama dan minor untuk instans DB PostgreSQL Anda. | [Upgrade RDS untuk mesin PostgreSQL DB](USER_UpgradeDBInstance.PostgreSQL.md) [Memilih versi utama untuk RDS untuk upgrade PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) |
| **Menggunakan file log** Anda dapat mengakses file log untuk instans DB PostgreSQL Anda. | [](USER_LogAccess.Concepts.PostgreSQL.md) |
| **Memahami praktik terbaik untuk instans DB PostgreSQL** Temukan beberapa praktik terbaik untuk menggunakan PostgreSQL di Amazon RDS. | [Praktik terbaik untuk menggunakan PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL) |
Berikut ini adalah daftar bagian lain dalam panduan ini yang dapat membantu Anda memahami dan menggunakan fitur penting RDS for PostgreSQL:
+ [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Mengontrol akses pengguna ke basis data PostgreSQLMengontrol akses pengguna ke PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Bekerja dengan parameter pada instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
+ [Memahami mekanisme pencatatan log yang didukung oleh RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Menggunakan server DNS kustom untuk akses jaringan keluar](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
# Menggunakan lingkungan Pratinjau Basis Data
Komunitas PostgreSQL terus merilis versi dan ekstensi PostgreSQL baru, termasuk versi beta. Hal ini memberi pengguna PostgreSQL kesempatan untuk mencoba versi PostgreSQL baru lebih awal. Untuk mempelajari selengkapnya tentang proses rilis beta komunitas PostgreSQL, lihat [Beta Information](https://www.postgresql.org/developer/beta/) dalam dokumentasi PostgreSQL. Demikian pula, Amazon RDS membuat versi beta PostgreSQL tertentu tersedia sebagai rilis Pratinjau. Ini memungkinkan Anda membuat instans DB menggunakan versi Pratinjau dan menguji fitur-fiturnya di Lingkungan Pratinjau Basis Data.
Instans DB RDS untuk PostgreSQL di Lingkungan Pratinjau Basis Data secara fungsional mirip dengan instans RDS for PostgreSQL lainnya. Namun, Anda tidak dapat menggunakan versi Pratinjau untuk produksi.
Perhatikan batasan penting berikut:
+ Semua instans DB dihapus pada 60 hari setelah pembuatannya, bersama dengan semua cadangan dan snapshot.
+ Anda hanya dapat membuat instans DB dalam Cloud Privat Virtual (VPC) berdasarkan layanan Amazon VPC.
+ Anda hanya dapat menggunakan SSD Tujuan Umum dan penyimpanan SSD IOPS yang Tersedia.
+ Anda tidak bisa mendapatkan bantuan dari AWS Support dengan instans DB. [Sebagai gantinya, Anda dapat memposting pertanyaan Anda ke komunitas Tanya Jawab yang AWS dikelola, Re:post.AWS](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service)
+ Anda tidak dapat menyalin snapshot instans DB ke lingkungan produksi.
Opsi berikut didukung oleh Pratinjau.
+ Anda dapat membuat instans DB hanya menggunakan jenis instans M6i, R6i, M6g, M5, T3, R6g, dan R5. Untuk informasi selengkapnya tentang kelas instans RDS, lihat [ DB](Concepts.DBInstanceClass.md).
+ Anda dapat menggunakan deployment AZ tunggal dan multi-AZ.
+ Anda dapat menggunakan pembuangan PostgreSQL standar dan memuat fungsi untuk mengekspor basis data dari atau mengimpor basis data ke Lingkungan Pratinjau Basis Data.
**Topics**
+ [Fitur yang tidak didukung di lingkungan Pratinjau Basis Data](#preview-environment-exclusions)
+ [PostgreSQL versi 17 di lingkungan Pratinjau Database](#PostgreSQL.Concepts.General.version17)
+ [Membuat instans DB baru di Lingkungan Pratinjau Basis Data](create-db-instance-in-preview-environment.md)
## Fitur yang tidak didukung di lingkungan Pratinjau Basis Data
Fitur berikut ini tidak tersedia di lingkungan Pratinjau Basis Data:
+ Salinan snapshot lintas Wilayah
+ Replika baca lintas Wilayah
## PostgreSQL versi 17 di lingkungan Pratinjau Database
**catatan**
Ini adalah dokumentasi pratinjau untuk Amazon RDS PostgreSQL versi 17. Dokumentasi ini dapat berubah.
PostgreSQL versi 17.0 sekarang tersedia di lingkungan Amazon RDS Database Preview. [PostgreSQL versi 17.0 berisi beberapa perbaikan yang dijelaskan dalam dokumentasi PostgreSQL berikut, PostgreSQL 17 Dirilis\$1](https://www.postgresql.org/docs/17/release-17.html)
Untuk informasi tentang Lingkungan Pratinjau Basis Data, lihat [Menggunakan lingkungan Pratinjau Basis Data](#working-with-the-database-preview-environment). Untuk mengakses Lingkungan Pratinjau dari konsol, pilih [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
# Membuat instans DB baru di Lingkungan Pratinjau Basis Data
Gunakan prosedur berikut untuk membuat instans DB di lingkungan pratinjau.
**Untuk membuat instans DB di lingkungan Pratinjau Basis Data**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Dasbor** dari panel navigasi.
1. Di halaman Dasbor, temukan bagian **Lingkungan Pratinjau Basis Data**, seperti yang ditunjukkan pada gambar berikut.
![\[Bagian lingkungan pratinjau dengan tautan yang ditampilkan di konsol RDS, Dasbor\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Anda dapat langsung menuju [Lingkungan pratinjau basis data](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Sebelum dapat melanjutkan, Anda harus mengakui dan menerima batasan.
![\[Dialog batasan lingkungan pratinjau\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Untuk membuat instans DB RDS for PostgreSQL, ikuti proses yang sama seperti untuk membuat instans DB Amazon RDS apa pun. Untuk informasi lebih lanjut, lihat prosedur [Konsol](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) di [Membuat instans DB](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
Untuk membuat instans di Lingkungan Pratinjau Basis Data menggunakan API RDS atau AWS CLI, gunakan titik akhir berikut.
```
rds-preview.us-east-2.amazonaws.com
```
# Versi basis data PostgreSQL yang tersedia
Amazon RDS mendukung instans DB yang menjalankan beberapa edisi PostgreSQL. Anda dapat menentukan versi PostgreSQL mana pun yang saat ini tersedia ketika membuat instans DB baru. Anda dapat menentukan versi utama (seperti PostgreSQL 14) dan versi minor yang tersedia untuk versi utama tertentu. Jika tidak ada versi yang ditentukan, Amazon RDS menetapkan ke versi yang tersedia secara default, biasanya versi terbaru. Jika versi utama ditentukan tetapi versi minor tidak, Amazon RDS menetapkan default ke rilis versi utama terbaru yang telah Anda tentukan.
Untuk melihat daftar versi yang tersedia, serta default untuk instance DB yang baru dibuat, gunakan perintah. [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI Misalnya, untuk menampilkan versi mesin PostgreSQL default, gunakan perintah berikut:
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Untuk detail tentang versi PostgreSQL yang didukung di Amazon RDS, lihat [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html). Anda juga dapat melihat informasi tentang tanggal dukungan untuk versi mesin utama dengan menjalankan AWS CLI perintah [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) atau dengan menggunakan operasi [Describe DBMajor EngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS API.
Jika Anda belum siap untuk meningkatkan secara manual ke versi mesin utama baru sebelum tanggal dukungan standar berakhir RDS, Amazon RDS akan secara otomatis mendaftarkan database Anda di Amazon RDS Extended Support setelah RDS berakhir pada tanggal dukungan standar. Kemudian, Anda dapat terus menjalankan RDS untuk PostgreSQL versi 11 dan lebih tinggi. Untuk informasi selengkapnya, lihat [](extended-support.md) dan [Harga Amazon RDS](https://aws.amazon.com/rds/pricing/).
## Versi usang untuk Amazon RDS for PostgreSQL
Perhatikan versi usang berikut ini:
+ RDS untuk PostgreSQL 10 tidak digunakan lagi pada Februari 2023.
+ RDS untuk PostgreSQL 9.6 tidak digunakan lagi pada Maret 2022.
+ RDS untuk PostgreSQL 9.5 tidak digunakan lagi pada Maret 2021.
[Untuk mempelajari selengkapnya tentang kebijakan penghentian RDS untuk PostgreSQL, lihat Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/) Untuk informasi selengkapnya tentang versi PostgreSQL, lihat [Versioning Policy](https://www.postgresql.org/support/versioning/) di dokumentasi PostgreSQL.
# Memahami RDS untuk proses rilis inkremental PostgreSQL
RDS untuk PostgreSQL memberikan perbaikan keamanan, peningkatan kinerja, dan fitur baru melalui rilis inkremental sambil mempertahankan kompatibilitas versi minor. Rilis ini diberi label sebagai R1, R2, R3, dan sebagainya.
**Konvensi penamaan versi rilis**
+ R1 adalah rilis awal dari versi minor. Kadang-kadang termasuk fitur baru, ekstensi, atau upgrade ke ekstensi yang ada.
+ Versi rilis berikutnya (R2, R3, dan yang lebih baru) meliputi:
+ Pembaruan keamanan
+ Peningkatan kinerja
+ Perbaikan bug
+ Pembaruan ekstensi
## Keuntungan RDS untuk proses rilis inkremental PostgreSQL
Proses rilis inkremental memberikan keuntungan sebagai berikut:
+ Adopsi cepat rilis komunitas PostgreSQL baru sambil secara terpisah mengelola peningkatan khusus RDS melalui rilis berikutnya. Ini merampingkan proses rilis dan memastikan pengiriman pembaruan penting yang lebih cepat.
+ Akses ke perbaikan bug, fitur baru, pembaruan keamanan, dan pembaruan ekstensi sambil mempertahankan kompatibilitas dengan versi minor PostgreSQL.
## Mengelola pembaruan rilis
Amazon RDS memberi tahu Anda tentang rilis inkremental baru melalui tindakan pemeliharaan yang tertunda di. Konsol Manajemen AWS Anda dapat memperbarui database Anda menggunakan salah satu metode berikut:
+ Aktifkan pembaruan otomatis selama jendela pemeliharaan terjadwal.
+ Terapkan pembaruan secara manual melalui tindakan pemeliharaan yang tertunda.
+ Gunakan Blue/Green penerapan dengan replikasi fisik untuk meminimalkan waktu henti. Untuk informasi selengkapnya, lihat [Penerapan Biru/Hijau mendukung peningkatan versi minor untuk RDS](https://aws.amazon.com/about-aws/whats-new/2024/11/rds-blue-green-deployments-upgrade-rds-postgresql/) untuk PostgreSQL.
Sebelum memperbarui database Anda, pertimbangkan poin-poin penting berikut:
+ Reboot basis data diperlukan untuk pembaruan kecuali Anda menggunakan penerapan Biru/Hijau dengan replikasi fisik.
+ Beberapa rilis inkremental adalah wajib, terutama yang mencakup perbaikan keamanan.
Untuk informasi selengkapnya tentang memperbarui instans instans Amazon RDS DB, lihat [Ekstensi terpercaya PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted) dan [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html).
# Versi ekstensi PostgreSQL yang didukung
RDS for PostgreSQL mendukung banyak ekstensi PostgreSQL. Komunitas PostgreSQL terkadang mengacu pada berbagai modul ini. Ekstensi memperluas fungsionalitas yang disediakan oleh mesin PostgreSQL. Anda dapat menemukan daftar ekstensi yang didukung oleh Amazon RDS di grup parameter DB default untuk versi PostgreSQL tersebut. Anda juga dapat melihat daftar ekstensi saat ini menggunakan `psql` dengan menampilkan parameter `rds.extensions` seperti pada contoh berikut.
```
SHOW rds.extensions;
```
**catatan**
Parameter yang ditambahkan dalam rilis versi minor mungkin ditampilkan secara tidak akurat saat menggunakan parameter `rds.extensions` di `psql`.
Pada RDS for PostgreSQL 13, ekstensi tertentu dapat diinstal oleh pengguna basis data selain `rds_superuser`. Ini dikenal sebagai *ekstensi tepercaya*. Untuk mempelajari selengkapnya, lihat [Ekstensi terpercaya PostgreSQL](#PostgreSQL.Concepts.General.Extensions.Trusted).
Versi RDS for PostgreSQL tertentu mendukung parameter `rds.allowed_extensions`. Parameter ini memungkinkan `rds_superuser` membatasi ekstensi yang dapat diinstal di instans DB RDS for PostgreSQL. Untuk informasi selengkapnya, lihat [Membatasi penginstalan ekstensi PostgreSQL](#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Untuk daftar ekstensi dan versi PostgreSQL yang didukung oleh setiap versi RDS for PostgreSQL yang tersedia, see [Ekstensi PostgreSQL yang didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) di *Catatan Rilis Amazon RDS for PostgreSQL*.
## Membatasi penginstalan ekstensi PostgreSQL
Anda dapat membatasi ekstensi yang dapat diinstal pada instans DB PostgreSQL. Secara default, parameter ini tidak ditetapkan, jadi ekstensi apa pun yang didukung dapat ditambahkan jika pengguna memiliki izin untuk melakukannya. Untuk melakukannya, tetapkan parameter `rds.allowed_extensions` ke string nama ekstensi yang dipisahkan koma. Dengan menambahkan daftar ekstensi ke parameter ini, Anda secara eksplisit mengidentifikasi ekstensi yang dapat digunakan oleh instans DB RDS for PostgreSQL Anda. Hanya ekstensi ini yang kemudian dapat diinstal di instans DB PostgreSQL.
String default untuk parameter `rds.allowed_extensions` adalah '\$1', yang berarti ekstensi apa pun yang tersedia untuk versi mesin dapat diinstal. Mengubah parameter `rds.allowed_extensions` tidak memerlukan mulai ulang basis data karena parameter tersebut bersifat dinamis.
Mesin instans DB PostgreSQL harus merupakan salah satu versi berikut agar Anda dapat menggunakan parameter `rds.allowed_extensions`:
+ Semua versi PostgreSQL 16
+ PostgreSQL 15 dan semua versi yang lebih tinggi
+ PostgreSQL 14 dan semua versi yang lebih tinggi
+ PostgreSQL 13.3 dan versi minor yang lebih tinggi
+ PostgreSQL 12.7 dan versi minor yang lebih tinggi
Untuk melihat instalasi ekstensi yang diizinkan, gunakan perintah psql berikut.
```
postgres=> SHOW rds.allowed_extensions;
rds.allowed_extensions
------------------------
*
```
Jika ekstensi telah diinstal tetapi sebelumnya tidak dimasukkan dalam daftar di parameter `rds.allowed_extensions`, ekstensi tersebut masih dapat digunakan secara normal, dan perintah seperti `ALTER EXTENSION` dan `DROP EXTENSION` akan terus berfungsi. Namun, setelah ekstensi dibatasi, perintah `CREATE EXTENSION` untuk ekstensi yang dibatasi akan gagal.
Instalasi dependensi ekstensi dengan `CREATE EXTENSION CASCADE` juga dibatasi. Ekstensi dan dependensinya harus ditentukan dalam `rds.allowed_extensions`. Jika instalasi dependensi ekstensi gagal, seluruh pernyataan `CREATE EXTENSION CASCADE` akan gagal.
Jika ekstensi tidak disertakan dengan parameter `rds.allowed_extensions`, Anda akan melihat kesalahan seperti berikut jika mencoba menginstalnya.
```
ERROR: permission denied to create extension "extension-name"
HINT: This extension is not specified in "rds.allowed_extensions".
```
## Ekstensi terpercaya PostgreSQL
Untuk menginstal sebagian besar ekstensi PostgreSQL membutuhkan hak istimewa `rds_superuser`. PostgreSQL 13 memperkenalkan ekstensi tepercaya, yang mengurangi kebutuhan untuk memberikan hak istimewa `rds_superuser` kepada pengguna biasa. Dengan fitur ini, pengguna dapat menginstal banyak ekstensi jika mereka memiliki hak istimewa `CREATE` pada basis data saat ini alih-alih memerlukan peran `rds_superuser`. Untuk informasi selengkapnya, lihat perintah SQL [CREATE EXTENSION](https://www.postgresql.org/docs/current/sql-createextension.html) di dokumentasi PostgreSQL.
Berikut ini daftar ekstensi yang dapat diinstal oleh pengguna yang memiliki hak istimewa `CREATE` pada basis data saat ini dan tidak memerlukan peran `rds_superuser`:
+ bool\$1plperl
+ [btree\$1gin](http://www.postgresql.org/docs/current/btree-gin.html)
+ [btree\$1gist](http://www.postgresql.org/docs/current/btree-gist.html)
+ [citext ](http://www.postgresql.org/docs/current/citext.html)
+ [cube ](http://www.postgresql.org/docs/current/cube.html)
+ [ dict\$1int ](http://www.postgresql.org/docs/current/dict-int.html)
+ [fuzzystrmatch](http://www.postgresql.org/docs/current/fuzzystrmatch.html)
+ [hstore](http://www.postgresql.org/docs/current/hstore.html)
+ [ intarray](http://www.postgresql.org/docs/current/intarray.html)
+ [isn](http://www.postgresql.org/docs/current/isn.html)
+ jsonb\$1plperl
+ [ltree ](http://www.postgresql.org/docs/current/ltree.html)
+ [pg\$1trgm](http://www.postgresql.org/docs/current/pgtrgm.html)
+ [pgcrypto](http://www.postgresql.org/docs/current/pgcrypto.html)
+ [plperl](https://www.postgresql.org/docs/current/plperl.html)
+ [plpgsql](https://www.postgresql.org/docs/current/plpgsql.html)
+ [pltcl](https://www.postgresql.org/docs/current/pltcl-overview.html)
+ [tablefunc](http://www.postgresql.org/docs/current/tablefunc.html)
+ [tsm\$1system\$1rows](https://www.postgresql.org/docs/current/tsm-system-rows.html)
+ [tsm\$1system\$1time](https://www.postgresql.org/docs/current/tsm-system-time.html)
+ [unaccent](http://www.postgresql.org/docs/current/unaccent.html)
+ [uuid-ossp](http://www.postgresql.org/docs/current/uuid-ossp.html)
Untuk daftar ekstensi dan versi PostgreSQL yang didukung oleh setiap versi RDS for PostgreSQL yang tersedia, see [Ekstensi PostgreSQL yang didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) di *Catatan Rilis Amazon RDS for PostgreSQL*.
# Menggunakan fitur PostgreSQL yang didukung oleh Amazon RDS for PostgreSQL
Amazon RDS for PostgreSQL mendukung banyak fitur PostgreSQL yang paling umum. Misalnya, PostgreSQL memiliki fitur autovacuum yang melakukan pemeliharaan rutin pada basis data. Fitur autovacuum aktif secara default. Meskipun Anda dapat menonaktifkan fitur ini, kami sangat menyarankan Anda untuk tetap mengaktifkannya. Memahami fitur ini dan apa yang dapat Anda lakukan untuk memastikannya berfungsi sebagaimana mestinya adalah tugas dasar setiap DBA. Untuk informasi selengkapnya tentang autovacuum, lihat [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Untuk mempelajari lebih lanjut tentang tugas DBA umum lainnya, [Tugas DBA umum untuk Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md).
RDS for PostgreSQL juga mendukung ekstensi yang menambahkan fungsionalitas penting pada instans DB. Misalnya, Anda dapat menggunakan ekstensi PostGIS untuk bekerja dengan data spasial, atau menggunakan ekstensi pg\$1cron untuk menjadwalkan pemeliharaan dari dalam instans. Untuk informasi selengkapnya tentang ekstensi PostgreSQL, lihat [Menggunakan ekstensi PostgreSQL dengan Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md).
Pembungkus data asing adalah jenis ekstensi spesifik yang dirancang agar instans DB RDS for PostgreSQL Anda bekerja dengan basis data komersial atau jenis data lainnya. Untuk informasi selengkapnya tentang pembungkus data asing yang didukung untuk RDS for PostgreSQL, lihat [Bekerja dengan pembungkus data asing yang didukung untuk Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
Berikut ini, Anda dapat menemukan informasi tentang beberapa fitur lain yang didukung oleh RDS for PostgreSQL.
**Topics**
+ [Jenis data kustom dan enumerasi dengan RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md)
+ [Pemicu peristiwa untuk RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md)
+ [Halaman besar untuk RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)
+ [Melakukan replikasi logis untuk Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)
+ [Mengkonfigurasi otentikasi IAM untuk koneksi replikasi logis](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md)
+ [Disk RAM untuk stats\$1temp\$1directory](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md)
+ [Tablespace untuk RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md)
+ [Kolasi RDS for PostgreSQL untuk EBCDIC dan migrasi mainframe lainnya](PostgreSQL.Collations.mainframe.migration.md)
+ [Mengelola sinkronisasi slot logis untuk RDS untuk PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md)
# Jenis data kustom dan enumerasi dengan RDS for PostgreSQL
PostgreSQL mendukung pembuatan jenis data kustom dan dapat digunakan dengan enumerasi. Untuk informasi selengkapnya tentang membuat dan bekerja dengan enumerasi serta jenis data lainnya, lihat [Enumerated types](https://www.postgresql.org/docs/14/datatype-enum.html) dalam dokumentasi PostgreSQL.
Berikut ini adalah contoh pembuatan suatu jenis sebagai enumerasi lalu memasukkan nilai ke dalam tabel.
```
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)
```
# Pemicu peristiwa untuk RDS for PostgreSQL
Semua versi PostgreSQL saat ini mendukung pemicu peristiwa, dan begitu juga semua versi RDS yang tersedia untuk PostgreSQL. Anda dapat menggunakan akun pengguna utama (default, `postgres`) untuk membuat, memodifikasi, mengganti nama, dan menghapus pemicu peristiwa. Pemicu peristiwa berada di tingkat instans DB, sehingga dapat diterapkan ke semua basis data pada sebuah instans.
Misalnya, kode berikut membuat pemicu peristiwa yang mencetak pengguna saat ini di akhir setiap perintah bahasa definisi data (DDL).
```
CREATE OR REPLACE FUNCTION raise_notice_func()
RETURNS event_trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;
CREATE EVENT TRIGGER event_trigger_1
ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();
```
Untuk informasi lebih lanjut tentang pemicu peristiwa PostgreSQL, lihat [Event triggers](https://www.postgresql.org/docs/current/static/event-triggers.html) dalam dokumentasi PostgreSQL.
Ada beberapa batasan dalam penggunaan pemicu peristiwa PostgreSQL di Amazon RDS. Hal ini mencakup:
+ Anda tidak dapat membuat pemicu peristiwa pada replika baca. Namun, Anda dapat membuat pemicu peristiwa di sumber replika baca. Pemicu peristiwa kemudian disalin ke replika baca. Pemicu peristiwa pada replika baca tidak diaktifkan pada replika baca saat perubahan didorong dari sumber. Namun, jika replika baca dipromosikan, pemicu peristiwa yang ada aktif saat operasi basis data terjadi.
+ Untuk melakukan peningkatan versi utama ke instans DB PostgreSQL yang menggunakan pemicu peristiwa, hapus pemicu peristiwa sebelum meningkatkan instans tersebut.
# Halaman besar untuk RDS for PostgreSQL
*Halaman besar* adalah fitur manajemen memori yang mengurangi overhead saat instans DB menangani potongan besar memori yang berdekatan, seperti yang digunakan oleh buffer bersama. Fitur PostgreSQL ini didukung oleh semua versi RDS for PostgreSQL yang tersedia saat ini. Anda mengalokasikan halaman besar untuk aplikasi Anda menggunakan panggilan ke memori bersama `mmap` atau `SYSV`. RDS for PostgreSQL mendukung ukuran halaman 4-KB dan 2-MB.
Anda dapat mengaktifkan atau menonaktifkan halaman besar dengan mengubah nilai parameter `huge_pages`. Fitur ini diaktifkan secara default untuk semua kelas instans DB selain kelas instans DB mikro, kecil, dan menengah.
RDS for PostgreSQL menggunakan halaman besar berdasarkan memori bersama yang tersedia. Jika instans DB tidak dapat menggunakan halaman besar karena batasan memori bersama, Amazon RDS mencegah dimulainya instans DB. Dalam kasus ini, Amazon RDS mengatur status instans DB ke parameter yang tidak kompatibel. Jika ini terjadi, Anda dapat mengatur parameter `huge_pages` ke `off` agar Amazon RDS dapat memulai instans DB.
Parameter `shared_buffers` adalah kunci untuk mengatur kumpulan memori bersama yang diperlukan untuk menggunakan halaman besar. Nilai default untuk parameter `shared_buffers` menggunakan basis data parameter makro. Makro ini mengatur persentase dari total 8 KB halaman yang tersedia untuk memori instans DB. Saat Anda menggunakan halaman besar, halaman tersebut berada dengan halaman besar. Amazon RDS menempatkan instans DB ke dalam status parameter yang tidak kompatibel jika parameter memori bersama diatur untuk memerlukan lebih dari 90 persen memori instans DB.
Untuk mempelajari lebih lanjut tentang manajemen memori PostgreSQL, lihat [Resource Consumption](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) dalam dokumentasi PostgreSQL.
# Melakukan replikasi logis untuk Amazon RDS for PostgreSQL
Dimulai dengan versi 10.4, RDS for PostgreSQL mendukung publikasi dan langganan sintaks yang diperkenalkan di PostgreSQL 10. Untuk mempelajari selengkapnya, lihat [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) dalam dokumentasi PostgreSQL.
**catatan**
Selain fitur replikasi logis PostgreSQL asli yang diperkenalkan di PostgreSQL 10, RDS for PostgreSQL juga mendukung ekstensi `pglogical`. Untuk informasi selengkapnya, lihat [Menggunakan pglogical untuk menyinkronkan data di seluruh instans](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Berikut ini, Anda dapat menemukan informasi tentang pengaturan replikasi logis untuk instans DB RDS for PostgreSQL.
**Topics**
+ [Memahami replikasi logis dan decoding logis](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding)
+ [Menggunakan slot replikasi logis](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots)
+ [Mereplikasi data tingkat tabel menggunakan replikasi logis](#PostgreSQL.Concepts.LogicalReplication.Tables)
## Memahami replikasi logis dan decoding logis
RDS for PostgreSQL mendukung streaming write-ahead log (WAL) menggunakan slot replikasi logis PostgreSQL. Penggunaan decoding logis juga didukung. Anda dapat menyiapkan slot replikasi logis pada instans Anda dan mengalirkan perubahan basis data melalui slot ini ke klien seperti `pg_recvlogical`. Anda membuat slot replikasi logis di tingkat basis data, dan slot tersebut mendukung koneksi replikasi ke satu basis data.
Klien yang paling umum untuk replikasi logis PostgreSQL AWS Database Migration Service adalah atau host yang dikelola khusus pada instans Amazon EC2. Slot replikasi logis tidak memiliki informasi tentang penerima aliran. Selain itu, target tidak perlu merupakan basis data replika. Jika Anda menyiapkan slot replikasi logis dan tidak membaca dari slot, data dapat ditulis dan mengisi penyimpanan instans DB Anda dengan cepat.
Anda mengaktifkan replikasi logis PostgreSQL dan decoding logis untuk Amazon RDS dengan parameter, jenis koneksi replikasi, dan peran keamanan. Klien untuk decoding logis dapat berupa klien yang dapat membuat koneksi replikasi ke basis data pada instans DB PostgreSQL.
**Cara mengaktifkan decoding logis untuk instans DB RDS for PostgreSQL**
1. Pastikan akun pengguna yang Anda gunakan memiliki peran berikut:
+ Peran `rds_superuser` agar Anda dapat mengaktifkan replikasi logis
+ Peran `rds_replication` untuk memberikan izin guna mengelola slot logis dan mengalirkan data menggunakan slot logis
1. Atur parameter statis `rds.logical_replication` ke 1. Sebagai bagian dari penerapan parameter ini, atur juga parameter`wal_level`, `max_wal_senders`, `max_replication_slots`, dan `max_connections`. Perubahan parameter ini dapat meningkatkan pembuatan WAL, jadi atur parameter `rds.logical_replication` hanya saat Anda menggunakan slot logis.
1. Boot ulang instans DB agar parameter `rds.logical_replication` statis berlaku.
1. Buat slot replikasi logis sebagaimana dijelaskan di bagian selanjutnya. Proses ini mengharuskan Anda menentukan plugin decoding. Saat ini, RDS for PostgreSQL mendukung plugin output test\$1decoding dan wal2json yang dikirimkan dengan PostgreSQL.
Untuk informasi selengkapnya tentang decoding logis PostgreSQL, lihat [dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html).
## Menggunakan slot replikasi logis
Anda dapat menggunakan perintah SQL untuk bekerja dengan slot logis. Misalnya, perintah berikut membuat slot logis bernama `test_slot` menggunakan plugin output `test_decoding` PostgreSQL default.
```
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
```
Untuk membuat daftar slot logis, gunakan perintah berikut.
```
SELECT * FROM pg_replication_slots;
```
Untuk membatalkan daftar slot logis, gunakan perintah berikut.
```
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)
```
Untuk contoh selengkapnya tentang bekerja dengan slot replikasi logis, lihat [Logical decoding examples](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) dalam dokumentasi PostgreSQL.
Setelah Anda membuat slot replikasi logis, Anda dapat memulai pengaliran. Contoh berikut menunjukkan bagaimana decoding logis dikontrol melalui protokol replikasi streaming. Contoh ini menggunakan program pg\$1recvlogical, yang termasuk dalam distribusi PostgreSQL. Untuk melakukan hal ini, autentikasi klien perlu disiapkan untuk memungkinkan koneksi replikasi.
```
pg_recvlogical -d postgres --slot test_slot -U postgres
--host -instance-name.111122223333.aws-region.rds.amazonaws.com
-f - --start
```
Untuk melihat konten tampilan `pg_replication_origin_status`, kueri fungsi `pg_show_replication_origin_status`.
```
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)
```
## Mereplikasi data tingkat tabel menggunakan replikasi logis
Anda dapat menggunakan replikasi logis untuk mereplikasi data dari tabel sumber untuk menargetkan tabel di RDS untuk PostgreSQL. Replikasi logis pertama melakukan pemuatan awal data yang ada dari tabel sumber dan kemudian terus mereplikasi perubahan yang sedang berlangsung.
1.
**Buat tabel sumber**
Connect ke database sumber di RDS Anda untuk PostgreSQL DB instance:
```
source=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
1.
**Masukkan data ke dalam tabel sumber**
```
source=> INSERT INTO testtab VALUES (generate_series(1,1000));
INSERT 0 1000
```
1.
**Buat publikasi untuk tabel sumber**
+ Buat publikasi untuk tabel sumber:
```
source=> CREATE PUBLICATION testpub FOR TABLE testtab;
CREATE PUBLICATION
```
+ Gunakan kueri SELECT untuk memverifikasi detail publikasi yang dibuat:
```
source=> SELECT * FROM pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
--------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
115069 | testpub | 16395 | f | t | t | t | t | f
(1 row)
```
+ Verifikasi bahwa tabel sumber ditambahkan ke publikasi:
```
source=> SELECT * FROM pg_publication_tables;
pubname | schemaname | tablename
---------+------------+-----------
testpub | public | testtab
(1 rows)
```
+ Untuk mereplikasi semua tabel dalam database, gunakan:
```
CREATE PUBLICATION testpub FOR ALL TABLES;
```
+ Jika publikasi sudah dibuat untuk tabel individual dan Anda perlu menambahkan tabel baru, Anda dapat menjalankan kueri di bawah ini untuk menambahkan tabel baru ke publikasi yang ada:
```
ALTER PUBLICATION add table ;
```
1.
**Connect ke database target dan buat tabel target**
+ Connect ke database target dalam instans DB target. Buat tabel target dengan nama yang sama dengan tabel sumber:
```
target=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
+ Pastikan tidak ada data yang ada di tabel target dengan menjalankan kueri SELECT pada tabel target:
```
target=> SELECT count(*) FROM testtab;
count
-------
0
(1 row)
```
1.
**Membuat dan memverifikasi langganan di database target**
+ Buat langganan di database target:
```
target=> CREATE SUBSCRIPTION testsub
CONNECTION 'host= port=5432 dbname= user= password='
PUBLICATION testpub;
NOTICE: Created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
+ Gunakan kueri SELECT untuk memverifikasi bahwa langganan diaktifkan:
```
target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16434 | testsub | t | testsub | {testpub}
(1 row)
```
+ Ketika langganan dibuat, itu memuat semua data dari tabel sumber ke tabel target. Jalankan kueri SELECT pada tabel target untuk memverifikasi bahwa data awal dimuat:
```
target=> SELECT count(*) FROM testtab;
count
-------
1000
(1 row)
```
1.
**Verifikasi slot replikasi dalam database sumber**
Pembuatan langganan dalam database target menciptakan slot replikasi dalam database sumber. Verifikasi detail slot replikasi dengan menjalankan kueri SELECT berikut pada database sumber:
```
source=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved |
(1 row)
```
1.
**Menguji replikasi**
+ Uji apakah perubahan data dalam tabel sumber sedang direplikasi ke tabel target dengan menyisipkan baris ke dalam tabel sumber:
```
source=> INSERT INTO testtab VALUES(generate_series(1001,2000));
INSERT 0 1000
source=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
+ Verifikasi jumlah baris dalam tabel target untuk mengonfirmasi bahwa sisipan baru sedang direplikasi:
```
target=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
1.
**Menyegarkan langganan setelah menambahkan tabel**
+ Saat Anda menambahkan tabel baru ke publikasi yang ada, wajib menyegarkan langganan agar perubahan diterapkan:
```
ALTER SUBSCRIPTION REFRESH PUBLICATION;
```
+ Perintah ini mengambil informasi tabel yang hilang dari penerbit dan memulai replikasi untuk tabel yang ditambahkan ke publikasi berlangganan sejak langganan dibuat atau terakhir diperbarui.
# Mengkonfigurasi otentikasi IAM untuk koneksi replikasi logis
Dimulai dengan RDS untuk PostgreSQL versi 11 dan lebih tinggi, Anda dapat AWS Identity and Access Management menggunakan otentikasi (IAM) untuk koneksi replikasi. Fitur ini meningkatkan keamanan dengan memungkinkan Anda mengelola akses database menggunakan peran IAM, bukan kata sandi. Ia bekerja baik pada granularitas cluster dan instance dan mengikuti model keamanan yang sama dengan otentikasi IAM standar.
Autentikasi IAM untuk koneksi replikasi adalah fitur opt-in. Untuk mengaktifkannya, atur `rds.iam_auth_for_replication` parameter ke 1 di cluster DB atau grup parameter DB Anda. Karena ini adalah parameter dinamis, cluster atau instans DB Anda tidak perlu memulai ulang, memungkinkan Anda memanfaatkan otentikasi IAM dengan beban kerja yang ada tanpa waktu henti. Sebelum mengaktifkan fitur ini, Anda harus memenuhi Prasyarat yang tercantum di bawah ini.
**Topics**
+ [Prasyarat](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)
+ [Mengaktifkan otentikasi IAM untuk koneksi replikasi](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling)
+ [Menonaktifkan otentikasi IAM untuk koneksi replikasi](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling)
+ [Pertimbangan dan batasan](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations)
## Prasyarat
Untuk menggunakan autentikasi IAM untuk koneksi replikasi, Anda harus memenuhi semua persyaratan berikut:
+ Instans RDS untuk PostgreSQL DB Anda harus versi 11 atau yang lebih baru.
+ Pada RDS penerbit Anda untuk instans PostgreSQL DB:
+ Aktifkan otentikasi database IAM. Untuk informasi selengkapnya, lihat [Mengaktifkan dan menonaktifkan autentikasi basis data IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Aktifkan replikasi logis dengan mengatur `rds.logical_replication` parameter ke 1.
Dalam replikasi logis, penerbit adalah sumber RDS untuk database PostgreSQL yang mengirimkan data ke database pelanggan. Untuk informasi selengkapnya, lihat [Melakukan replikasi logis untuk Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
**catatan**
Otentikasi IAM dan replikasi logis harus diaktifkan pada RDS penerbit Anda untuk instance PostgreSQL DB. Jika salah satu tidak diaktifkan, Anda tidak dapat menggunakan autentikasi IAM untuk koneksi replikasi.
## Mengaktifkan otentikasi IAM untuk koneksi replikasi
Selesaikan langkah-langkah berikut untuk mengaktifkan otentikasi IAM untuk koneksi replikasi.
**Untuk mengaktifkan otentikasi IAM untuk koneksi replikasi**
1. Verifikasi bahwa klaster atau instans RDS untuk PostgreSQL DB memenuhi semua prasyarat untuk autentikasi IAM dengan koneksi replikasi. Lihat perinciannya di [Prasyarat](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites).
1. Konfigurasikan `rds.iam_auth_for_replication` parameter berdasarkan RDS Anda untuk penyiapan PostgreSQL:
+ Untuk RDS untuk instance PostgreSQL DB: Ubah grup parameter DB Anda.
+ Untuk klaster Multi-AZ: Ubah grup parameter cluster DB Anda.
Setel `rds.iam_auth_for_replication` ke 1. Ini adalah parameter dinamis yang segera berlaku tanpa memerlukan reboot.
**catatan**
Cluster multi-AZ hanya menggunakan grup parameter cluster DB. Grup parameter instans individual tidak dapat dimodifikasi di klaster multi-AZ.
1. Connect ke database Anda dan berikan peran yang diperlukan untuk pengguna replikasi Anda:
Perintah SQL berikut memberikan peran yang diperlukan untuk mengaktifkan otentikasi IAM untuk koneksi replikasi:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Setelah Anda menyelesaikan langkah-langkah ini, pengguna yang ditentukan harus menggunakan otentikasi IAM untuk koneksi replikasi.
**penting**
Saat Anda mengaktifkan fitur, pengguna dengan keduanya `rds_iam` dan `rds_replication` peran harus menggunakan autentikasi IAM untuk koneksi replikasi. Ini berlaku apakah peran ditetapkan langsung ke pengguna atau diwarisi melalui peran lain.
## Menonaktifkan otentikasi IAM untuk koneksi replikasi
Anda dapat menonaktifkan autentikasi IAM untuk koneksi replikasi dengan menggunakan salah satu metode berikut:
+ Setel `rds.iam_auth_for_replication` parameter ke 0 di grup parameter DB Anda untuk instans DB atau grup parameter cluster DB untuk cluster multi-AZ.
+ Atau, Anda dapat menonaktifkan salah satu fitur ini pada RDS Anda untuk PostgreSQL DB cluster atau instance:
+ Nonaktifkan replikasi logis dengan mengatur `rds.logical_replication` parameter ke 0
+ Nonaktifkan otentikasi IAM
Saat Anda menonaktifkan fitur tersebut, koneksi replikasi dapat menggunakan kata sandi database untuk otentikasi.
**catatan**
Koneksi replikasi untuk pengguna tanpa `rds_iam` peran dapat menggunakan otentikasi kata sandi bahkan ketika fitur diaktifkan.
## Pertimbangan dan batasan
Pertimbangkan batasan dan pertimbangan berikut saat menggunakan otentikasi IAM untuk koneksi replikasi logis:
+ Fitur ini hanya tersedia untuk RDS untuk PostgreSQL versi 11 dan lebih tinggi.
+ Penerbit harus mendukung otentikasi IAM untuk koneksi replikasi.
+ Token otentikasi IAM kedaluwarsa setelah 15 menit secara default. Anda mungkin perlu menyegarkan koneksi replikasi yang berjalan lama sebelum token kedaluwarsa.
# Disk RAM untuk stats\$1temp\$1directory
Anda dapat menggunakan parameter `rds.pg_stat_ramdisk_size` RDS for PostgreSQL untuk menentukan memori sistem yang dialokasikan ke disk RAM untuk menyimpan `stats_temp_directory` PostgreSQL. Parameter disk RAM hanya tersedia di RDS untuk PostgreSQL versi 14 dan versi yang lebih rendah.
Di bawah beban kerja tertentu, pengaturan parameter ini dapat meningkatkan kinerja dan mengurangi I/O persyaratan. Untuk informasi lebih lanjut tentang `stats_temp_directory`, lihat [dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY).
Untuk mengatur disk RAM untuk `stats_temp_directory`, atur parameter `rds.pg_stat_ramdisk_size` ke nilai literal integer dalam grup parameter yang digunakan oleh instans DB Anda. Parameter ini menunjukkan MB, jadi Anda harus menggunakan nilai integer. Ekspresi, rumus, dan fungsi tidak valid untuk parameter `rds.pg_stat_ramdisk_size`. Pastikan untuk mem-boot ulang instans DB agar perubahan diterapkan. Untuk mengetahui informasi tentang mengatur parameter, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Misalnya, AWS CLI perintah berikut menetapkan parameter disk RAM ke 256 MB.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name pg-95-ramdisk-testing \
--parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
```
Setelah Anda mem-boot ulang, jalankan perintah berikut untuk melihat status `stats_temp_directory`.
```
postgres=> SHOW stats_temp_directory;
```
Perintah tersebut akan menghasilkan hal berikut.
```
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
```
# Tablespace untuk RDS for PostgreSQL
RDS for PostgreSQL mendukung tablespace untuk kompatibilitas. Karena semua penyimpanan berada pada satu volume logis, Anda tidak dapat menggunakan ruang tabel untuk I/O pemisahan atau isolasi. Tolok ukur dan pengalaman kami menunjukkan bahwa satu volume logis adalah penyiapan terbaik untuk sebagian besar kasus penggunaan.
Untuk membuat dan menggunakan tablespace dengan instans DB RDS for PostgreSQL Anda memerlukan peran `rds_superuser`. Akun pengguna utama instans DB RDS for PostgreSQL Anda (nama default, `postgres`) adalah anggota peran ini. Untuk informasi selengkapnya, lihat [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Jika Anda menentukan nama file saat membuat tablespace, awalan jalurnya adalah `/rdsdbdata/db/base/tablespace`. Contoh berikut menempatkan file tablespace di `/rdsdbdata/db/base/tablespace/data`. Contoh ini mengasumsikan bahwa pengguna (peran) `dbadmin` ada dan telah diberikan peran `rds_superuser` yang diperlukan untuk bekerja dengan tablespace.
```
postgres=> CREATE TABLESPACE act_data
OWNER dbadmin
LOCATION '/data';
CREATE TABLESPACE
```
Untuk mempelajari selengkapnya tentang tablespace PostgreSQL, lihat [Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) dalam dokumentasi PostgreSQL.
# Kolasi RDS for PostgreSQL untuk EBCDIC dan migrasi mainframe lainnya
RDS for PostgreSQL versi 10 dan yang lebih tinggi termasuk ICU versi 60.2, yang didasarkan pada Unicode 10.0 dan mencakup kolasi dari Unicode Common Locale Data Repository, CLDR 32. Pustaka internasionalisasi perangkat lunak ini memastikan bahwa pengodean karakter disajikan secara konsisten, terlepas dari sistem operasi atau platform. Untuk informasi selengkapnya tentang Unicode CLDR-32, lihat [CLDR 32 Release Note](https://cldr.unicode.org/index/downloads/cldr-32) di situs web Unicode CLDR. Anda dapat mempelajari lebih lanjut tentang komponen internasionalisasi untuk Unicode (ICU) di situs web [ICU Technical Committee (ICU-TC)](https://icu.unicode.org/home). Untuk informasi tentang ICU-60, lihat [Download ICU 60](https://icu.unicode.org/download/60).
Mulai dari versi 14.3, RDS for PostgreSQL juga mencakup kolasi yang membantu integrasi data dan konversi dari sistem berbasis EBCDIC. Kode pertukaran desimal kode biner yang diperluas atau pengodean *EBCDIC* biasanya digunakan oleh sistem operasi mainframe. Kolasi yang disediakan Amazon RDS ini didefinisikan secara sempit untuk hanya mengurutkan karakter Unicode yang langsung dipetakan ke halaman kode EBCDIC. Karakter diurutkan dalam urutan titik kode EBCDIC untuk memungkinkan validasi data setelah konversi. Kolasi ini tidak menyertakan formulir denormalisasi, juga tidak menyertakan karakter Unicode yang tidak langsung memetakan ke karakter di halaman kode EBCDIC sumber.
Pemetaan karakter antara halaman kode EBCDIC dan titik kode Unicode didasarkan pada tabel yang diterbitkan oleh IBM. Set lengkap tersedia dari IBM sebagai [file terkompresi](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip) yang dapat diunduh. RDS for PostgreSQL menggunakan pemetaan ini dengan alat yang disediakan oleh ICU untuk membuat kolasi yang tercantum dalam tabel di bagian ini. Nama kolasi mencakup bahasa dan negara seperti yang dipersyaratkan oleh ICU. Namun, halaman kode EBCDIC tidak menentukan bahasa, dan beberapa halaman kode EBCDIC mencakup beberapa negara. Itu artinya porsi bahasa dan negara dari nama kolasi dalam tabel bersifat arbitrer, dan tidak perlu cocok dengan lokal saat ini. Dengan kata lain, nomor halaman kode adalah bagian terpenting dari nama kolasi dalam tabel ini. Anda dapat menggunakan kolasi apa pun yang tertera dalam tabel berikut di basis data RDS for PostgreSQL.
+ [Unicode to EBCDIC collations table](#ebcdic-table)Beberapa alat migrasi data mainframe secara internal menggunakan LATIN1 atau LATIN9 untuk menyandikan dan memproses data. Alat tersebut menggunakan skema pulang-pergi untuk menjaga integritas data dan mendukung konversi terbalik. Kumpulan dalam tabel ini dapat digunakan oleh alat yang memproses data menggunakan LATIN1 pengkodean, yang tidak memerlukan penanganan khusus.
+ [Unicode to LATIN9 collations table](#latin9-table)— Anda dapat menggunakan kolasi ini di RDS apa pun untuk basis data PostgreSQL.
Dalam tabel berikut, ada kolasi yang tersedia di RDS for PostgreSQL yang memetakan halaman kode EBCDIC ke titik kode Unicode. Kami menyarankan Anda menggunakan kolasi dalam tabel ini untuk pengembangan aplikasi yang memerlukan pengurutan berdasarkan urutan halaman kode IBM.
| Nama kolasi PostgreSQL | Deskripsi pemetaan halaman kode dan pengurutan urutan |
| --- | --- |
| da-DK-cp277-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 277 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 277 |
| de-DE-cp273-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 273 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 273 |
| en-GB-cp285-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 285 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 285 |
| en-US-cp037-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 037 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 37 |
| es-ES-cp284-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 284 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 284 |
| fi-FI-cp278-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 278 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 278 |
| fr-FR-cp297-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 297 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 297 |
| it-IT-cp280-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 280 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 280 |
| nl-BE-cp500-x-icu | Karakter Unicode yang langsung memetakan ke Kode EBCDIC IBM Halaman 500 (sesuai tabel konversi) diurutkan dalam urutan titik kode IBM CP 500 |
Amazon RDS menyediakan satu set kumpulan tambahan yang mengurutkan titik kode Unicode yang dipetakan ke LATIN9 karakter menggunakan tabel yang diterbitkan oleh IBM, dalam urutan titik kode asli sesuai dengan halaman kode EBCDIC dari data sumber.
| Nama kolasi PostgreSQL | Deskripsi pemetaan halaman kode dan pengurutan urutan |
| --- | --- |
| DA-DK-CP1142 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1142 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1142 |
| De-De-CP1141 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1141 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1141 |
| EN-GB-CP1146 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1146 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1146 |
| en-AS-CP1140 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1140 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1140 |
| ES-ES-CP1145 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1145 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1145 |
| fi-fi-CP1143 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1143 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1143 |
| fr-FR-CP1147 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1147 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1147 |
| IT-IT-CP1144 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1144 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1144 |
| nl-BE-CP1148 m-x-icu | Karakter unicode yang dipetakan ke LATIN9 karakter yang awalnya dikonversi dari IBM EBCDIC Code Page 1148 (per tabel konversi) diurutkan dalam urutan titik kode IBM CP 1148 |
Berikut ini, Anda dapat menemukan contoh penggunaan RDS untuk kolasi PostgreSQL.
```
db1=> SELECT pg_import_system_collations('pg_catalog');
pg_import_system_collations
-----------------------------
36
db1=> SELECT '¤' < 'a' col1;
col1
------
t
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
col1
------
f
```
Kami menyarankan Anda menggunakan kolasi di [Unicode to EBCDIC collations table](#ebcdic-table) dan di [Unicode to LATIN9 collations table](#latin9-table) untuk pengembangan aplikasi yang memerlukan pengurutan berdasarkan urutan halaman kode IBM. Kumpulan berikut (akhiran dengan huruf “b”) juga terlihat di`pg_collation`, tetapi dimaksudkan untuk digunakan oleh integrasi data mainframe dan alat migrasi di AWS halaman kode peta dengan pergeseran titik kode tertentu dan memerlukan penanganan khusus dalam pemeriksaan. Dengan kata lain, penggunaan kolasi berikut tidak direkomendasikan.
+ DA-DK-277 b-x-icu
+ DA-DK-1142 b-x-icu
+ De-de-CP273 b-x-icu
+ De-De-CP1141 b-x-icu
+ EN-GB-CP1146 b-x-icu
+ EN-GB-CP285 b-x-icu
+ id-US-CP037 b-x-icu
+ en-AS-CP1140 b-x-icu
+ ES-ES-CP1145 b-x-icu
+ es-ES-CP284 b-x-icu
+ fi-fi-CP1143 b-x-icu
+ fr-FR-CP1147 b-x-icu
+ FR-FR-CP297 b-x-icu
+ IT-IT-CP1144 b-x-icu
+ IT-IT-CP280 b-x-icu
+ nl-BE-CP1148 b-x-icu
+ NL-BE-CP500 b-x-icu
Untuk mempelajari lebih lanjut tentang memigrasi aplikasi dari lingkungan mainframe ke AWS, lihat [Apa itu Modernisasi AWS Mainframe](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html)? .
Untuk mempelajari selengkapnya tentang mengelola kolasi PostgreSQL, lihat [Collation Support](https://www.postgresql.org/docs/current/collation.html) dalam dokumentasi PostgreSQL.
# Mengelola sinkronisasi slot logis untuk RDS untuk PostgreSQL
Dimulai di komunitas PostgreSQL 17, fitur baru untuk secara otomatis menyinkronkan slot replikasi logis dari server primer ke server siaga telah diperkenalkan melalui `sync_replication_slots` parameter atau fungsi terkait`pg_sync_replication_slots()`, yang secara manual menyinkronkan slot pada eksekusi.
Fitur-fitur ini tersedia dimulai dengan RDS untuk PostgreSQL 17. Pengaturan tipikal akan memiliki instance utama dan [replika bacanya](USER_PostgreSQL.Replication.ReadReplicas.md), serta pelanggan replikasi logis ke primer.
Pastikan langganan dibuat dengan opsi failover disetel ke true:
```
CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true);
```
Ini menciptakan slot logis pada penerbit dengan failover diaktifkan.
```
postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots;
slot_name | slot_type | failover
-----------+-----------+----------
subname | logical | t
(1 row)
```
Dengan mengaktifkan sinkronisasi slot, semua slot replikasi logis failover pada primer secara otomatis dibuat pada siaga fisik dan disinkronkan secara berkala. Pastikan nilai-nilai berikut telah ditetapkan melalui [kelompok parameter](USER_WorkingWithParamGroups.Associating.md):
+ `rds.logical_replication`harus `1` mengaktifkan replikasi logis
+ `hot_standby_feedback`harus dalam `1` keadaan siaga
+ `rds.logical_slot_sync_dbname`pada siaga harus diatur ke nama database yang valid
Nilai default parameter adalah`postgres`. Jika instance penerbitan logis memiliki `postgres` database, parameter default tidak perlu diubah.
+ `synchronized_standby_slots`pada primer harus diatur ke slot replikasi fisik siaga yang dimaksudkan untuk sinkron
+ `sync_replication_slots`harus mengaktifkan `1` sinkronisasi otomatis
Dengan slot langganan yang diaktifkan failover dan nilai parameter di atas, ketika siaga dipromosikan, pelanggan dapat mengubah langganannya ke instance yang baru dipromosikan ini dan melanjutkan replikasi logis dengan mulus.
# Menghubungkan ke instans DB yang menjalankan mesin basis data PostgreSQL
Setelah Amazon RDS menyediakan instans DB, Anda dapat menggunakan aplikasi klien SQL standar untuk terhubung ke instans. Sebelum Anda dapat terhubung ke instans DB, instans tersebut harus tersedia dan dapat diakses. Apakah Anda dapat terhubung ke instans dari luar VPC atau tidak tergantung pada cara Anda membuat instans DB Amazon RDS:
+ Jika Anda membuat instans DB sebagai *publik*, perangkat dan instans Amazon EC2 di luar VPC dapat terhubung ke basis data Anda.
+ Jika Anda membuat instans DB sebagai *publik*, hanya perangkat dan instans Amazon EC2 di dalam Amazon VPC yang dapat terhubung ke basis data Anda.
Untuk memeriksa apakah instans DB Anda bersifat publik atau pribadi, gunakan Konsol Manajemen AWS untuk melihat tab **Konektivitas & keamanan** untuk instans Anda. Di bagian **Keamanan**, Anda dapat menemukan nilai "Dapat diakses publik", dengan Tidak untuk pribadi, Ya untuk publik.
Untuk mempelajari selengkapnya tentang berbagai konfigurasi Amazon RDS dan Amazon VPC serta pengaruhnya terhadap aksesibilitas, lihat [Skenario untuk mengakses instans DB di VPC](USER_VPC.Scenarios.md).
**Contents**
+ [Menginstal klien psql](#install-psql)
+ [Menemukan informasi koneksi untuk RDS untuk PostgreSQL DB instance](#postgresql-endpoint)
+ [Menggunakan pgAdmin untuk terhubung ke instans RDS for PostgreSQL DB](USER_ConnectToPostgreSQLInstance.pgAdmin.md)
+ [Menggunakan psql untuk terhubung ke instans RDS for PostgreSQL DB Anda](USER_ConnectToPostgreSQLInstance.psql.md)
+ [Menghubungkan ke RDS untuk PostgreSQL dengan Driver Amazon Web Services () JDBC AWS](PostgreSQL.Connecting.JDBCDriver.md)
+ [Menghubungkan ke RDS untuk PostgreSQL dengan Driver Python Amazon Web Services ()AWS](PostgreSQL.Connecting.PythonDriver.md)
+ [Memecahkan masalah koneksi ke instans RDS for PostgreSQL Anda](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [Kesalahan — FATAL: basis data *name* tidak ada](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [Kesalahan — Tidak dapat terhubung ke server: Waktu koneksi habis](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [Kesalahan dengan aturan akses grup keamanan](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Menginstal klien psql
Untuk terhubung ke instans DB Anda dari instans EC2, Anda dapat menginstal klien PostgreSQL pada instans EC2. Untuk menginstal versi terbaru klien psql di Amazon Linux 2023, jalankan perintah berikut:
```
sudo dnf install postgresql
```
Untuk menginstal versi terbaru klien psql di Amazon Linux 2, jalankan perintah berikut:
```
sudo yum install -y postgresql
```
Untuk menginstal versi terbaru klien psql di Ubuntu, jalankan perintah berikut:
```
sudo apt install -y postgresql-client
```
## Menemukan informasi koneksi untuk RDS untuk PostgreSQL DB instance
Jika instans DB tersedia dan dapat diakses, Anda dapat terhubung dengan memberikan informasi berikut ke aplikasi klien SQL:
+ Titik akhir instans DB, yang berfungsi sebagai nama host (nama DNS) untuk instans.
+ Port tempat instans DB penulis mendengarkan. Port default untuk PostgreSQL adalah 5432.
+ Nama pengguna dan kata sandi untuk instans DB. Default 'nama pengguna utama' untuk PostgreSQL adalah `postgres`.
+ Nama dan kata sandi basis data (nama DB).
Anda dapat memperoleh detail ini dengan menggunakan Konsol Manajemen AWS, AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)perintah, atau DBInstances operasi Amazon RDS API [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html).
**Untuk menemukan titik akhir, nomor port, dan nama DB menggunakan Konsol Manajemen AWS**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Buka konsol RDS, lalu pilih **Basis data** untuk menampilkan daftar instans DB Anda.
1. Pilih nama instans PostgreSQL DB untuk menampilkan detailnya.
1. Di tab **Konektivitas & keamanan**, salin titik akhir. Selain itu, catat nomor port. Anda memerlukan titik akhir dan nomor port untuk terhubung ke instans DB.
![\[Dapatkan titik akhir dari Konsol RDS\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/PostgreSQL-endpoint.png)
1. Pada tab **Konfigurasi**, perhatikan nama DB. Jika Anda membuat basis data saat membuat instans RDS for PostgreSQL, Anda melihat nama yang tercantum di bawah nama DB. Jika Anda tidak membuat basis data, nama DB akan menampilkan tanda hubung (‐).
![\[Dapatkan nama DB dari Konsol RDS\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/PostgreSQL-db-name.png)
Berikut ini adalah dua cara untuk terhubung dengan instans PostgreSQL DB. Contoh pertama menggunakan pgAdmin, alat administrasi dan pengembangan sumber terbuka yang populer untuk PostgreSQL. Contoh kedua menggunakan psql, utilitas baris perintah yang merupakan bagian dari penginstalan PostgreSQL.
# Menggunakan pgAdmin untuk terhubung ke instans RDS for PostgreSQL DB
Anda dapat menggunakan alat sumber terbuka pgAdmin untuk terhubung ke instans RDS for PostgreSQL DB. Anda dapat mengunduh dan menginstal pgAdmin dari [http://www.pgadmin.org/](http://www.pgadmin.org/) tanpa memiliki instans lokal PostgreSQL di komputer klien Anda.
**Untuk terhubung ke instans RDS for PostgreSQL DB menggunakan pgAdmin**
1. Luncurkan aplikasi pgAdmin di komputer klien Anda.
1. Pada tab **Dasbor**, pilih **Tambahkan Server Baru**.
1. Di kotak dialog **Buat - Server**, ketik nama pada tab **Umum** untuk mengidentifikasi server di pgAdmin.
1. Di tab **Koneksi**, ketik informasi berikut dari instans DB Anda:
+ Untuk **Host**, ketik titik akhir, misalnya `mypostgresql.c6c8dntfzzhgv0.us-east-2.rds.amazonaws.com`.
+ Untuk **Port**, ketik port yang ditetapkan.
+ Untuk **Nama pengguna**, ketik nama pengguna yang Anda masukkan saat membuat instans DB (jika Anda mengubah 'nama pengguna utama' dari default, `postgres`).
+ Untuk **Kata sandi**, ketik kata sandi yang Anda masukkan saat membuat instans DB.
![\[Ketik kata sandi yang Anda masukkan saat membuat instans DB\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/Postgres-Connect01.png)
1. Pilih **Simpan**.
Jika Anda mengalami masalah saat menghubungkan, lihat [Memecahkan masalah koneksi ke instans RDS for PostgreSQL Anda](USER_ConnectToPostgreSQLInstance.Troubleshooting.md).
1. Untuk mengakses basis data di browser pgAdmin, perluas **Server**, instans DB, dan **Basis data**. Pilih nama basis data instans DB.
![\[Pilih nama database instans DB di browser pgAdmin\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/Postgres-Connect02.png)
1. Untuk membuka panel tempat Anda dapat memasukkan perintah SQL, pilih **Alat**, **Alat Kueri**.
# Menggunakan psql untuk terhubung ke instans RDS for PostgreSQL DB Anda
Anda dapat menggunakan instans lokal dari utilitas baris perintah psql untuk terhubung ke instans RDS for PostgreSQL DB. Anda memerlukan menginstal klien PostgreSQL atau psql pada komputer klien Anda.
Anda dapat mengunduh klien PostgreSQL dari situs web [PostgreSQL](https://www.postgresql.org/download/). Ikuti petunjuk khusus untuk versi sistem operasi Anda guna menginstal psql.
Untuk terhubung ke instans RDS for PostgreSQL DB menggunakan psql, Anda perlu memberikan informasi host (DNS), kredensial akses, dan nama basis data.
Gunakan salah satu format berikut untuk terhubung ke instans RDS for PostgreSQL DB. Saat terhubung, Anda diminta memasukkan kata sandi. Untuk pekerjaan atau skrip batch, gunakan opsi `--no-password`. Opsi ini ditetapkan untuk seluruh sesi.
**catatan**
Upaya koneksi dengan `--no-password` akan gagal saat server memerlukan autentikasi kata sandi dan kata sandi tidak tersedia dari sumber lain. Lihat mengetahui informasi selengkapnya, lihat [dokumentasi psql](https://www.postgresql.org/docs/13/app-psql.html).
Jika Anda pertama kali terhubung ke instans DB ini, atau jika Anda belum membuat basis data untuk instans RDS for PostgreSQL ini, Anda dapat terhubung ke basis data **postgres** menggunakan 'nama pengguna utama' dan kata sandi.
Untuk Unix, gunakan format berikut.
```
psql \
--host= \
--port= \
--username= \
--password \
--dbname=
```
Untuk Windows, gunakan format berikut.
```
psql ^
--host= ^
--port= ^
--username= ^
--password ^
--dbname=
```
Misalnya, perintah berikut menghubungkan ke basis data bernama `mypgdb` pada instans PostgreSQL DB bernama `mypostgresql` menggunakan kredensial fiktif.
```
psql --host=mypostgresql.c6c8mwvfdgv0.us-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb
```
# Menghubungkan ke RDS untuk PostgreSQL dengan Driver Amazon Web Services () JDBC AWS
Amazon Web Services (AWS) JDBC Driver dirancang sebagai pembungkus JDBC tingkat lanjut. Pembungkus ini melengkapi dan memperluas fungsionalitas driver JDBC yang ada. Driver ini kompatibel dengan driver PgJDBC komunitas.
Untuk menginstal Driver AWS JDBC, tambahkan file AWS JDBC Driver .jar (terletak di aplikasi`CLASSPATH`), dan simpan referensi ke driver komunitas masing-masing. Perbarui awalan URL koneksi masing-masing sebagai berikut:
+ `jdbc:postgresql://` untuk `jdbc:aws-wrapper:postgresql://`
Untuk informasi selengkapnya tentang Driver AWS JDBC dan petunjuk lengkap untuk menggunakannya, lihat repositori [Amazon Web Services (AWS) JDBC Driver](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub
# Menghubungkan ke RDS untuk PostgreSQL dengan Driver Python Amazon Web Services ()AWS
Driver Python Amazon Web Services (AWS) dirancang sebagai pembungkus Python tingkat lanjut. Pembungkus ini melengkapi dan memperluas fungsionalitas driver Psycopg open-source. Driver AWS Python mendukung Python versi 3.8 dan lebih tinggi. Anda dapat menginstal `aws-advanced-python-wrapper` paket menggunakan `pip` perintah, bersama dengan paket `psycopg` open-source.
Untuk informasi selengkapnya tentang Driver AWS Python dan petunjuk lengkap untuk menggunakannya, lihat repositori [Amazon Web Services ()AWS Python](https://github.com/awslabs/aws-advanced-python-wrapper) Driver. GitHub
# Memecahkan masalah koneksi ke instans RDS for PostgreSQL Anda
**Topics**
+ [Kesalahan — FATAL: basis data *name* tidak ada](#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [Kesalahan — Tidak dapat terhubung ke server: Waktu koneksi habis](#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [Kesalahan dengan aturan akses grup keamanan](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Kesalahan — FATAL: basis data *name* tidak ada
Jika Anda menerima pesan kesalahan seperti `FATAL: database name does not exist` saat menghubungkan, coba gunakan nama basis data default **postgres** untuk opsi `--dbname`.
## Kesalahan — Tidak dapat terhubung ke server: Waktu koneksi habis
Jika Anda tidak dapat terhubung ke instans DB, kesalahan yang paling umum adalah `Could not connect to server: Connection timed out.`. Jika Anda menerima kesalahan ini, periksa hal berikut:
+ Periksa bahwa nama host yang digunakan adalah titik akhir instans DB dan bahwa nomor port yang digunakan sudah benar.
+ Pastikan bahwa aksesibilitas publik instans DB tersebut diatur ke **Ya** untuk mengizinkan koneksi eksternal. Untuk mengubah pengaturan **Akses publik**, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
+ Pastikan bahwa pengguna yang terhubung ke basis data memiliki akses CONNECT. Anda dapat menggunakan kueri berikut untuk memberikan akses koneksi ke basis data tersebut.
```
GRANT CONNECT ON DATABASE database name TO username;
```
+ Periksa bahwa grup keamanan yang ditetapkan ke instans DB memiliki aturan untuk memungkinkan akses melalui firewall yang mungkin dilalui koneksi Anda. Misalnya, jika instans DB dibuat menggunakan port default 5432, dan perusahaan Anda mungkin memiliki aturan firewall yang memblokir koneksi ke port tersebut dari perangkat perusahaan eksternal.
Untuk memperbaikinya, ubah instans DB untuk menggunakan port yang berbeda. Selain itu, pastikan bahwa grup keamanan yang diterapkan ke instans DB memungkinkan koneksi ke port baru. Untuk mengubah pengaturan **Port basis data**, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
+ Periksa apakah port yang Anda coba gunakan sudah ditempati oleh instance lokal PostgreSQL atau layanan lain yang berjalan di komputer Anda. Misalnya, jika Anda memiliki database PostgreSQL lokal yang berjalan pada port yang sama (defaultnya adalah 5432), mungkin mencegah koneksi berhasil ke RDS untuk PostgreSQL DB instance. Pastikan port gratis, atau coba sambungkan dengan nomor port yang berbeda jika memungkinkan.
+ Lihat juga [Kesalahan dengan aturan akses grup keamanan](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules).
## Kesalahan dengan aturan akses grup keamanan
Sejauh ini, masalah koneksi yang paling umum adalah dengan aturan akses grup keamanan yang ditetapkan untuk instans DB. Jika Anda menggunakan grup keamanan default saat membuat instans DB, grup keamanan kemungkinan tidak memiliki aturan akses yang memungkinkan Anda mengakses instans tersebut.
Agar koneksi dapat berfungsi, grup keamanan yang Anda tetapkan ke instans DB pada pembuatannya harus mengizinkan akses ke instans DB. Misalnya, jika instans DB dibuat di VPC, instans tersebut harus memiliki grup keamanan VPC yang mengotorisasi koneksi. Periksa apakah instans DB dibuat menggunakan grup keamanan yang tidak mengotorisasi koneksi dari perangkat atau instans Amazon EC2 tempat aplikasi tersebut berjalan.
Anda dapat menambahkan atau mengedit aturan masuk di grup keamanan. Untuk **Sumber**, memilih **IP Saya** akan mengizinkan akses ke instans DB dari alamat IP yang terdeteksi di browser Anda. Untuk informasi selengkapnya, lihat [Memberikan akses ke instans DB di VPC Anda dengan membuat grup keamanan](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Atau, jika instans DB dibuat di luar VPC, instans tersebut harus memiliki grup keamanan basis data yang mengotorisasi koneksinya.
Untuk mengetahui informasi selengkapnya tentang grup keamanan Amazon RDS, lihat [Mengontrol akses dengan grup keamanan](Overview.RDSSecurityGroups.md).
# Mengamankan koneksi ke RDS for PostgreSQL dengan SSL/TLS
RDS for PostgreSQL mendukung enkripsi Secure Socket Layer (SSL) untuk instans DB PostgreSQL. Dengan menggunakan SSL, Anda dapat mengenkripsi koneksi PostgreSQL antara aplikasi Anda dan instans DB PostgreSQL Anda. Anda juga dapat memaksa semua koneksi ke instans DB PostgreSQL Anda untuk menggunakan SSL. RDS for PostgreSQL juga mendukung Keamanan Lapisan Pengangkutan (TLS), protokol penerus SSL.
Untuk mempelajari lebih lanjut tentang Amazon RDS dan perlindungan data, termasuk mengenkripsi koneksi menggunakan SSL/TLS, lihat [Perlindungan data di Amazon RDS](DataDurability.md).
**Topics**
+ [Menggunakan SSL dengan instans DB PostgreSQL](PostgreSQL.Concepts.General.SSL.md)
+ [Memperbarui aplikasi untuk terhubung ke instance PostgreSQL DB menggunakan sertifikat baru SSL/TLS](ssl-certificate-rotation-postgresql.md)
# Menggunakan SSL dengan instans DB PostgreSQL
Amazon RDS mendukung enkripsi Secure Socket Layer (SSL) untuk instans DB PostgreSQL. Dengan menggunakan SSL, Anda dapat mengenkripsi koneksi PostgreSQL antara aplikasi Anda dan instans DB PostgreSQL Anda. Secara default, RDS for PostgreSQL menggunakan dan mengharapkan semua klien untuk terhubung menggunakan SSL/TLS, tetapi Anda juga dapat memerlukannya. RDS untuk PostgreSQL mendukung Transport Layer Security (TLS) versi 1.1, 1.2, dan 1.3.
Untuk informasi umum tentang dukungan SSL dan basis data PostgreSQL, lihat [SSL support](https://www.postgresql.org/docs/11/libpq-ssl.html) dalam dokumentasi PostgreSQL. Untuk informasi tentang menggunakan koneksi SSL melalui JDBC, lihat [Configuring the client](https://jdbc.postgresql.org/documentation/head/ssl-client.html) dalam dokumentasi PostgreSQL.
Dukungan SSL tersedia di semua AWS Wilayah untuk PostgreSQL. Amazon RDS membuat sertifikat SSL untuk instans DB PostgreSQL Anda ketika instans dibuat. Jika Anda mengaktifkan verifikasi sertifikat SSL, maka sertifikat SSL mencakup titik akhir instans DB sebagai Nama Umum (CN) untuk sertifikat SSL untuk melindungi dari serangan spoofing.
**Topics**
+ [Menghubungkan ke instans DB PostgreSQL melalui SSL](#PostgreSQL.Concepts.General.SSL.Connecting)
+ [Mewajibkan koneksi SSL ke instans DB PostgreSQL](#PostgreSQL.Concepts.General.SSL.Requiring)
+ [Menentukan status koneksi SSL](#PostgreSQL.Concepts.General.SSL.Status)
+ [Rangkaian penyandian SSL di RDS for PostgreSQL](#PostgreSQL.Concepts.General.SSL.Ciphers)
## Menghubungkan ke instans DB PostgreSQL melalui SSL
**Untuk menghubungkan ke instans DB PostgreSQL melalui SSL**
1. Unduh sertifikatnya.
Untuk informasi tentang mengunduh sertifikat, lihat [](UsingWithRDS.SSL.md).
1. Hubungkan instans DB PostgreSQL Anda melalui SSL.
Saat Anda menghubungkan menggunakan SSL, klien Anda dapat memilih untuk memverifikasi rantai sertifikat. Jika parameter koneksi Anda menentukan `sslmode=verify-ca` atau `sslmode=verify-full`, kemudian klien Anda mengharuskan sertifikat RDS CA berada di penyimpanan terpercaya atau dirujuk di URL koneksi. Persyaratan ini untuk memverifikasi rantai sertifikat yang menandatangani sertifikat basis data Anda.
Ketika klien, seperti psql atau JDBC, dikonfigurasikan dengan dukungan SSL, klien pertama kali mencoba untuk terhubung ke basis data dengan SSL secara default. Jika klien tidak dapat terhubung dengan SSL, maka akan kembali ke koneksi tanpa SSL. Mode `sslmode` default yang digunakan berbeda antara klien berbasis libpq (seperti psql) dan JDBC. Klien berbasis libpq dan JDBC default ke. `prefer`
Gunakan parameter `sslrootcert` untuk mereferensikan sertifikat, misalnya `sslrootcert=rds-ssl-ca-cert.pem`.
Berikut ini adalah contoh penggunaan `psql` untuk terhubung ke instans DB PostgreSQL menggunakan SSL dengan verifikasi sertifikat.
```
$ psql "host=db-name.555555555555.ap-southeast-1.rds.amazonaws.com
port=5432 dbname=testDB user=testuser sslrootcert=rds-ca-rsa2048-g1.pem sslmode=verify-full"
```
## Mewajibkan koneksi SSL ke instans DB PostgreSQL
Anda dapat mewajibkan koneksi tersebut ke instans DB RDS for PostgreSQL Anda dengan SSL menggunakan parameter `rds.force_ssl`. Nilai default `rds.force_ssl` parameter adalah 1 (on) untuk RDS untuk PostgreSQL versi 15 dan yang lebih baru. Untuk semua RDS lainnya untuk PostgreSQL mayor versi 14 dan yang lebih lama, nilai default parameter ini adalah 0 (off). Anda dapat mengatur `rds.force_ssl` parameter ke 1 (on) SSL/TLS untuk memerlukan koneksi ke cluster DB Anda. Anda dapat mengatur parameter `rds.force_ssl` ke 1 (aktif) guna mewajibkan SSL untuk koneksi dengan instans basis data Anda.
Untuk mengubah nilai parameter ini, Anda perlu membuat grup parameter DB kustom. Anda kemudian mengubah nilai untuk `rds.force_ssl` dalam grup parameter DB kustom Anda menjadi `1` untuk mengaktifkan fitur ini. Jika Anda menyiapkan grup parameter DB kustom sebelum membuat RDS untuk instans DB PostgreSQL, Anda dapat memilihnya (bukan grup parameter default) selama proses pembuatan. Jika Anda melakukan ini setelah instans DB RDS for PostgreSQL Anda sudah berjalan, Anda perlu mem-boot ulang instans sehingga instans Anda menggunakan grup parameter kustom. Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Ketika fitur `rds.force_ssl` aktif pada instans DB Anda, upaya koneksi yang tidak menggunakan SSL ditolak dengan pesan berikut:
```
$ psql -h db-name.555555555555.ap-southeast-1.rds.amazonaws.com port=5432 dbname=testDB user=testuser
psql: error: FATAL: no pg_hba.conf entry for host "w.x.y.z", user "testuser", database "testDB", SSL off
```
## Menentukan status koneksi SSL
Status terenkripsi dari koneksi Anda ditunjukkan pada banner logon saat Anda terhubung ke instans DB:
```
Password for user master:
psql (10.3)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Anda juga dapat memuat ekstensi `sslinfo`, lalu memanggil fungsi `ssl_is_used()` untuk menentukan apakah SSL digunakan. Fungsi akan kembali `t` jika koneksi menggunakan SSL, jika tidak akan menghasilkan `f`.
```
postgres=> CREATE EXTENSION sslinfo;
CREATE EXTENSION
postgres=> SELECT ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Untuk informasi lebih rinci, Anda dapat menggunakan kueri berikut untuk mendapatkan informasi dari `pg_settings`:
```
SELECT name as "Parameter name", setting as value, short_desc FROM pg_settings WHERE name LIKE '%ssl%';
Parameter name | value | short_desc
----------------------------------------+-----------------------------------------+-------------------------------------------------------
ssl | on | Enables SSL connections.
ssl_ca_file | /rdsdbdata/rds-metadata/ca-cert.pem | Location of the SSL certificate authority file.
ssl_cert_file | /rdsdbdata/rds-metadata/server-cert.pem | Location of the SSL server certificate file.
ssl_ciphers | HIGH:!aNULL:!3DES | Sets the list of allowed SSL ciphers.
ssl_crl_file | | Location of the SSL certificate revocation list file.
ssl_dh_params_file | | Location of the SSL DH parameters file.
ssl_ecdh_curve | prime256v1 | Sets the curve to use for ECDH.
ssl_key_file | /rdsdbdata/rds-metadata/server-key.pem | Location of the SSL server private key file.
ssl_library | OpenSSL | Name of the SSL library.
ssl_max_protocol_version | | Sets the maximum SSL/TLS protocol version to use.
ssl_min_protocol_version | TLSv1.2 | Sets the minimum SSL/TLS protocol version to use.
ssl_passphrase_command | | Command to obtain passphrases for SSL.
ssl_passphrase_command_supports_reload | off | Also use ssl_passphrase_command during server reload.
ssl_prefer_server_ciphers | on | Give priority to server ciphersuite order.
(14 rows)
```
Anda juga dapat mengumpulkan semua informasi tentang penggunaan SSL instans DB RDS for PostgreSQL Anda berdasarkan proses, klien, dan aplikasi menggunakan kueri berikut:
```
SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid
ORDER BY ssl;
Database name | User name | ssl | client_addr | application_name | backend_type
---------------+-----------+-----+----------------+------------------------+------------------------------
| | f | | | autovacuum launcher
| rdsadmin | f | | | logical replication launcher
| | f | | | background writer
| | f | | | checkpointer
| | f | | | walwriter
rdsadmin | rdsadmin | t | 127.0.0.1 | | client backend
rdsadmin | rdsadmin | t | 127.0.0.1 | PostgreSQL JDBC Driver | client backend
postgres | postgres | t | 204.246.162.36 | psql | client backend
(8 rows)
```
Untuk mengidentifikasi penyandian yang digunakan untuk koneksi SSL Anda, Anda dapat melakukan kueri sebagai berikut:
```
postgres=> SELECT ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Untuk informasi tentang opsi `sslmode`, lihat [Database connection control functions](https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) dalam *dokumentasi PostgreSQL*.
## Rangkaian penyandian SSL di RDS for PostgreSQL
[Parameter](https://www.postgresql.org/docs/current/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL) konfigurasi PostgreSQL ssl\$1ciphers menentukan kategori cipher suite yang diizinkan untuk koneksi SSL ke database saat menggunakan TLS 1.2 dan yang lebih rendah.
Di RDS untuk PostgreSQL 16 dan yang lebih baru, Anda dapat memodifikasi parameter untuk menggunakan nilai tertentu `ssl_ciphers` dari rangkaian sandi yang diizinkan. Ini adalah parameter dinamis yang tidak memerlukan reboot instance database. Untuk melihat rangkaian cipher yang diizinkan, gunakan konsol Amazon RDS atau perintah CLI berikut: AWS
```
aws rds describe-db-parameters --db-parameter-group-name --region --endpoint-url --output json | jq '.Parameters[] | select(.ParameterName == "ssl_ciphers")'
```
Tabel berikut mencantumkan suite cipher default dan suite cipher yang diizinkan untuk versi yang mendukung konfigurasi kustom.
| Versi mesin PostgreSQL | Nilai suite ssl\$1cipher default | Nilai suite ssl\$1cipher kustom yang diizinkan |
| --- | --- | --- |
| 18 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 17 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 16 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 15 | HIGH:\$1aNULL:\$13DES | Ssl\$1ciphers kustom tidak didukung |
| 14 | HIGH:\$1aNULL:\$13DES | Ssl\$1ciphers kustom tidak didukung |
| 13 | HIGH:\$1aNULL:\$13DES | Ssl\$1ciphers kustom tidak didukung |
| 12 | HIGH:\$1aNULL:\$13DES | Ssl\$1ciphers kustom tidak didukung |
| 11.4 dan versi minor yang lebih tinggi | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | Ssl\$1ciphers kustom tidak didukung |
| 11.1, 11.2 | HIGH:MEDIUM:\$13DES:\$1aNULL | Ssl\$1ciphers kustom tidak didukung |
| 10.9 dan versi minor yang lebih tinggi | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | Ssl\$1ciphers kustom tidak didukung |
| 10.7 dan versi minor yang lebih rendah | HIGH:MEDIUM:\$13DES:\$1aNULL | Ssl\$1ciphers kustom tidak didukung |
Untuk mengonfigurasi semua koneksi instance untuk menggunakan `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` cipher suite, ubah grup parameter Anda seperti yang ditunjukkan pada contoh berikut:
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_ciphers',ParameterValue='TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',ApplyMethod=immediate"
```
Contoh ini menggunakan sandi ECDSA, yang mengharuskan instans Anda menggunakan otoritas sertifikat dengan kriptografi kurva elips (ECC) untuk membuat koneksi. Untuk informasi tentang otoritas sertifikat yang disediakan oleh Amazon RDS, lihat [Otoritas sertifikat](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/singWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities).
Anda dapat memverifikasi cipher yang digunakan melalui metode yang dijelaskan dalam [Menentukan status koneksi SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Status).
Cipher mungkin memiliki nama yang berbeda tergantung pada konteksnya:
+ Cipher yang diizinkan yang dapat Anda konfigurasikan dalam grup parameter Anda dirujuk dengan nama IANA mereka.
+ Spanduk `sslinfo` dan `psql` logon mengacu pada cipher menggunakan nama OpenSSL mereka.
Secara default, nilai `ssl_max_protocol_version` dalam RDS untuk PostgreSQL 16 dan yang lebih baru adalah TLS v1.3. Anda harus mengatur nilai parameter ini ke TLS v1.2 karena TLS v1.3 tidak menggunakan konfigurasi sandi yang ditentukan dalam parameter. `ssl_ciphers` Ketika Anda menetapkan nilai sebagai TLS v1.2, koneksi hanya menggunakan cipher yang Anda tentukan. `ssl_ciphers`
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_max_protocol_version',ParameterValue='TLSv1.2',ApplyMethod=immediate"
```
Untuk memastikan koneksi database menggunakan SSL, atur `rds.force_ssl parameter` ke 1 di grup parameter Anda. Untuk informasi selengkapnya tentang parameter dan grup parameter, lihat [Grup parameter untuk Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)
# Memperbarui aplikasi untuk terhubung ke instance PostgreSQL DB menggunakan sertifikat baru SSL/TLS
Sertifikat yang digunakan untuk Secure Socket Layer atau Transport Layer Security (SSL/TLS) typically have a set lifetime. When service providers update their Certificate Authority (CA) certificates, clients must update their applications to use the new certificates. Following, you can find information about how to determine if your client applications use SSL/TLSuntuk menyambung ke Amazon RDS for PostgreSQL DB instance. Anda juga menemukan informasi tentang cara memeriksa apakah aplikasi tersebut memverifikasi sertifikat server saat aplikasi terhubung.
**catatan**
Aplikasi klien yang dikonfigurasi untuk memverifikasi sertifikat server sebelum SSL/TLS koneksi harus memiliki sertifikat CA yang valid di toko kepercayaan klien. Perbarui penyimpanan kepercayaan klien bila diperlukan untuk sertifikat baru.
Setelah Anda memperbarui sertifikat CA di penyimpanan kepercayaan aplikasi klien, Anda dapat merotasi sertifikat di instans DB Anda. Kami sangat menyarankan Anda menguji prosedur ini di lingkungan non-produksi sebelum menerapkannya di lingkungan produksi Anda.
Untuk informasi selengkapnya tentang rotasi sertifikat, lihat [Memutar sertifikat Anda SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md). Untuk informasi selengkapnya tentang mengunduh sertifikat, lihat [](UsingWithRDS.SSL.md). Untuk informasi tentang penggunaan SSL/TLS dengan instance PostgreSQL DB, lihat. [Menggunakan SSL dengan instans DB PostgreSQL](PostgreSQL.Concepts.General.SSL.md)
**Topics**
+ [Menentukan apakah aplikasi terhubung ke instans DB PostgreSQL menggunakan SSL](#ssl-certificate-rotation-postgresql.determining-server)
+ [Menentukan apakah klien memerlukan verifikasi sertifikat agar dapat terhubung](#ssl-certificate-rotation-postgresql.determining-client)
+ [Memperbarui penyimpanan kepercayaan aplikasi Anda](#ssl-certificate-rotation-postgresql.updating-trust-store)
+ [Menggunakan SSL/TLS koneksi untuk berbagai jenis aplikasi](#ssl-certificate-rotation-postgresql.applications)
## Menentukan apakah aplikasi terhubung ke instans DB PostgreSQL menggunakan SSL
Periksa konfigurasi instans DB untuk nilai parameter `rds.force_ssl`. Secara default, parameter `rds.force_ssl` diatur ke `0` (tidak aktif) untuk instans DB menggunakan versi PostgreSQL sebelum versi 15. Secara default, `rds.force_ssl` diatur ke `1` (aktif) untuk instans DB menggunakan PostgreSQL versi 15 dan versi utama yang lebih baru. Jika `rds.force_ssl` parameter diatur ke `1` (on), klien diharuskan untuk menggunakan SSL/TLS untuk koneksi. Untuk informasi lebih lanjut tentang grup parameter, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Jika Anda menggunakan RDS PostgreSQL versi 9.5 atau versi utama yang lebih baru dan `rds.force_ssl` tidak diatur ke `1` (aktif), lakukan kueri tampilan `pg_stat_ssl` untuk memeriksa koneksi menggunakan SSL. Misalnya, kueri berikut hanya mengembalikan koneksi SSL dan informasi tentang klien menggunakan SSL.
```
SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';
```
Hanya baris yang menggunakan SSL/TLS koneksi yang ditampilkan dengan informasi tentang koneksi. Berikut ini adalah contoh output-nya.
```
datname | usename | ssl | client_addr
----------+---------+-----+-------------
benchdb | pgadmin | t | 53.95.6.13
postgres | pgadmin | t | 53.95.6.13
(2 rows)
```
Kueri ini hanya menampilkan koneksi saat ini pada waktu kueri. Tidak adanya hasil tidak menunjukkan bahwa tidak ada aplikasi yang menggunakan koneksi SSL. Koneksi SSL lainnya mungkin dibangun pada waktu yang lain.
## Menentukan apakah klien memerlukan verifikasi sertifikat agar dapat terhubung
Ketika klien, seperti psql atau JDBC, dikonfigurasikan dengan dukungan SSL, klien pertama kali mencoba untuk terhubung ke basis data dengan SSL secara default. Jika klien tidak dapat terhubung dengan SSL, maka akan kembali ke koneksi tanpa SSL. `sslmode`Mode default yang digunakan untuk klien berbasis libpq (seperti psql) dan JDBC diatur ke. `prefer` Sertifikat di server diverifikasi hanya jika `sslrootcert` disediakan dengan `sslmode` diatur ke `verify-ca` atau `verify-full`. Kesalahan akan muncul jika sertifikat tidak valid.
Gunakan `PGSSLROOTCERT` untuk memverifikasi sertifikat dengan variabel lingkungan `PGSSLMODE`, dengan `PGSSLMODE` diatur ke `verify-ca` atau `verify-full`.
```
PGSSLMODE=verify-full PGSSLROOTCERT=/fullpath/ssl-cert.pem psql -h pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com -U masteruser -d postgres
```
Gunakan argumen `sslrootcert` untuk memverifikasi sertifikat dengan `sslmode` dalam menghubungkan format string, dengan `sslmode` diatur ke `verify-ca` atau `verify-full` untuk memverifikasi sertifikat.
```
psql "host=pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com sslmode=verify-full sslrootcert=/full/path/ssl-cert.pem user=masteruser dbname=postgres"
```
Misalnya, dalam kasus sebelumnya, jika Anda menggunakan sertifikat root yang tidak valid, maka Anda akan melihat kesalahan yang serupa dengan yang berikut pada klien Anda.
```
psql: SSL error: certificate verify failed
```
## Memperbarui penyimpanan kepercayaan aplikasi Anda
Untuk informasi tentang memperbarui toko kepercayaan untuk aplikasi PostgreSQL, [lihat Koneksi TCP/IP aman dengan SSL](https://www.postgresql.org/docs/current/ssl-tcp.html) di dokumentasi PostgreSQL.
Untuk informasi tentang cara mengunduh sertifikat root, lihat [](UsingWithRDS.SSL.md).
Untuk contoh skrip yang mengimpor sertifikat, lihat [Contoh skrip untuk mengimpor sertifikat ke trust store Anda](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**catatan**
Saat memperbarui penyimpanan kepercayaan, Anda dapat mempertahankan sertifikat lama selain menambahkan sertifikat baru.
## Menggunakan SSL/TLS koneksi untuk berbagai jenis aplikasi
Berikut ini memberikan informasi tentang penggunaan SSL/TLS koneksi untuk berbagai jenis aplikasi:
+ **psql**
Klien diinvokasi dari baris perintah dengan menentukan opsi sebagai string koneksi atau sebagai variabel lingkungan. Untuk SSL/TLS koneksi, opsi yang relevan adalah `sslmode` (variabel lingkungan`PGSSLMODE`), `sslrootcert` (variabel lingkungan`PGSSLROOTCERT`).
Untuk daftar lengkap opsi, lihat [Parameter key words](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS) dalam dokumentasi PostgreSQL. Untuk daftar lengkap variabel lingkungan, lihat [Environment variables](https://www.postgresql.org/docs/current/libpq-envars.html) dalam dokumentasi PostgreSQL.
+ **pgAdmin**
Klien berbasis browser ini adalah antarmuka yang lebih mudah untuk terhubung ke basis data PostgreSQL.
Untuk informasi tentang cara mengonfigurasi koneksi, lihat [dokumentasi pgAdmin](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html).
+ **JDBC**
JDBC memungkinkan koneksi basis data dengan aplikasi Java.
Untuk informasi umum tentang koneksi ke basis data PostgreSQL dengan JDBC, lihat [Connecting to the database](https://jdbc.postgresql.org/documentation/use/#connecting-to-the-database) dalam dokumentasi driver JDBC PostgreSQL. Untuk informasi tentang koneksi dengan SSL/TLS, lihat [Configuring the client](https://jdbc.postgresql.org/documentation/ssl/#configuring-the-client) dalam dokumentasi driver JDBC PostgreSQL.
+ **Python**
Pustaka Python yang populer untuk terhubung ke basis data PostgreSQL adalah `psycopg2`.
Untuk informasi tentang cara menggunakan `psycopg2`, lihat [dokumentasi psycopg2](https://pypi.org/project/psycopg2/). Untuk tutorial singkat tentang cara terhubung ke basis data PostgreSQL, lihat [Tutorial Psycopg2](https://wiki.postgresql.org/wiki/Psycopg2_Tutorial). Anda dapat menemukan informasi tentang opsi penerimaan perintah koneksi di [Konten modul psycopg2](http://initd.org/psycopg/docs/module.html#module-psycopg2).
**penting**
Setelah Anda menentukan bahwa koneksi database Anda menggunakan SSL/TLS dan telah memperbarui toko kepercayaan aplikasi Anda, Anda dapat memperbarui database Anda untuk menggunakan sertifikat rds-ca-rsa 2048-g1. Untuk petunjuk, lihat langkah 3 dalam [Memperbarui sertifikat CA Anda dengan memodifikasi instans atau cluster DB Anda](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
# Menggunakan autentikasi Kerberos dengan Amazon RDS for PostgreSQL
Anda dapat menggunakan Kerberos untuk mengautentikasi pengguna saat terhubung ke instans DB Anda yang menjalankan PostgreSQL. Untuk melakukannya, konfigurasikan instans DB Anda untuk digunakan AWS Directory Service for Microsoft Active Directory untuk otentikasi Kerberos. AWS Directory Service for Microsoft Active Directory disebut juga AWS Managed Microsoft AD. Ini adalah fitur yang tersedia dengan Directory Service. Untuk mempelajari lebih lanjut, lihat [Apa itu Directory Service?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) dalam *Panduan AWS Directory Service Administrasi*.
Untuk memulai, buat AWS Managed Microsoft AD direktori untuk menyimpan kredensyal pengguna. Kemudian, berikan domain Active Directory dan informasi lainnya ke instans DB PostgreSQL Anda. Saat pengguna mengautentikasi dengan instans DB PostgreSQL, permintaan autentikasi diteruskan ke direktori AWS Managed Microsoft AD .
Dengan menyimpan semua kredensial Anda di direktori yang sama, Anda dapat menghemat waktu dan tenaga. Anda memiliki sebuah lokasi terpusat untuk menyimpan dan mengelola kredensial bagi beberapa instans DB. Penggunaan direktori juga dapat meningkatkan profil keamanan Anda secara keseluruhan.
Selain itu, Anda dapat mengakses kredensial dari Microsoft Active Directory on-premise Anda sendiri. Untuk melakukannya, buat hubungan domain tepercaya sehingga direktori AWS Managed Microsoft AD mempercayai Microsoft Active Directory on-premise Anda. Dengan cara ini, pengguna Anda dapat mengakses instans PostgreSQL Anda dengan pengalaman masuk tunggal (SSO) Windows yang sama seperti ketika mereka mengakses beban kerja di jaringan on-premise Anda.
Database dapat menggunakan otentikasi kata sandi atau otentikasi kata sandi dengan otentikasi Kerberos atau AWS Identity and Access Management (IAM). Untuk informasi selengkapnya tentang autentikasi IAM, lihat [Autentikasi basis data IAMuntuk MariaDB, MySQL, dan PostgreSQL](UsingWithRDS.IAMDBAuth.md).
**catatan**
RDS untuk PostgreSQL tidak mendukung otentikasi Kerberos untuk grup Active Directory.
**Topics**
+ [Ketersediaan wilayah dan versi](#postgresql-kerberos.RegionVersionAvailability)
+ [Ikhtisar autentikasi Kerberos untuk instans DB PostgreSQL](#postgresql-kerberos-overview)
+ [Menyiapkan autentikasi Kerberos untuk instans DB PostgreSQL](postgresql-kerberos-setting-up.md)
+ [Mengelola dalam domain Active Directory](postgresql-kerberos-managing.md)
+ [Menghubungkan ke PostgreSQL dengan autentikasi Kerberos](postgresql-kerberos-connecting.md)
## Ketersediaan wilayah dan versi
Ketersediaan dan dukungan fitur bervariasi di seluruh versi khusus dari setiap mesin basis data, dan di seluruh Wilayah AWS. Lihat informasi selengkapnya tentang Ketersediaan wilayah dan versi RDS for PostgreSQL dengan autentikasi Kerberos di [Wilayah dan mesin DB yang Didukung untuk otentikasi Kerberos di Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md).
## Ikhtisar autentikasi Kerberos untuk instans DB PostgreSQL
Untuk menyiapkan autentikasi Kerberos untuk instans DB PostgreSQL, lakukan langkah-langkah berikut, yang dijelaskan secara lebih mendetail nanti:
1. Gunakan AWS Managed Microsoft AD untuk membuat AWS Managed Microsoft AD direktori. Anda dapat menggunakan Konsol Manajemen AWS, AWS CLI, atau Directory Service API untuk membuat direktori. Pastikan untuk membuka port keluar yang relevan pada grup keamanan direktori sehingga direktori dapat berkomunikasi dengan instans.
1. Buat peran yang menyediakan akses RDS untuk melakukan panggilan ke direktori Anda. AWS Managed Microsoft AD Untuk melakukannya, buat peran AWS Identity and Access Management (IAM) yang menggunakan kebijakan IAM terkelola. `AmazonRDSDirectoryServiceAccess`
Agar peran IAM mengizinkan akses, titik akhir AWS Security Token Service (AWS STS) harus diaktifkan di AWS Wilayah yang benar untuk akun Anda AWS . AWS STS endpoint aktif secara default di semua Wilayah AWS, dan Anda dapat menggunakannya tanpa tindakan lebih lanjut. Untuk informasi selengkapnya, lihat [Mengaktifkan dan menonaktifkan AWS STS di AWS Wilayah di Panduan Pengguna](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) *IAM*.
1. Buat dan konfigurasikan pengguna di AWS Managed Microsoft AD direktori menggunakan alat Microsoft Active Directory. Untuk informasi selengkapnya tentang membuat pengguna di Active Directory, lihat [Mengelola pengguna dan grup di Microsoft AD yang AWS dikelola](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) di *Panduan Directory Service Administrasi*.
1. Jika Anda berencana untuk menemukan direktori dan instans DB di AWS akun yang berbeda atau virtual private cloud (VPCs), konfigurasikan peering VPC. Untuk informasi selengkapnya, lihat [Apa yang dimaksud peering VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) di *Panduan Peering Amazon VPC*.
1. Buat atau modifikasi instans DB PostgreSQL dari konsol, CLI, atau RDS API menggunakan salah satu metode berikut:
+ [Membuat instans DB Amazon RDS](USER_CreateDBInstance.md)
+ [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md)
+ [Memulihkan ke instans DB](USER_RestoreFromSnapshot.md)
+ [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md)
Anda dapat menemukan instance di Amazon Virtual Private Cloud (VPC) yang sama dengan direktori atau di akun AWS atau VPC yang berbeda. Saat membuat atau memodifikasi instans DB PostgreSQL, lakukan hal berikut:
+ Sediakan pengidentifikasi domain (pengidentifikasi `d-*`) yang dihasilkan saat Anda membuat direktori.
+ Beri nama peran IAM yang Anda buat.
+ Pastikan bahwa grup keamanan instans DB dapat menerima lalu lintas masuk dari grup keamanan direktori.
1. Gunakan kredensial pengguna utama RDS untuk terhubung ke instans DB PostgreSQL. Buat pengguna dalam PostgreSQL untuk diidentifikasi secara eksternal. Pengguna yang diidentifikasi secara eksternal dapat masuk ke instans DB PostgreSQL menggunakan autentikasi Kerberos.
# Menyiapkan autentikasi Kerberos untuk instans DB PostgreSQL
Untuk menyiapkan autentikasi Kerberos, lakukan langkah berikut.
**Topics**
+ [Langkah 1: Buat direktori menggunakan AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory)
+ [Langkah 2: (Opsional) Buat hubungan kepercayaan antara Active Directory lokal dan Directory Service](#postgresql-kerberos-setting-up.create-trust)
+ [Langkah 3: Buat peran IAM untuk RDS untuk mengakses Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole)
+ [Langkah 4: Buat dan konfigurasikan pengguna](#postgresql-kerberos-setting-up.create-users)
+ [Langkah 5: Aktifkan lalu lintas antar-VPC antara direktori dan instans DB](#postgresql-kerberos-setting-up.vpc-peering)
+ [Langkah 6: Buat atau modifikasi instans DB PostgreSQL](#postgresql-kerberos-setting-up.create-modify)
+ [Langkah 7: Buat pengguna PostgreSQL untuk pengguna utama Kerberos Anda](#postgresql-kerberos-setting-up.create-logins)
+ [Langkah 8: Konfigurasikan klien PostgreSQL](#postgresql-kerberos-setting-up.configure-client)
## Langkah 1: Buat direktori menggunakan AWS Managed Microsoft AD
Directory Service membuat Direktori Aktif yang dikelola sepenuhnya di AWS Cloud. Saat Anda membuat AWS Managed Microsoft AD direktori, Directory Service buat dua pengontrol domain dan server DNS untuk Anda. Server-server direktori dibuat di subnet yang berbeda di VPC. Redundansi ini membantu memastikan bahwa direktori Anda tetap dapat diakses meskipun terjadi kegagalan.
Saat Anda membuat AWS Managed Microsoft AD AWS direktori, Directory Service melakukan tugas-tugas berikut atas nama Anda:
+ Menyiapkan Active Directory di dalam VPC Anda.
+ Membuat akun administrator direktori dengan nama pengguna `Admin` dan kata sandi yang ditentukan. Anda menggunakan akun ini untuk mengelola direktori.
**penting**
Pastikan untuk menyimpan kata sandi ini. Directory Service tidak menyimpan kata sandi ini, dan tidak dapat diambil atau diatur ulang.
+ Membuat grup keamanan untuk pengendali direktori. Grup keamanan harus mengizinkan komunikasi dengan instans DB PostgreSQL.
Saat Anda meluncurkan AWS Directory Service for Microsoft Active Directory, AWS buat Unit Organisasi (OU) yang berisi semua objek direktori Anda. OU ini memiliki nama NetBIOS yang Anda masukkan saat membuat direktori, dan terletak di root domain. Root domain dimiliki dan dikelola oleh AWS.
`Admin`Akun yang dibuat dengan AWS Managed Microsoft AD direktori Anda memiliki izin untuk kegiatan administratif yang paling umum untuk OU Anda:
+ Membuat, memperbarui, atau menghapus pengguna
+ Menambahkan sumber daya ke domain Anda seperti server file atau cetak, lalu menetapkan izin untuk sumber daya tersebut kepada pengguna di OU Anda
+ Buat tambahan OUs dan wadah
+ Melimpahkan kewenangan
+ Memulihkan objek-objek yang dihapus dari Keranjang Sampah Active Directory
+ Jalankan modul Active Directory dan Domain Name Service (DNS) untuk Windows PowerShell pada Layanan Active Directory Web
Akun `Admin` juga memiliki hak untuk melakukan aktivitas di seluruh domain berikut:
+ Mengelola konfigurasi DNS (menambahkan, menghapus, atau memperbarui catatan, zona, dan penerus)
+ Melihat log peristiwa DNS
+ Melihat log peristiwa keamanan
**Untuk membuat direktori dengan AWS Managed Microsoft AD**
1. Di panel navigasi [konsol Directory Service](https://console.aws.amazon.com/directoryservicev2/), pilih **Direktori**, lalu pilih **Siapkan direktori**.
1. Pilih **AWS Managed Microsoft AD**. AWS Managed Microsoft AD adalah satu-satunya pilihan yang saat ini didukung untuk digunakan dengan RDS.
1. Pilih **Berikutnya**.
1. Di halaman **Masukkan informasi direktori**, berikan informasi berikut:
**Edisi**
Pilih edisi sesuai kebutuhan Anda.
**Nama DNS direktori**
Nama berkualifikasi penuh untuk direktori, seperti **corp.example.com**.
**Nama NetBIOS direktori**
Nama pendek opsional untuk direktori, seperti `CORP`.
**Deskripsi direktori**
Deskripsi opsional untuk direktori.
**Kata sandi admin**
Kata sandi administrator direktori. Proses pembuatan direktori menciptakan akun administrator dengan nama pengguna `Admin` dan kata sandi ini.
Kata sandi administrator direktori tidak boleh menyertakan kata "admin". Kata sandi peka terhadap huruf besar/kecil dan harus terdiri dari 8–64 karakter. Kata sandi juga harus berisi setidaknya satu karakter dari tiga di antara empat kategori berikut:
+ Huruf kecil (a-z)
+ Huruf besar (A-Z)
+ Angka (0–9)
+ Karakter non-alfanumerik (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**Konfirmasi kata sandi**
Ketik ulang kata sandi administrator.
Pastikan Anda menyimpan kata sandi ini. Directory Service tidak menyimpan kata sandi ini, dan tidak dapat diambil atau diatur ulang.
1. Pilih **Berikutnya**.
1. Di halaman **Pilih VPC dan subnet**, berikan informasi berikut:
**VPC**
Pilih VPC untuk direktori. Anda dapat membuat instans DB PostgreSQL dalam VPC yang sama ini atau dalam VPC yang berbeda.
**Subnet**
Pilih subnet untuk server direktori. Kedua subnet harus berada di Zona Ketersediaan yang berbeda.
1. Pilih **Berikutnya**.
1. Tinjau informasi direktori. Jika ada yang perlu diubah, pilih **Sebelumnya** dan lakukan perubahan. Jika informasi sudah benar, pilih **Buat direktori**.
![\[Halaman detail direktori\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
Pembuatan direktori memerlukan waktu beberapa menit. Setelah berhasil dibuat, nilai **Status** berubah menjadi **Aktif**.
Untuk melihat informasi tentang direktori Anda, pilih ID direktori di daftar direktori. Buat catatan tentang nilai **ID Direktori**. Anda memerlukan nilai ini saat membuat atau mengubah instans DB PostgreSQL.
![\[Gambar halaman detail\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## Langkah 2: (Opsional) Buat hubungan kepercayaan antara Active Directory lokal dan Directory Service
Jika Anda tidak berencana untuk menggunakan Microsoft Active Directory on-premise Anda sendiri, langsung ke [Langkah 3: Buat peran IAM untuk RDS untuk mengakses Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole).
Untuk mendapatkan autentikasi Kerberos menggunakan Active Directory lokal, Anda perlu membuat relasi domain kepercayaan menggunakan trust hutan antara Microsoft Active Directory lokal dan direktori (dibuat di AWS Managed Microsoft AD ). [Langkah 1: Buat direktori menggunakan AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory) Kepercayaan bisa satu arah, di mana AWS Managed Microsoft AD direktori mempercayai Microsoft Active Directory lokal. Kepercayaan juga dapat bersifat dua arah, di mana kedua Active Directory saling mempercayai. Untuk informasi selengkapnya tentang menyiapkan trust menggunakan Directory Service, lihat [Kapan membuat hubungan kepercayaan](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html) di *Panduan AWS Directory Service Administrasi*.
**catatan**
Jika Anda menggunakan Microsoft Active Directory lokal, klien Windows akan terhubung menggunakan nama domain di titik akhir, bukan Directory Service rds.amazonaws.com. Untuk mempelajari selengkapnya, lihat [Menghubungkan ke PostgreSQL dengan autentikasi Kerberos](postgresql-kerberos-connecting.md).
Pastikan bahwa nama domain Microsoft Active Directory on-premise Anda mencakup perutean akhiran DNS yang sesuai dengan hubungan kepercayaan yang baru dibuat. Tangkapan layar berikut menunjukkan sebuah contoh.
![\[Perutean DNS sesuai dengan kepercayaan yang dibuat\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/kerberos-auth-trust.png)
## Langkah 3: Buat peran IAM untuk RDS untuk mengakses Directory Service
Agar RDS memanggil Directory Service Anda, AWS akun Anda memerlukan peran IAM yang menggunakan kebijakan IAM terkelola. `AmazonRDSDirectoryServiceAccess` Peran ini membuat Amazon RDS dapat melakukan panggilan ke Directory Service.
Saat Anda membuat instans DB menggunakan Konsol Manajemen AWS dan akun pengguna konsol Anda memiliki `iam:CreateRole` izin, konsol akan membuat peran IAM yang diperlukan secara otomatis. Dalam hal ini, nama perannya adalah `rds-directoryservice-kerberos-access-role`. Jika tidak, Anda harus membuat peran IAM secara manual. Saat Anda membuat peran IAM ini, pilih`Directory Service`, dan lampirkan kebijakan AWS terkelola `AmazonRDSDirectoryServiceAccess` padanya.
Untuk informasi selengkapnya tentang membuat peran IAM untuk layanan, lihat [Membuat peran untuk mendelegasikan izin ke AWS layanan di Panduan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) Pengguna *IAM*.
**catatan**
Peran IAM yang digunakan untuk Autentikasi Windows untuk RDS for Microsoft SQL Server tidak dapat digunakan untuk Amazon RDS for PostgreSQL.
Sebagai alternatif untuk menggunakan kebijakan terkelola `AmazonRDSDirectoryServiceAccess`, Anda dapat membuat kebijakan dengan izin yang diperlukan. Dalam hal ini, peran IAM harus memiliki kebijakan kepercayaan IAM berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Peran ini juga harus memiliki kebijakan peran IAM berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Untuk keikutsertaan Wilayah AWS, gunakan prinsip layanan khusus Wilayah dalam kebijakan kepercayaan peran IAM. Saat Anda membuat kebijakan kepercayaan untuk layanan di Wilayah ini, tentukan kode Wilayah di prinsipal layanan.
Contoh berikut menunjukkan kebijakan kepercayaan yang mencakup prinsip layanan khusus Wilayah:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.REGION-CODE.amazonaws.com",
"rds.REGION-CODE.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Ganti REGION-CODE dengan kode untuk Wilayah spesifik Anda. Misalnya, gunakan prinsip layanan berikut untuk Wilayah Asia Pasifik (Melbourne):
```
"Service": [
"directoryservice.rds.ap-southeast-4.amazonaws.com",
"rds.ap-southeast-4.amazonaws.com"
]
```
## Langkah 4: Buat dan konfigurasikan pengguna
Anda dapat membuat pengguna dengan alat Active Directory Users and Computers. Alat ini merupakan salah satu alat Active Directory Domain Services dan Active Directory Lightweight Directory Services. Untuk informasi selengkapnya, lihat [Add Users and Computers to the Active Directory domain](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/create-an-active-directory-server#add-users-and-computers-to-the-active-directory-domain) dalam dokumentasi Microsoft. Dalam hal ini, pengguna adalah individu atau entitas lain, seperti komputer mereka yang merupakan bagian dari domain dan yang identitasnya dipertahankan dalam direktori.
Untuk membuat pengguna di Directory Service direktori, Anda harus terhubung ke instans Amazon EC2 berbasis Windows yang merupakan anggota direktori. Directory Service Pada saat yang sama, Anda harus masuk sebagai pengguna yang memiliki hak untuk membuat pengguna. Untuk informasi selengkapnya, lihat [Membuat pengguna](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html) dalam *Panduan Administrasi AWS Directory Service *.
## Langkah 5: Aktifkan lalu lintas antar-VPC antara direktori dan instans DB
Jika Anda ingin menemukan direktori dan instans DB dalam VPC yang sama, lewati langkah ini dan lanjutkan ke [Langkah 6: Buat atau modifikasi instans DB PostgreSQL](#postgresql-kerberos-setting-up.create-modify).
[Jika Anda berencana untuk menemukan direktori dan instans DB yang berbeda VPCs, konfigurasikan lalu lintas lintas VPC menggunakan pengintip VPC atau Transit Gateway.AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
Prosedur berikut memungkinkan lalu lintas antara VPCs menggunakan VPC peering. Ikuti petunjuk di [Apa yang dimaksud dengan peering VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) dalam *Panduan Peering Amazon Virtual Private Cloud*.
**Untuk mengaktifkan lalu lintas VPC menggunakan peering VPC**
1. Siapkan aturan perutean VPC yang sesuai untuk memastikan lalu lintas jaringan dapat berjalan dua arah.
1. Pastikan bahwa grup keamanan instans DB dapat menerima lalu lintas masuk dari grup keamanan direktori.
1. Pastikan tidak ada aturan daftar kontrol akses (ACL) jaringan yang memblokir lalu lintas.
Jika AWS akun lain memiliki direktori, Anda harus berbagi direktori.
**Untuk berbagi direktori antar AWS akun**
1. *Mulai berbagi direktori dengan AWS akun tempat instans DB akan dibuat dengan mengikuti petunjuk di [Tutorial: Berbagi direktori AD Microsoft AWS Terkelola Anda untuk Domain EC2 yang mulus-Bergabung](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) dalam Panduan Administrasi.Directory Service *
1. Masuk ke Directory Service konsol menggunakan akun untuk instans DB, dan pastikan domain memiliki `SHARED` status sebelum melanjutkan.
1. Saat masuk ke Directory Service konsol menggunakan akun untuk instans DB, perhatikan nilai **ID Direktori**. Anda menggunakan ID direktori ini untuk menggabungkan instans DB ke domain.
## Langkah 6: Buat atau modifikasi instans DB PostgreSQL
Buat atau modifikasi instans DB PostgreSQL untuk digunakan dengan direktori Anda. Anda dapat menggunakan konsol, CLI, atau RDS API untuk mengaitkan instans DB dengan direktori. Anda dapat melakukannya dengan salah satu cara berikut:
+ [Buat instance PostgreSQL DB baru menggunakan konsol, perintah [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI, atau operasi Create RDS API. DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) Untuk petunjuk, lihat [Membuat instans DB Amazon RDS](USER_CreateDBInstance.md).
+ [Ubah instance PostgreSQL DB yang ada menggunakan konsol, perintah [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI, atau operasi Modify RDS API. DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) Untuk petunjuk, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
+ [Pulihkan instans PostgreSQL DB dari snapshot DB menggunakan konsol, perintah CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html), atau operasi Restore From RDS API. DBInstance DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) Untuk petunjuk, lihat [Memulihkan ke instans DB](USER_RestoreFromSnapshot.md).
+ [Kembalikan instance PostgreSQL DB ke point-in-time menggunakan konsol, perintah [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI, atau operasi Restore RDS API. DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) Untuk petunjuk, lihat [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md).
Autentikasi Kerberos hanya didukung untuk instans DB PostgreSQL dalam sebuah VPC. Instans DB boleh berada dalam VPC yang sama dengan direktori, atau dalam VPC yang berbeda. Instans DB harus menggunakan grup keamanan yang memungkinkan ingress and egress di dalam VPC direktori, sehingga instans DB dapat berkomunikasi dengan direktori.
### Konsol
Saat Anda menggunakan konsol untuk membuat, memodifikasi, atau memulihkan instans DB, pilih **Kata sandi dan autentikasi Kerberos** di bagian **Autentikasi basis data**. Kemudian pilih **Cari Direktori**. Pilih direktori atau pilih **Buat direktori baru** untuk menggunakan Directory Service.
![\[Memilih Kerberos untuk autentikasi dan mengidentifikasi direktori yang akan digunakan.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg-authentication-use-kerberos.png)
### AWS CLI
Saat Anda menggunakan AWS CLI, parameter berikut diperlukan untuk instance DB agar dapat menggunakan direktori yang Anda buat:
+ Untuk parameter `--domain`, gunakan pengidentifikasi domain (pengidentifikasi "d-\$1") yang dihasilkan saat Anda membuat direktori.
+ Untuk parameter `--domain-iam-role-name`, gunakan peran yang Anda buat yang menggunakan kebijakan IAM terkelola `AmazonRDSDirectoryServiceAccess`.
Misalnya, perintah CLI berikut memodifikasi instans DB untuk menggunakan direktori.
```
aws rds modify-db-instance --db-instance-identifier mydbinstance --domain d-Directory-ID --domain-iam-role-name role-name
```
**penting**
Jika Anda memodifikasi instans DB untuk mengaktifkan autentikasi Kerberos, boot ulang instans DB setelah membuat perubahan.
## Langkah 7: Buat pengguna PostgreSQL untuk pengguna utama Kerberos Anda
Pada titik ini, instans DB RDS for PostgreSQL Anda digabungkan ke domain AWS Managed Microsoft AD . Pengguna yang Anda buat di direktori [Langkah 4: Buat dan konfigurasikan pengguna](#postgresql-kerberos-setting-up.create-users) perlu diatur sebagai pengguna basis data PostgreSQL dan diberi hak istimewa untuk masuk ke basis data. Anda dapat melakukannya dengan masuk sebagai pengguna basis data dengan hak istimewa `rds_superuser`. Misalnya, jika Anda menerima default saat membuat instans DB RDS for PostgreSQL, gunakan `postgres`, seperti yang ditunjukkan dalam langkah berikut.
**Untuk membuat pengguna basis data PostgreSQL untuk pengguna utama Kerberos**
1. Gunakan `psql` untuk menghubungkan ke titik akhir instans DB RDS for PostgreSQL menggunakan `psql`. Contoh berikut menggunakan akun `postgres` default untuk peran `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Buat nama pengguna basis data untuk setiap pengguna utama Kerberos (nama pengguna Active Directory) yang ingin Anda beri akses ke basis data. Gunakan nama pengguna (identitas) kanonik seperti yang didefinisikan dalam instans Active Directory, yaitu `alias` dalam huruf kecil (nama pengguna di Active Directory) dan nama domain Active Directory dalam huruf besar untuk nama pengguna tersebut. Nama pengguna Active Directory adalah pengguna yang diautentikasi secara eksternal, jadi gunakan tanda kutip pada nama ini seperti yang ditunjukkan berikut.
```
postgres=> CREATE USER "username@CORP.EXAMPLE.COM" WITH LOGIN;
CREATE ROLE
```
1. Beri peran `rds_ad` kepada pengguna basis data.
```
postgres=> GRANT rds_ad TO "username@CORP.EXAMPLE.COM";
GRANT ROLE
```
Setelah Anda selesai membuat semua pengguna PostgreSQL untuk identitas pengguna Active Directory Anda, pengguna dapat mengakses instans DB RDS for PostgreSQL menggunakan kredensial Kerberos mereka.
Diperlukan bahwa pengguna database yang mengautentikasi menggunakan Kerberos melakukannya dari mesin klien yang merupakan anggota domain Active Directory.
Pengguna basis data yang telah diberi peran `rds_ad` tidak dapat memiliki peran `rds_iam`. Aturan ini juga berlaku untuk keanggotaan bertingkat. Untuk informasi selengkapnya, lihat [Autentikasi basis data IAMuntuk MariaDB, MySQL, dan PostgreSQL](UsingWithRDS.IAMDBAuth.md).
## Langkah 8: Konfigurasikan klien PostgreSQL
Untuk mengonfigurasi klien PostgreSQL, lakukan langkah berikut:
+ Buat file krb5.conf (atau yang setara) untuk menunjuk ke domain.
+ Verifikasi bahwa lalu lintas dapat mengalir antara host klien dan Directory Service. Gunakan utilitas jaringan seperti Netcat untuk hal berikut:
+ Memeriksa lalu lintas melalui DNS untuk port 53.
+ Verifikasi lalu lintas TCP/UDP untuk port 53 dan untuk Kerberos, yang mencakup port 88 dan 464 untuk. Directory Service
+ Memastikan lalu lintas dapat mengalir di antara host klien dan instans DB melalui port basis data. Misalnya, gunakan psql untuk menghubungkan dan mengakses basis data.
Berikut ini adalah contoh konten krb5.conf untuk. AWS Managed Microsoft AD
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
```
Berikut adalah contoh konten krb5.conf untuk Microsoft Active Directory on-premise.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
ONPREM.COM = {
kdc = onprem.com
admin_server = onprem.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
.onprem.com = ONPREM.COM
onprem.com = ONPREM.COM
.rds.amazonaws.com = EXAMPLE.COM
.amazonaws.com.rproxy.goskope.com.cn = EXAMPLE.COM
.amazon.com = EXAMPLE.COM
```
# Mengelola dalam domain Active Directory
Anda dapat menggunakan konsol, CLI, atau RDS API untuk mengelola instans Anda dan hubungannya dengan Microsoft Active Directory Anda. Misalnya, Anda dapat mengaitkan Active Directory untuk mengaktifkan autentikasi Kerberos. Anda juga dapat menghapus pengaitan Active Directory untuk menonaktifkan autentikasi Kerberos. Anda juga dapat memindahkan instans DB untuk diautentikasi secara eksternal oleh satu Microsoft Active Directory ke yang lain.
Misalnya, dengan CLI, Anda dapat melakukan hal berikut:
+ Untuk mencoba kembali mengaktifkan otentikasi Kerberos untuk keanggotaan yang gagal, gunakan perintah CLI. [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) Tentukan ID direktori keanggotaan saat ini untuk opsi `--domain`.
+ Untuk menonaktifkan otentikasi Kerberos pada instance DB, gunakan perintah CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). Tentukan `none` untuk opsi `--domain`.
+ Untuk memindahkan instance DB dari satu domain ke domain lainnya, gunakan perintah [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI. Tentukan pengidentifikasi domain dari domain baru untuk opsi `--domain`.
## Memahami keanggotaan Domain
Setelah Anda membuat atau memodifikasi instans DB, klaster DB menjadi anggota domain. Anda dapat melihat status keanggotaan domain di konsol atau dengan menjalankan perintah [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI. Status instans DB dapat berupa salah satu dari daftar berikut:
+ `kerberos-enabled` – Instans basis data telah mengaktifkan autentikasi Kerberos.
+ `enabling-kerberos`— AWS sedang dalam proses mengaktifkan otentikasi Kerberos pada instance DB ini.
+ `pending-enable-kerberos` – Aktivasi autentikasi Kerberos pada instans DB ini tertunda.
+ `pending-maintenance-enable-kerberos`— AWS akan mencoba mengaktifkan otentikasi Kerberos pada instans DB selama jendela pemeliharaan terjadwal berikutnya.
+ `pending-disable-kerberos` – Penonaktifan autentikasi Kerberos pada instans DB ini tertunda.
+ `pending-maintenance-disable-kerberos`— AWS akan mencoba menonaktifkan otentikasi Kerberos pada instans DB selama jendela pemeliharaan terjadwal berikutnya.
+ `enable-kerberos-failed`— Masalah konfigurasi dicegah AWS dari mengaktifkan otentikasi Kerberos pada instans DB. Perbaiki masalah konfigurasi tersebut sebelum menerbitkan ulang perintah untuk memodifikasi instans DB.
+ `disabling-kerberos`— AWS sedang dalam proses menonaktifkan otentikasi Kerberos pada instance DB ini.
Permintaan untuk mengaktifkan autentikasi Kerberos dapat gagal karena masalah koneksi jaringan atau kesalahan peran IAM. Dalam beberapa kasus, upaya untuk mengaktifkan autentikasi Kerberos mungkin gagal saat Anda membuat atau memodifikasi instans DB. Jika demikian, pastikan Anda menggunakan peran IAM yang benar, kemudian ubah instans DB untuk bergabung ke domain.
**catatan**
Hanya autentikasi Kerberos dengan RDS for PostgreSQL yang mengirimkan lalu lintas ke server DNS domain. Semua permintaan DNS lainnya diperlakukan sebagai akses jaringan keluar pada instans DB Anda yang menjalankan PostgreSQL. Untuk informasi selengkapnya tentang akses jaringan keluar dengan RDS for PostgreSQL, lihat [Menggunakan server DNS kustom untuk akses jaringan keluar](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md).
# Menghubungkan ke PostgreSQL dengan autentikasi Kerberos
Anda dapat terhubung ke PostgreSQL dengan autentikasi Kerberos, antarmuka pgAdmin, atau antarmuka baris perintah seperti psql. Untuk informasi selengkapnya tentang cara menghubungkan, lihat [Menghubungkan ke instans DB yang menjalankan mesin basis data PostgreSQL](USER_ConnectToPostgreSQLInstance.md) . Untuk informasi tentang mendapatkan titik akhir, nomor port, dan detail lain yang diperlukan untuk koneksi, lihat [Terhubung ke instans DB PostgreSQL](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md#CHAP_GettingStarted.Connecting.PostgreSQL).
**catatan**
Otentikasi dan enkripsi GSSAPI di PostgreSQL diimplementasikan oleh perpustakaan Kerberos. `libkrb5.so` Fitur seperti `postgres_fdw` dan `dblink` juga mengandalkan perpustakaan yang sama ini untuk koneksi keluar dengan otentikasi atau enkripsi Kerberos.
## pgAdmin
Untuk menggunakan pgAdmin untuk terhubung ke PostgreSQL dengan autentikasi Kerberos, lakukan langkah berikut:
1. Luncurkan aplikasi pgAdmin di komputer klien Anda.
1. Pada tab **Dasbor**, pilih **Tambahkan Server Baru**.
1. Di kotak dialog **Buat - Server**, masukkan nama pada tab **Umum** untuk mengidentifikasi server di pgAdmin.
1. Pada tab **Koneksi**, masukkan informasi berikut dari basis data RDS for PostgreSQL Anda.
+ Untuk **Host**, masukkan titik akhir untuk . Instans DB RDS for PostgreSQL. Titik akhir terlihat seperti berikut ini:
```
RDS-DB-instance.111122223333.aws-region.rds.amazonaws.com
```
Untuk menyambung ke Microsoft Active Directory lokal dari klien Windows, Anda menggunakan nama domain Direktori Aktif AWS Terkelola, bukan `rds.amazonaws.com` di titik akhir host. Misalnya, misalkan nama domain untuk AWS Managed Active Directory adalah`corp.example.com`. Kemudian untuk **Host**, titik akhir akan ditentukan sebagai berikut:
```
RDS-DB-instance.111122223333.aws-region.corp.example.com
```
+ Untuk **Port**, masukkan port yang ditetapkan.
+ Untuk **Basis data pemeliharaan**, masukkan nama basis data awal yang akan dihubungkan ke klien.
+ Untuk **Nama pengguna**, masukkan nama pengguna yang Anda masukkan untuk autentikasi Kerberos di [Langkah 7: Buat pengguna PostgreSQL untuk pengguna utama Kerberos Anda](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
1. Pilih **Simpan**.
## Psql
Untuk menggunakan psql untuk terhubung ke PostgreSQL dengan autentikasi Kerberos, lakukan langkah berikut:
1. Pada jendela perintah, jalankan perintah berikut.
```
kinit username
```
Ganti *`username`* dengan nama pengguna. Saat diminta, masukkan kata sandi yang disimpan dalam Microsoft Active Directory untuk pengguna.
1. Jika instans DB PostgreSQL menggunakan VPC yang dapat diakses publik, masukkan alamat IP untuk titik akhir instans DB di file `/etc/hosts` Anda pada klien EC2. Misalnya, perintah berikut mendapatkan alamat IP lalu memasukkannya ke dalam file `/etc/hosts`.
```
% dig +short PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com
;; Truncated, retrying in TCP mode.
ec2-34-210-197-118.AWS-Region.compute.amazonaws.com.
34.210.197.118
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com" >> /etc/hosts
```
Jika Anda menggunakan Microsoft Active Directory on-premise dari klien Windows, Anda perlu terhubung menggunakan titik akhir khusus. Alih-alih menggunakan domain Amazon `rds.amazonaws.com` di titik akhir host, gunakan nama domain Direktori Aktif AWS Terkelola.
Misalnya, misalkan nama domain untuk Direktori Aktif AWS Terkelola Anda adalah`corp.example.com`. Kemudian gunakan format `PostgreSQL-endpoint.AWS-Region.corp.example.com` untuk titik akhir dan masukkan ke dalam file `/etc/hosts`.
```
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.corp.example.com" >> /etc/hosts
```
1. Gunakan perintah psql berikut untuk masuk ke instans DB PostgreSQL yang terintegrasi dengan Active Directory.
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com postgres
```
Untuk masuk ke klaster DB PostgreSQL dari klien Windows menggunakan Active Directory on-premise, gunakan perintah psql berikut dengan nama domain dari langkah sebelumnya (`corp.example.com`):
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.corp.example.com postgres
```
# Menggunakan server DNS kustom untuk akses jaringan keluar
Amazon RDS for PostgreSQL mendukung akses jaringan keluar di instans DB Anda dan mengizinkan resolusi Layanan Nama Domain (DNS) dari server DNS kustom yang dimiliki pelanggan. Anda hanya dapat menyelesaikan nama domain yang benar-benar memenuhi syarat dari instans DB RDS for PostgreSQL melalui server DNS kustom.
**Topics**
+ [Mengaktifkan resolusi DNS kustom](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Enable)
+ [Menonaktifkan resolusi DNS kustom](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Disable)
+ [Menyiapkan server DNS kustom](#Appendix.Oracle.CommonDBATasks.CustomDNS.Setup)
## Mengaktifkan resolusi DNS kustom
Untuk mengaktifkan resolusi DNS di VPC pelanggan Anda, pertama-tama kaitkan grup parameter DB kustom ke instans RDS for PostgreSQL. Kemudian nyalakan parameter `rds.custom_dns_resolution` dengan mengaturnya ke 1, lalu mulai ulang instans DB agar perubahan terjadi.
## Menonaktifkan resolusi DNS kustom
Untuk menonaktifkan resolusi DNS di VPC pelanggan Anda, matikan parameter `rds.custom_dns_resolution` dari grup parameter DB kustom dengan mengaturnya ke 0. Kemudian mulai ulang instans DB agar perubahan terjadi.
## Menyiapkan server DNS kustom
Setelah Anda menyiapkan nama server DNS, tunggu selama 30 menit hingga proses menyebarkan perubahan ke instans DB Anda selesai. Setelah perubahan diterapkan ke instans DB Anda, semua lalu lintas jaringan keluar memerlukan kueri pencarian DNS melalui port 53.
**catatan**
Jika Anda tidak menyiapkan server DNS kustom dan `rds.custom_dns_resolution` diatur ke 1, host akan diselesaikan menggunakan zona pribadi Amazon Route 53. Untuk informasi selengkapnya, lihat [Menggunakan zona yang di-hosting pribadi](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html).
**Untuk menyiapkan server DNS kustom untuk instans DB RDS for PostgreSQL**
1. Dari opsi Protokol Konfigurasi Host Dinamis (DHCP) yang dipasang ke VPC, atur opsi `domain-name-servers` ke alamat IP dari server nama DNS Anda. Untuk informasi selengkapnya, lihat [Set pilihan DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).
**catatan**
Opsi `domain-name-servers` menerima hingga empat nilai, tetapi instans DB Amazon RDS Anda hanya menggunakan nilai pertama.
1. Pastikan bahwa server DNS Anda dapat menyelesaikan semua kueri pencarian, termasuk nama DNS publik, nama DNS privat Amazon EC2, dan nama DNS khusus pelanggan. Jika lalu lintas jaringan keluar memuat setiap pencarian DNS yang tidak dapat ditangani server DNS Anda, server DNS Anda harus dikonfigurasikan oleh penyedia DNS hulu yang sesuai.
1. Konfigurasikan server DNS Anda untuk menghasilkan respons Protokol Datagram Pengguna (UDP) sebesar 512 byte atau kurang dari jumlah tersebut.
1. Konfigurasikan server DNS Anda untuk menghasilkan respons Protokol Kontrol Transmisi (TCP) sebesar 1024 byte atau kurang dari jumlah tersebut.
1. Konfigurasikan server DNS Anda agar lalu lintas dapat masuk dari instans DB Amazon RDS melalui port 53. Jika server DNS Anda berada di Amazon VPC, VPC harus memiliki grup keamanan yang berisi aturan masuk yang memungkinkan lalu lintas UDP dan TCP di port 53. Jika server DNS Anda tidak berada di Amazon VPC, VPC harus memiliki pengaturan firewall yang sesuai untuk memungkinkan lalu lintas masuk UDP dan TCP di port 53.
Untuk informasi lebih lanjut, lihat [Grup keamanan untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) serta [Menambahkan dan menghapus aturan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules).
1. Konfigurasikan VPC dari instans DB Amazon RDS agar lalu lintas keluar dapat melalui port 53. VPC Anda harus memiliki grup keamanan yang berisi aturan keluar yang memungkinkan lalu lintas UDP dan TCP di port 53.
Untuk informasi selengkapnya, lihat [Grup keamanan untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) serta [Menambahkan dan menghapus aturan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules) di *Panduan Pengguna Amazon VPC*.
1. Pastikan jalur perutean antara instans DB Amazon RDS dan server DNS dikonfigurasi dengan benar untuk memungkinkan lalu lintas DNS.
Selain itu, jika instans DB Amazon RDS dan server DNS tidak berada dalam VPC yang sama, pastikan koneksi peering disiapkan di antara keduanya. Untuk informasi selengkapnya, lihat [Apa yang dimaksud peering VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) di *Panduan Peering Amazon VPC*.
# Upgrade RDS untuk mesin PostgreSQL DB
Ada dua jenis peningkatan yang dapat Anda kelola untuk basis data PostgreSQL Anda:
+ Pembaruan sistem operasi – Terkadang, Amazon RDS mungkin perlu memperbarui sistem operasi yang mendasari basis data Anda untuk menerapkan perbaikan keamanan atau perubahan OS. Anda dapat memutuskan kapan Amazon RDS menerapkan pembaruan OS dengan menggunakan konsol RDS, AWS Command Line Interface (AWS CLI), atau RDS API. Untuk informasi selengkapnya tentang pembaruan OS, lihat [Menerapkan pembaruan ke instans DB](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).
+ Peningkatan mesin basis data – Ketika Amazon RDS mendukung versi baru mesin basis data, Anda dapat meningkatkan basis data Anda ke versi baru.
Sebuah *basis data* dalam konteks ini adalah instans DB atau klaster DB Multi-AZ RDS for PostgreSQL.
Ada dua jenis peningkatan mesin untuk basis data PostgreSQL: peningkatan versi mayor dan peningkatan versi minor.
**Peningkatan versi mayor**
*Peningkatan versi mayor* dapat berisi perubahan basis data yang tidak memiliki kompatibilitas mundur dengan aplikasi yang ada. Oleh karena itu, Anda harus melakukan peningkatan versi mayor untuk basis data Anda secara manual. Anda dapat memulai peningkatan versi mayor dengan memodifikasi instans DB atau klaster DB Multi-AZ. Sebelum Anda melakukan peningkatan versi mayor, kami sarankan agar Anda mengikuti langkah-langkah yang dijelaskan dalam [Memilih versi utama untuk RDS untuk upgrade PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
Amazon RDS menangani peningkatan versi utama Multi-AZ dengan cara berikut:
+ **Penerapan instans DB multi-AZ** — Amazon RDS secara bersamaan meningkatkan instans utama dan instans siaga apa pun. Database Anda mungkin tidak tersedia selama beberapa menit saat pemutakhiran selesai.
+ **Penerapan klaster DB multi-AZ** — Amazon RDS secara bersamaan meningkatkan instans pembaca dan penulis. Database Anda mungkin tidak tersedia selama beberapa menit saat pemutakhiran selesai.
Jika Anda memutakhirkan instans DB yang memiliki replika baca In-region, Amazon RDS akan meningkatkan replika bersama dengan instans DB utama.
Amazon RDS tidak meningkatkan replika baca klaster DB Multi-AZ. Jika Anda melakukan peningkatan versi mayor klaster DB Multi-AZ, maka status replikasi replika bacanya berubah menjadi **diakhiri**. Anda harus menghapus dan membuat ulang replika baca secara manual setelah peningkatan selesai.
Anda dapat meminimalkan waktu henti yang diperlukan untuk peningkatan versi utama dengan menggunakan blue/green penerapan. Untuk informasi selengkapnya, lihat [Menggunakan Amazon RDS Blue/Green Aurora Deployment untuk pembaruan database](blue-green-deployments.md).
**Peningkatan versi minor**
Sebaliknya, tingkatkan* versi minor* hanya menyertakan perubahan yang kompatibel dengan aplikasi yang ada. Anda dapat memulai peningkatan versi minor secara manual dengan memodifikasi basis data Anda. Atau, Anda dapat mengaktifkan opsi **pemutakhiran versi minor otomatis** saat membuat atau memodifikasi database. Tindakan ini akan membuat Amazon RDS secara otomatis meningkatkan basis data Anda setelah menguji dan menyetujui versi baru.
Amazon RDS menangani peningkatan versi minor Multi-AZ dengan cara berikut:
+ **Penerapan instans DB multi-AZ** — Amazon RDS secara bersamaan meningkatkan instans utama dan instans siaga apa pun. Database Anda mungkin tidak tersedia selama beberapa menit saat pemutakhiran selesai.
+ **Penerapan klaster DB multi-AZ** — Amazon RDS meningkatkan instans DB pembaca satu per satu. Kemudian, salah satu instans basis data pembaca beralih menjadi instans basis data penulis baru. Amazon RDS kemudian meningkatkan instans penulis lama (yang sekarang menjadi instans pembaca). Klaster DB Multi-AZ biasanya mengurangi waktu henti peningkatan versi minor menjadi sekitar 35 detik. Ketika digunakan dengan RDS Proxy, mereka dapat mengurangi downtime menjadi satu detik atau kurang. Untuk informasi selengkapnya, lihat [Proksi Amazon RDS Aurora](rds-proxy.md). [Sebagai alternatif, Anda dapat menggunakan proxy database open source seperti [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/),, atau Advanced JDBC [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)Wrapper Driver.AWS](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/)
Jika database Anda telah membaca replika, Anda harus terlebih dahulu memutakhirkan semua replika baca sebelum Anda memutakhirkan instance sumber atau cluster.
Untuk informasi selengkapnya, lihat [Upgrade versi minor otomatis untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md). Untuk informasi tentang melakukan peningkatan versi minor secara manual, lihat [Meningkatkan versi mesin secara manual](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Untuk informasi selengkapnya tentang versi mesin database dan kebijakan untuk menghentikan versi mesin database, lihat [Versi Mesin Database](https://aws.amazon.com/rds/faqs/#Database_Engine_Versions) di Amazon RDS. FAQs
**Topics**
+ [Pertimbangan untuk upgrade PostgreSQL](#USER_UpgradeDBInstance.PostgreSQL.Considerations)
+ [Menemukan target peningkatan yang valid](#USER_UpgradeDBInstance.PostgreSQL.FindingTargets)
+ [Nomor versi PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.VersionID.md)
+ [Nomor versi RDS di RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.rds.version.md)
+ [Memilih versi utama untuk RDS untuk upgrade PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [Cara melakukan upgrade versi utama untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)
+ [Upgrade versi minor otomatis untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md)
+ [Meningkatkan SQL ekstensi Postgre untuk database Postgre RDS SQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)
+ [Memantau RDS untuk upgrade mesin PostgreSQL dengan acara](USER_UpgradeDBInstance.PostgreSQL.Monitoring.md)
## Pertimbangan untuk upgrade PostgreSQL
[Untuk memutakhirkan database Anda dengan aman, Amazon RDS menggunakan `pg_upgrade` utilitas yang dijelaskan dalam dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/pgupgrade.html)
Amazon RDS mengambil dua snapshot DB selama proses peningkatan jika periode retensi cadangan Anda lebih besar dari 0. Snapshot DB pertama adalah snapshot dari basis data sebelum perubahan peningkatan dibuat. Jika peningkatan gagal untuk basis data Anda, Anda dapat memulihkan snapshot ini untuk membuat basis data yang menjalankan versi lama. Snapshot DB kedua diambil setelah peningkatan selesai. Snapshot DB ini dihapus secara otomatis setelah periode retensi cadangan berakhir.
**catatan**
Amazon RDS mengambil snapshot DB selama proses peningkatan hanya jika Anda telah mengatur periode retensi cadangan untuk basis data Anda ke angka yang lebih besar dari 0. Untuk mengubah periode retensi cadangan untuk DB, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md). Anda tidak dapat mengonfigurasi periode retensi cadangan kustom untuk klaster DB Multi-AZ.
Saat Anda melakukan peningkatan versi mayor pada instans DB, setiap replika baca dalam Wilayah juga otomatis ditingkatkan. Setelah alur kerja peningkatan dimulai, replika baca menunggu `pg_upgrade` untuk berhasil diselesaikan pada instans DB primer. Kemudian, tingkatkan instans DB primer menunggu peningkatan replika baca selesai. Anda akan mengalami pemadaman hingga peningkatan selesai. Saat Anda melakukan peningkatan versi mayor klaster DB Multi-AZ, status replikasi replika bacanya berubah menjadi **diakhiri**.
Setelah peningkatan selesai, Anda tidak dapat kembali ke versi mesin DB yang lebih lama. Jika Anda ingin kembali ke versi yang lebih lama, pulihkan snapshot DB yang diambil sebelum peningkatan untuk membuat basis data baru.
## Menemukan target peningkatan yang valid
Bila Anda menggunakan Konsol Manajemen AWS untuk meng-upgrade database, ini menunjukkan target upgrade valid untuk database. Anda juga dapat menggunakan AWS CLI perintah berikut untuk mengidentifikasi target pemutakhiran yang valid untuk database:
Untuk Linux, macOS, atau Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version version-number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Untuk Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Misalnya, untuk mengidentifikasi target pemutakhiran yang valid untuk database PostgreSQL versi 16.1, jalankan perintah berikut: AWS CLI
Untuk Linux, macOS, atau Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Untuk Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# Nomor versi PostgreSQL
Urutan penomoran versi untuk mesin basis data PostgreSQL adalah sebagai berikut:
+ *Untuk PostgreSQL versi 10 dan lebih tinggi, nomor versi mesin dalam bentuk major.minor.* Nomor versi mayor adalah bagian bilangan bulat dari nomor versi. Nomor versi minor adalah bagian pecahan dari nomor versi.
Peningkatan versi mayor akan meningkatkan bagian bilangan bulat dari nomor versi, seperti peningkatan dari 10.*minor* ke 11.*minor*.
+ *Untuk versi PostgreSQL yang lebih rendah dari 10, nomor versi mesin dalam bentuk major.major.minor.* Nomor versi mesin mayor adalah bagian bilangan bulat dan pecahan pertama dari nomor versi. Misalnya, 9.6 adalah versi mayor. Nomor versi minor adalah bagian ketiga dari nomor versi. Misalnya, untuk versi 9.6.12, angka 12 adalah nomor versi minor.
Peningkatan versi mayor akan meningkatkan bagian mayor dari nomor versi. Misalnya, tingkatkan dari *9.6*.12 ke 11.14 adalah peningkatan versi mayor, dengan *9.6* dan *11* adalah nomor versi mayor.
Untuk informasi tentang penomoran versi RDS Extended Support, lihat. [Penamaan versi Amazon RDS Extended Support](extended-support-versions.md#extended-support-naming)
# Nomor versi RDS di RDS untuk PostgreSQL
Nomor versi RDS menggunakan skema penamaan `major.minor.patch`. Versi patch RDS mencakup perbaikan bug penting yang ditambahkan ke versi minor setelah dirilis. Untuk informasi tentang penomoran versi RDS Extended Support, lihat. [Penamaan versi Amazon RDS Extended Support](extended-support-versions.md#extended-support-naming)
Untuk mengidentifikasi nomor versi Amazon RDS untuk basis data Anda, Anda harus terlebih dahulu membuat ekstensi `rds_tools` dengan menggunakan perintah berikut:
```
CREATE EXTENSION rds_tools;
```
Mulai dari rilis PostgreSQL versi 15.2-R2, Anda dapat mengetahui nomor versi RDS untuk basis data RDS for PostgreSQL Anda dengan kueri SQL berikut:
```
postgres=> SELECT rds_tools.rds_version();
```
Misalnya, mengueri basis data RDS for PostgreSQL 15.2 akan menampilkan hal berikut:
```
rds_version
----------------
15.2.R2
(1 row)
```
# Memilih versi utama untuk RDS untuk upgrade PostgreSQL
Peningkatan versi mayor dapat berisi perubahan yang tidak memiliki kompatibilitas mundur dengan versi basis data yang lebih lama. Fungsi baru dapat menyebabkan aplikasi yang ada berhenti berfungsi dengan benar. Untuk alasan ini, Amazon RDS tidak menerapkan peningkatan versi mayor secara otomatis. Untuk melakukan peningkatan versi mayor, ubah basis data Anda secara manual. Pastikan bahwa Anda menguji secara menyeluruh setiap peningkatan untuk memverifikasi bahwa aplikasi Anda berfungsi dengan benar sebelum menerapkan peningkatan ke basis data produksi Anda. Saat Anda melakukan peningkatan versi mayor PostgreSQL, kami sarankan agar Anda mengikuti langkah yang dijelaskan dalam [Cara melakukan upgrade versi utama untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Saat Anda meningkatkan instans DB AZ Tunggal atau deployment instans DB Multi-AZ PostgreSQL ke versi mayor berikutnya, replika baca apa pun yang terkait dengan basis data ini juga akan ditingkatkan ke versi mayor berikutnya. Dalam beberapa kasus, Anda dapat melompat ke versi mayor yang lebih tinggi saat meningkatkan. Jika peningkatan Anda melewati sebuah versi mayor, replika baca juga akan ditingkatkan ke versi mayor target tersebut. Peningkatan ke versi 11 yang melewati versi mayor lainnya akan memiliki batasan tertentu. Anda dapat menemukan detailnya dalam langkah-langkah yang dijelaskan dalam [Cara melakukan upgrade versi utama untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Sebagian besar ekstensi PostgreSQL tidak ditingkatkan selama peningkatan mesin PostgreSQL. Hal ini harus ditingkatkan secara terpisah. Untuk informasi selengkapnya, lihat [Meningkatkan SQL ekstensi Postgre untuk database Postgre RDS SQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
Anda dapat mengetahui versi utama mana yang tersedia untuk database RDS untuk PostgreSQL Anda dengan menjalankan kueri berikut: AWS CLI
```
aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Tabel berikut merangkum hasil kueri ini untuk semua versi yang tersedia. Tanda bintang (\$1) pada nomor versi berarti bahwa versi tidak lagi didukung. Jika versi Anda saat ini tidak didukung, kami sarankan Anda meningkatkan ke target pemutakhiran versi minor terbaru atau ke salah satu target pemutakhiran lain yang tersedia untuk versi tersebut.
| Versi sumber saat ini | Target peningkatan |
| --- | --- |
| 17.6 | Tidak ada |
| 17.5 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 17.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) |
| 17.3\$1, 17.2 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) |
| 17.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) |
| 16.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 16.9 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 16.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, 16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) |
| 16.7\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.7 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.6 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16,5\$1, 16,4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16.3 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16.2\$1, 16.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) |
| 15.14 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 15.13 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, 16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 15.12, 15.11\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, 15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) |
| 15.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) |
| 15.9\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.7 | [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159) |
| 15.6\$1, 15.5\$1, 15.4\$1, 15.3\$1, 15.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) |
| 14.19 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 14.18 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, 16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, 15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 14.17, 14.16\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, 14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) |
| 14.15 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) |
| 14.14\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14.13 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14.12 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) |
| 14.11\$1, 14.10\$1, 14.9\$1, 14.8\$1, 14.7\$1, 14.6\$1, 14.5\$1, 14.4\$1, 14.3\$1, 14.2\$1, 14.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) |
| 13.22 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 13.21 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, 16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, 15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, 14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) |
| 13.20, 13.19\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, 13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 13.18, 13.17\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, [13.21, 13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) |
| 13.16 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) |
| 13.15 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)[, 15,7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317) |
| 13.14\$1, 13.13\$1, 13.12\$1, 13.11\$1, 13.10\$1, 13.9\$1, 13.8\$1, 13.7\$1, 13.6\$1, 13.5\$1, 13.4\$1, 13.3\$1, 13.2\$1, 13.2\$1, 13.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) |
| 12.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, 16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, 15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, 14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, 13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 12.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, [13.21, 13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.22, 12.21\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, [13.21, 13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22-rds.20250220, [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.20\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22, 12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)[, [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.19\$1, 12.18\$1, 12.17\$1, 12.16\$1, 12.15\$1, 12.14\$1, 12.13\$1, 12.12\$1, 12.11\$1, 12.10\$1, 12.9\$1, 12.8\$1, 12.7\$1, 12.6\$1, 12.5\$1, 12.4\$1, 12.3\$1, 12.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22, 12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)[, [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, 17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, 16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, 15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, 14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, 13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)[, [16.9, 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)[, [15.13, 15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)[, [14.18, 14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)[, [13.21, 13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250220, [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22-rds.20240509 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22, 12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)[, [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808) |
| 11.22, 11.21\$1, 11.20\$1, 11.19\$1, 11.18\$1, 11.17\$1, 11.16\$1, 11.15\$1, 11.14\$1, 11.13\$1, 11.12\$1, 11.11\$1, 11.10\$1, 11.9\$1, 11.8\$1, 11.7\$1, 11.6\$1, 11.5\$1, 11.4\$1, 11.2\$1, 11.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)[, [17.5, 17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22, 12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)[, [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240418, 11.22-rds.20240509, 11.22-rds.20240808, 11.22-rds.20241121, 11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240418) [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509) |
\$1 Versi ini tidak lagi didukung.
# Cara melakukan upgrade versi utama untuk RDS untuk PostgreSQL
Kami merekomendasikan proses berikut saat melakukan peningkatan versi mayor pada basis data Amazon RDS for PostgreSQL:
1. **Siapkan grup parameter yang kompatibel dengan versi** – Jika Anda menggunakan grup parameter kustom, Anda memiliki dua opsi. Anda dapat menentukan grup parameter default untuk versi mesin DB baru. Atau Anda dapat membuat grup parameter kustom Anda sendiri untuk versi mesin DB baru. Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md) dan [Menggunakan grup parameter klaster DB untuk klaster DB Multi-AZ](USER_WorkingWithDBClusterParamGroups.md).
1. **Periksa kelas basis data yang tidak didukung** – Periksa apakah kelas instans basis data Anda kompatibel dengan versi PostgreSQL yang menjadi target peningkatan Anda. Untuk informasi selengkapnya, lihat [Mesin DB yang didukung untuk kelas instans DB](Concepts.DBInstanceClass.Support.md).
1. **Periksa penggunaan yang tidak didukung:**
+ **Transaksi yang disiapkan** – Komit atau rollback semua transaksi terbuka yang disiapkan sebelum mencoba melakukan peningkatan.
Anda dapat menggunakan kueri berikut untuk memverifikasi bahwa tidak ada transaksi terbuka yang disiapkan pada basis data Anda.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ **Jenis data reg\$1** – Hapus semua penggunaan jenis data *reg\$1* sebelum mencoba peningkatan. Kecuali untuk `regtype` dan `regclass`, Anda tidak dapat meningkatkan jenis data *reg\$1*. Utilitas `pg_upgrade` tidak dapat mempersistensi jenis data ini, yang digunakan oleh Amazon RDS untuk melakukan peningkatan.
Untuk memverifikasi bahwa jenis data *reg\$1* yang tidak didukung tidak digunakan, gunakan kueri berikut untuk setiap basis data.
```
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
WHERE c.oid = a.attrelid
AND NOT a.attisdropped
AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
'pg_catalog.regprocedure'::pg_catalog.regtype,
'pg_catalog.regoper'::pg_catalog.regtype,
'pg_catalog.regoperator'::pg_catalog.regtype,
'pg_catalog.regconfig'::pg_catalog.regtype,
'pg_catalog.regdictionary'::pg_catalog.regtype)
AND c.relnamespace = n.oid
AND n.nspname NOT IN ('pg_catalog', 'information_schema');
```
1. **Periksa database yang tidak valid:**
+ Pastikan tidak ada database yang tidak valid. `datconnlimit`Kolom dalam `pg_database` katalog mencakup nilai `-2` untuk menandai database sebagai tidak valid yang terputus selama operasi. `DROP DATABASE`
Gunakan kueri berikut untuk memeriksa database yang tidak valid:
```
SELECT datname FROM pg_database WHERE datconnlimit = - 2;
```
+ Query sebelumnya mengembalikan nama database yang tidak valid. Anda dapat menggunakan `DROP DATABASE invalid_db_name;` untuk menjatuhkan database yang tidak valid. Anda juga dapat menggunakan perintah berikut untuk menjatuhkan database yang tidak valid:
```
SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec
```
Untuk informasi selengkapnya tentang database yang tidak valid, lihat [Memahami perilaku autovacuum dengan database yang](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/appendix.postgresql.commondbatasks.autovacuumbehavior.html) tidak valid.
1. **Tangani slot replikasi logis** – Peningkatan tidak dapat terjadi jika basis data memiliki slot replikasi logis. Slot replikasi logis biasanya digunakan untuk migrasi AWS DMS dan untuk mereplikasi tabel dari basis data ke danau data, alat BI, dan target lainnya. Sebelum meningkatkan, pastikan Anda mengetahui tujuan dari setiap slot replikasi logis yang digunakan, dan konfirmasikan bahwa menghapusnya tidak akan jadi masalah. Jika slot replikasi logis masih digunakan, Anda tidak boleh menghapusnya, dan Anda tidak dapat melakukan peningkatan.
Jika slot replikasi logis tidak diperlukan, Anda dapat menghapusnya menggunakan SQL berikut:
```
SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);
```
Pengaturan replikasi logis yang menggunakan ekstensi `pglogical` juga harus dihapus beberapa slotnya agar peningkatan versi mayor berhasil dilakukan. Untuk informasi tentang cara mengidentifikasi dan menghapus slot yang dibuat menggunakan ekstensi `pglogical`, lihat [Mengelola slot replikasi logis untuk untuk PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
Pada versi sumber 17 dan yang lebih baru, slot replikasi logis non-read-replicas dapat dipertahankan melalui peningkatan. Slot replikasi logis yang dibuat pada replika baca tidak dipertahankan melalui peningkatan.
Pastikan bahwa semua transaksi dan pesan decoding logis telah dikonsumsi dari slot sebelum memulai upgrade. Jika ada file log write-ahead (WAL) yang tidak dikonsumsi yang dipegang oleh slot replikasi logis, pemutakhiran akan gagal dengan pesan yang mengidentifikasi slot masalah. Lihat dokumentasi [PostgreSQL untuk rincian](https://www.postgresql.org/docs/current/logical-replication-upgrade.html) lebih lanjut.
Pada cluster multi-AZ dengan versi sumber lebih awal dari 17.8 atau 18.2, pastikan itu dinonaktifkan. `flow_control` Untuk informasi selengkapnya, lihat [Menghidupkan dan mematikan kontrol aliran untuk klaster DB multi-AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-replica-lag). Anda dapat mematikan kontrol aliran dengan menghapus ekstensi dari `shared_preload_libraries` dan mem-boot ulang instans basis data Anda.
1. **Tangani replika baca** – Peningkatan instans DB AZ Tunggal atau deployment instans DB Multi-AZ juga akan meningkatkan replika baca dalam Wilayah bersama instans DB primer. Amazon RDS tidak meningkatkan replika baca klaster DB Multi-AZ.
Anda tidak dapat meningkatkan replika baca secara terpisah. Jika Anda bisa, hal ini dapat menyebabkan situasi ketika basis data primer dan replika memiliki perbedaan versi mayor PostgreSQL. Namun, tingkatkan replika baca dapat menambah waktu henti pada instans DB primer. Untuk mencegah peningkatan replika, promosikan replika menjadi instans mandiri atau hapus replika tersebut sebelum memulai proses peningkatan.
Proses peningkatan membuat ulang grup parameter replika baca berdasarkan grup parameter saat ini dari replika baca. Anda dapat menerapkan grup parameter kustom ke replika baca hanya setelah peningkatan selesai dengan memodifikasi replika baca. Untuk informasi selengkapnya tentang replika baca, lihat [Menggunakan replika baca untuk Amazon RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
1. **Menangani objek besar** — Di PostgreSQL, objek besar (juga dikenal BLOBs sebagai) digunakan untuk menyimpan dan mengelola objek biner besar (seperti file, gambar, video, dll.) yang lebih besar dari ukuran maksimum yang diizinkan untuk tipe data kolom biasa. Untuk informasi selengkapnya lihat dokumentasi [Objek Besar PostgreSQL](https://www.postgresql.org/docs/current/largeobjects.html).
Upgrade dapat kehabisan memori dan gagal jika ada jutaan objek besar dan instance tidak dapat menanganinya selama peningkatan. Proses upgrade versi utama PostgreSQL terdiri dari dua fase luas: membuang skema melalui pg\$1dump dan memulihkannya melalui pg\$1restore. Jika database Anda memiliki jutaan objek besar, Anda perlu memastikan instance Anda memiliki memori yang cukup untuk menangani pg\$1dump dan pg\$1restore selama peningkatan dan menskalakannya ke jenis instance yang lebih besar.
Sebelum Anda memulai upgrade, periksa apakah database Anda memiliki objek besar. Katalog `pg_largeobject_metadata` menyimpan metadata yang terkait dengan objek besar. Data objek besar yang sebenarnya disimpan di`pg_largeobject`. Gunakan kueri berikut untuk memeriksa jumlah objek besar:
```
SELECT count(*) FROM pg_largeobject_metadata;
```
Untuk membersihkan benda-benda besar yang ada atau benda besar yatim piatu, lihat [Mengelola objek besar dengan modul lo](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_large_objects_lo_extension.html).
Saat merencanakan upgrade versi utama, sebaiknya gunakan tipe instans dengan memori minimal 32 GB jika database Anda berisi 25 hingga 30 juta objek besar. Rekomendasi ini didasarkan pada pengujian kami dan dapat bervariasi tergantung pada beban kerja spesifik dan konfigurasi database Anda. Jika database Anda menyertakan objek tambahan (seperti tabel, indeks, atau tampilan terwujud), sebaiknya pilih jenis instans yang lebih besar untuk memastikan kinerja optimal selama proses pemutakhiran.
1. **Menangani integrasi nol-ETL — Jika Anda memiliki integrasi** [[nol-ETL yang ada, hapus sebelum melakukan upgrade versi](zero-etl.md) utama.](zero-etl.deleting.md) Kemudian, setelah menyelesaikan peningkatan, buat ulang integrasi.
Pada versi sumber jurusan 17 dan lebih tinggi, integrasi nol-ETL dapat dipertahankan melalui peningkatan.
1. **Lakukan pencadangan** – Kami sarankan Anda melakukan pencadangan sebelum melakukan peningkatan versi mayor sehingga Anda memiliki titik pemulihan yang diketahui untuk basis data Anda. Jika periode retensi cadangan Anda lebih besar dari 0, proses peningkatan akan membuat snapshot DB dari basis data Anda sebelum dan setelah peningkatan. Untuk mengubah periode retensi cadangan Anda, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md) dan [Memodifikasi cluster DB Multi-AZ untuk Amazon RDS](modify-multi-az-db-cluster.md).
Untuk melakukan pencadangan secara manual, lihat [Membuat snapshot DB untuk instans DB AZ tunggal untuk Amazon RDS](USER_CreateSnapshot.md) dan [Membuat snapshot cluster DB multi-AZ untuk Amazon RDS](USER_CreateMultiAZDBClusterSnapshot.md).
1. **Tingkatkan ekstensi tertentu sebelum peningkatan versi mayor** – Jika Anda berencana untuk melewati sebuah versi mayor dengan peningkatan, Anda perlu memperbarui ekstensi tertentu *sebelum* melakukan peningkatan versi mayor. Misalnya, sebuah versi mayor dilewati dalam peningkatan dari versi 9.5.x atau 9,6.x ke versi 11.x. Ekstensi yang perlu diperbarui mencakup PostGIS dan ekstensi terkait untuk memproses data spasial.
+ `address_standardizer`
+ `address_standardizer_data_us`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
Anda tidak dapat langsung meningkatkan ke PostgreSQL versi 17 jika Anda `rdkit` menggunakan versi 4.6.0 dan yang lebih rendah, dan PostgreSQL versi 16 dan lebih rendah, karena ketidakcocokan. `rdkit` Di bawah ini adalah opsi peningkatan:
+ Jika Anda menggunakan PostgreSQL versi 13 dan lebih rendah, Anda perlu melakukan upgrade versi utama ke versi 14.14 dan versi 14 yang lebih tinggi, 15.9 dan versi 15 yang lebih tinggi, atau 16.5 dan versi 16 yang lebih tinggi terlebih dahulu, dan kemudian melakukan upgrade versi ke PostgreSQL 17.
+ Jika Anda menggunakan PostgreSQL versi 14, 15, atau 16, Anda perlu melakukan upgrade versi minor ke 14.14 dan versi 14 yang lebih tinggi, 15.9 dan versi 15 yang lebih tinggi, atau 16.5 dan versi 16 yang lebih tinggi, dan kemudian meningkatkan ke PostgreSQL versi 17.
Jalankan perintah berikut untuk setiap ekstensi yang Anda gunakan:
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Untuk informasi selengkapnya, lihat [Meningkatkan SQL ekstensi Postgre untuk database Postgre RDS SQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md). Untuk mempelajari selengkapnya tentang cara meningkatkan PostGIS, lihat [Langkah 6: Meningkatkan ekstensi PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update).
1. **Jatuhkan ekstensi tertentu sebelum upgrade versi utama** — Ekstensi yang tidak didukung pada versi target harus dihapus, atau upgrade akan gagal.
`plrust`Ekstensi dihapus mulai dari RDS PostgreSQL 18. `postgis_topology`[https://trac.osgeo.org/postgis/ticket/5983](https://trac.osgeo.org/postgis/ticket/5983) Ekstensi ini harus dihapus sebelum upgrade.
Upgrade yang melewatkan versi utama ke versi 11.x tidak mendukung pembaruan ekstensi. `pgRouting` Sebuah versi mayor dilewati dalam peningkatan dari versi 9.4.x, 9,5.x, atau 9,6.x ke versi 11.x. Aman untuk menghapus ekstensi `pgRouting` lalu menginstalnya kembali ke versi yang kompatibel setelah peningkatan. Untuk versi ekstensi yang dapat Anda perbarui, lihat [Versi ekstensi PostgreSQL yang didukung](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Ekstensi `tsearch2` dan `chkpass` tidak lagi didukung untuk PostgreSQL versi 11 atau yang lebih baru.
Anda dapat memeriksa apakah ekstensi diinstal dengan kueri berikut:
```
SELECT * FROM pg_extension WHERE extname in ('extension_name');
```
1. **Hapus jenis data yang tidak diketahui** – Hapus jenis data `unknown` tergantung pada versi target.
PostgreSQL versi 10 berhenti mendukung jenis data `unknown`. Jika basis data versi 9.6 menggunakan jenis data `unknown`, tingkatkan ke versi 10 akan menunjukkan pesan kesalahan seperti berikut ini:
```
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."
```
Untuk menemukan jenis data `unknown` di basis data Anda sehingga Anda dapat menghapus kolom yang melanggar atau mengubahnya ke jenis data yang didukung, gunakan SQL berikut:
```
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
```
1. **Lakukan percobaan peningkatan** – Kami sangat menyarankan Anda untuk menguji peningkatan versi mayor pada duplikat basis data produksi Anda sebelum mencoba peningkatan pada basis data produksi Anda. Anda dapat memantau rencana eksekusi pada basis data uji duplikat untuk setiap kemungkinan regresi rencana eksekusi dan untuk mengevaluasi performanya. Untuk membuat contoh pengujian duplikat, Anda dapat memulihkan database Anda dari snapshot terbaru atau melakukan point-in-time pemulihan database Anda ke waktu restorable terbaru.
Untuk informasi selengkapnya, lihat [Memulihkan dari snapshot](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Restoring) atau [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md). Untuk klaster DB Multi-AZ, lihat [Memulihkan dari snapshot ke klaster DB Multi-AZ](USER_RestoreFromMultiAZDBClusterSnapshot.Restoring.md) atau [Memulihkan klaster DB Multi-AZ ke waktu tertentu](USER_PIT.MultiAZDBCluster.md).
Untuk detail tentang melakukan peningkatan, lihat [Meningkatkan versi mesin secara manual](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Dalam meningkatkan basis data versi 9.6 ke versi 10, ketahuilah bahwa PostgreSQL 10 mengaktifkan kueri paralel secara default. Anda dapat menguji dampak paralelisme *sebelum* peningkatan dengan mengubah parameter `max_parallel_workers_per_gather` pada basis data uji Anda menjadi 2.
**catatan**
Nilai default untuk parameter `max_parallel_workers_per_gather` dalam grup parameter DB `default.postgresql10` adalah 2.
Untuk informasi selengkapnya, lihat [Parallel Query](https://www.postgresql.org/docs/10/parallel-query.html) dalam dokumentasi PostgreSQL. Untuk menonaktifkan paralelisme pada versi 10, atur parameter `max_parallel_workers_per_gather` ke 0.
Selama peningkatan versi mayor, basis data `public` dan `template1` serta skema `public` di setiap basis data akan diubah namanya untuk sementara. Objek-objek ini muncul dalam log menggunakan nama aslinya dan string acak. String ditambahkan sehingga pengaturan kustom seperti `locale` dan `owner` dipertahankan selama peningkatan versi mayor. Setelah peningkatan selesai, objek diubah namanya kembali ke nama aslinya.
**catatan**
Selama proses peningkatan versi utama, Anda tidak dapat melakukan point-in-time pemulihan instans DB atau cluster DB multi-AZ Anda. Setelah melakukan peningkatan, Amazon RDS akan membuat cadangan otomatis dari basis data. Anda dapat melakukan point-in-time pemulihan ke waktu sebelum pemutakhiran dimulai dan setelah pencadangan otomatis database Anda selesai.
1. **Jika peningkatan gagal karena kesalahan prosedur pra-pemeriksaan, atasi masalah tersebut** – Selama proses peningkatan versi mayor, Amazon RDS for PostgreSQL pertama-tama menjalankan prosedur pra-pemeriksaan untuk mengidentifikasi masalah yang mungkin menyebabkan peningkatan gagal. Prosedur pra-pemeriksaan akan memeriksa semua kemungkinan kondisi yang tidak kompatibel di seluruh basis data dalam instans.
Jika pra-pemeriksaan menemui masalah, proses ini akan membuat peristiwa log yang menunjukkan bahwa pra-pemeriksaan peningkatan gagal. Detail proses pra-pemeriksaan ada dalam log peningkatan yang bernama `pg_upgrade_precheck.log` untuk semua basis data yang berasal dari sebuah basis data tertentu. Amazon RDS menambahkan stempel waktu ke nama file. Untuk informasi selengkapnya tentang melihat log, lihat [Memantau file RDS Amazon](USER_LogAccess.md).
Jika peningkatan replika baca gagal pada saat pra-pemeriksaan, replikasi pada replika baca yang gagal rusak dan replika baca diberi status diakhiri. Hapus replika baca ini dan buat ulang replika baca baru berdasarkan instans DB primer yang ditingkatkan.
Selesaikan semua masalah yang teridentifikasi dalam log pra-pemeriksaan lalu coba lagi peningkatan versi mayor. Berikut ini adalah contoh log pra-pemeriksaan.
```
------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.
* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.
* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].
* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
```
1. **Jika peningkatan replika baca gagal saat meningkatkan basis data, atasi masalah tersebut** – Replika baca gagal diubah ke status `incompatible-restore` dan replikasi diakhiri pada basis data. Hapus replika baca ini dan buat ulang replika baca baru berdasarkan instans DB primer yang ditingkatkan.
**catatan**
Amazon RDS tidak meningkatkan replika baca untuk klaster DB Multi-AZ. Jika Anda melakukan peningkatan versi mayor klaster DB Multi-AZ, maka status replikasi replika bacanya berubah menjadi **diakhiri**.
Peningkatan replika baca dapat gagal karena alasan berikut:
+ Replika baca tidak dapat mengimbangi instans primer bahkan setelah waktu tunggu.
+ Replika baca berada dalam status siklus hidup akhir atau tidak kompatibel seperti penyimpanan penuh, pemulihan yang tidak kompatibel, dan seterusnya.
+ Saat peningkatan instans DB primer dimulai, terdapat peningkatan versi minor terpisah yang berjalan pada replika baca.
+ Replika baca menggunakan parameter yang tidak kompatibel.
+ Replika baca tidak dapat berkomunikasi dengan instans DB primer untuk menyinkronkan folder data.
1. **Tingkatkan basis data produksi Anda** – Ketika percobaan peningkatan versi mayor yang dijalankan berhasil, Anda dapat meningkatkan basis data produksi Anda dengan percaya diri. Untuk informasi selengkapnya, lihat [Meningkatkan versi mesin secara manual](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
1. Jalankan operasi `ANALYZE` untuk menyegarkan tabel `pg_statistic`. Anda harus melakukannya untuk setiap basis data pada semua basis data PostgreSQL Anda. Statistik pengoptimisasi tidak ditransfer selama peningkatan versi mayor, jadi Anda perlu membuat ulang semua statistik untuk menghindari masalah performa. Jalankan perintah tanpa parameter apa pun untuk menghasilkan statistik untuk semua tabel reguler dalam basis data saat ini, sebagai berikut:
```
ANALYZE VERBOSE;
```
Bendera `VERBOSE` bersifat opsional, tetapi kemajuannya akan ditampilkan jika digunakan. Untuk informasi selengkapnya, lihat [ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html) di dokumentasi PostgreSQL.
Saat menganalisis tabel tertentu alih-alih menggunakan ANALYZE VERBOSE, jalankan perintah ANALYZE untuk setiap tabel sebagai berikut:
```
ANALYZE table_name;
```
Untuk tabel yang dipartisi, selalu analisis tabel induk. Proses ini:
+ Secara otomatis sampel baris di semua partisi
+ Memperbarui statistik untuk setiap partisi secara rekursif
+ Mempertahankan statistik perencanaan penting di tingkat induk
Sementara tabel induk tidak menyimpan data aktual, menganalisisnya sangat penting untuk optimasi kueri. Menjalankan ANALISIS hanya pada partisi individu dapat menyebabkan kinerja kueri yang buruk karena pengoptimal tidak akan memiliki statistik komprehensif yang diperlukan untuk perencanaan lintas partisi yang efisien.
**catatan**
Jalankan ANALYZE pada sistem Anda setelah peningkatan untuk menghindari masalah performa.
Setelah peningkatan versi mayor selesai, kami menyarankan hal berikut:
+ Peningkatan mesin PostgreSQL tidak meningkatkan ekstensi PostgreSQL apa pun. Untuk meningkatkan ekstensi, lihat [Meningkatkan SQL ekstensi Postgre untuk database Postgre RDS SQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ Atau, gunakan Amazon RDS untuk melihat dua log yang dihasilkan oleh utilitas `pg_upgrade`. Log tersebut adalah `pg_upgrade_internal.log` dan `pg_upgrade_server.log`. Amazon RDS menambahkan stempel waktu ke nama file untuk log ini. Anda dapat melihat log ini sebagaimana Anda dapat melihat log lainnya. Untuk informasi selengkapnya, lihat [Memantau file RDS Amazon](USER_LogAccess.md).
Anda juga dapat mengunggah log pemutakhiran ke Amazon CloudWatch Logs. Untuk informasi selengkapnya, lihat [Menerbitkan log PostgreSQL ke Amazon Logs CloudWatch](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
+ Untuk memverifikasi bahwa segalanya berfungsi seperti yang diharapkan, uji aplikasi Anda pada basis data yang ditingkatkan dengan beban kerja serupa. Setelah peningkatan diverifikasi, Anda dapat menghapus instans uji ini.
# Upgrade versi minor otomatis untuk RDS untuk PostgreSQL
Jika Anda mengaktifkan **Peningkatan versi minor otomatis** saat membuat atau memodifikasi instans DB atau klaster DB Multi-AZ, Anda dapat melakukan peningkatan basis data secara otomatis.
Amazon RDS juga mendukung kebijakan peluncuran pemutakhiran untuk mengelola peningkatan versi minor otomatis di beberapa sumber daya database dan. Akun AWS Untuk informasi selengkapnya, lihat [Menggunakan kebijakan peluncuran AWS Organizations pemutakhiran untuk peningkatan versi minor otomatis](RDS.Maintenance.AMVU.UpgradeRollout.md).
Untuk setiap versi mayor RDS for PostgreSQL, satu versi minor ditetapkan oleh RDS sebagai versi peningkatan otomatis. Setelah versi minor diuji dan disetujui oleh Amazon RDS, tingkatkan versi minor terjadi secara otomatis selama periode pemeliharaan Anda. RDS tidak secara otomatis menetapkan versi minor yang lebih baru sebagai versi peningkatan otomatis. Sebelum RDS menetapkan versi peningkatan otomatis yang lebih baru, beberapa kriteria dipertimbangkan, seperti yang berikut ini:
+ Masalah keamanan yang diketahui
+ Bug dalam versi komunitas PostgreSQL
+ Stabilitas armada secara keseluruhan sejak versi minor dirilis
Anda dapat menggunakan AWS CLI perintah berikut untuk menentukan versi target pemutakhiran minor otomatis saat ini untuk versi minor PostgreSQL tertentu dalam versi tertentu. Wilayah AWS
Untuk Linux, macOS, atau Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version minor-version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Untuk Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version minor-version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Misalnya, AWS CLI perintah berikut menentukan target upgrade minor otomatis untuk PostgreSQL minor versi 16.1 di AS Timur (Ohio) (us-east-2). Wilayah AWS
Untuk Linux, macOS, atau Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Untuk Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Output Anda akan seperti yang berikut ini.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 16.2 |
| True | 16.3 |
| False | 16.4 |
| False | 16.5 |
| False | 16.6 |
| False | 17.1 |
| False | 17.2 |
+--------------+-----------------+
```
Dalam contoh ini, `AutoUpgrade` nilainya adalah `True` untuk PostgreSQL versi 16.3. Jadi, target upgrade minor otomatis adalah PostgreSQL versi 16.3, yang disorot dalam output.
Basis data PostgreSQL secara otomatis ditingkatkan selama periode pemeliharaan Anda jika kriteria berikut terpenuhi:
+ Basis data memiliki opsi **Peningkatan versi minor otomatis** diaktifkan.
+ Basis data menjalankan versi mesin DB minor yang lebih rendah dari versi minor peningkatan otomatis saat ini.
Untuk informasi selengkapnya, lihat [Meningkatkan versi mesin minor secara otomatis](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
**catatan**
Peningkatan mesin PostgreSQL tidak meningkatkan ekstensi PostgreSQL apa pun. Untuk meningkatkan ekstensi, lihat [Meningkatkan SQL ekstensi Postgre untuk database Postgre RDS SQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
# Meningkatkan SQL ekstensi Postgre untuk database Postgre RDS SQL
Upgrade SQL mesin Postgre tidak memutakhirkan sebagian besar ekstensi SQL Postgre. Untuk memperbarui ekstensi setelah peningkatan versi, gunakan perintah `ALTER EXTENSION UPDATE`.
**catatan**
Untuk informasi tentang memperbarui GIS ekstensi Post, lihat [Mengelola data spasial dengan ekstensi PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Langkah 6: Meningkatkan ekstensi PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).
Untuk memperbarui ekstensi `pg_repack`, hapus ekstensi ini lalu buat versi baru di basis data yang ditingkatkan. Untuk informasi selengkapnya, lihat [pg\$1repack installation](https://reorg.github.io/pg_repack/) dalam dokumentasi `pg_repack`.
Untuk meningkatkan ekstensi, gunakan perintah berikut.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
Untuk daftar versi SQL ekstensi Postgre yang didukung, lihat. [Versi ekstensi PostgreSQL yang didukung](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
Untuk membuat daftar ekstensi yang saat ini diinstal, gunakan katalog Postgre SQL [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) dalam perintah berikut.
```
SELECT * FROM pg_extension;
```
Untuk melihat daftar versi ekstensi tertentu yang tersedia untuk instalasi Anda, gunakan tampilan Postgre SQL [pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) dalam perintah berikut.
```
SELECT * FROM pg_available_extension_versions;
```
# Memantau RDS untuk upgrade mesin PostgreSQL dengan acara
Saat Anda memutakhirkan versi mesin dari database RDS untuk PostgreSQL, Amazon RDS memancarkan peristiwa tertentu selama setiap fase proses. Untuk melacak kemajuan peningkatan, Anda dapat melihat atau berlangganan acara ini.
Untuk informasi selengkapnya tentang peristiwa RDS, lihat[Memantau RDS](working-with-events.md).
Untuk informasi rinci tentang peristiwa Amazon RDS tertentu yang terjadi selama upgrade engine Anda, lihat[Kategori acara Amazon RDS dan pesan acara Aurora](USER_Events.Messages.md).
# Meningkatkan versi mesin snapshot DB PostgreSQL
Dengan Amazon RDS, Anda dapat membuat volume penyimpanan snapshot DB dari instans DB PostgreSQL. Saat Anda membuat snapshot DB, snapshot didasarkan pada versi mesin yang digunakan oleh instans Amazon RDS Anda. Anda dapat memutakhirkan versi mesin untuk snapshot DB Anda.
Setelah memulihkan snapshot DB yang ditingkatkan ke versi mesin baru, pastikan untuk menguji bahwa peningkatan berhasil. Untuk informasi selengkapnya tentang peningkatan versi mayor, lihat [Upgrade RDS untuk mesin PostgreSQL DB](USER_UpgradeDBInstance.PostgreSQL.md). Untuk mempelajari cara memulihkan snapshot DB RDS, lihat [Memulihkan ke instans DB](USER_RestoreFromSnapshot.md).
Anda dapat meningkatkan snapshot DB manual yang dienkripsi atau tidak dienkripsi.
Untuk melihat versi engine yang tersedia untuk snapshot RDS Anda untuk PostgreSQL DB, gunakan contoh berikut. AWS CLI
```
aws rds describe-db-engine-versions --engine postgres --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text --include-all
```
Untuk informasi selengkapnya tentang versi engine yang tersedia untuk snapshot RDS untuk PostgreSQL DB, lihat. [Memilih versi utama untuk RDS untuk upgrade PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
**catatan**
Anda tidak dapat meningkatkan snapshot DB otomatis yang dibuat selama proses pencadangan otomatis.
## Konsol
**Untuk meningkatkan snapshot DB**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Snapshot**.
1. Pilih snapshot yang ingin Anda tingkatkan.
1. Untuk **Tindakan**, pilih **Tingkatkan snapshot**. Halaman **Tingkatkan snapshot** muncul.
1. Pilih **Versi mesin baru** yang akan menjadi target peningkatan.
1. Pilih **Simpan perubahan** untuk meningkatkan snapshot.
Selama proses peningkatan, semua tindakan snapshot dinonaktifkan untuk snapshot DB ini. Selain itu, status snapshot DB berubah dari **tersedia** menjadi **meningkatkan**, lalu berubah menjadi **aktif** setelah selesai. Jika snapshot DB tidak dapat ditingkatkan karena masalah kerusakan snapshot, status berubah menjadi **tidak tersedia**. Anda tidak dapat memulihkan snapshot dari status ini.
**catatan**
Jika peningkatan snapshot DB gagal, snapshot di-rollback ke kondisi awal sesuai dengan versi asli.
## AWS CLI
Untuk memutakhirkan snapshot DB ke versi mesin database baru, gunakan AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)perintah.
**Parameter**
+ `--db-snapshot-identifier` – Pengidentifikasi untuk snapshot DB. Pengidentifikasi harus berupa Amazon Resource Name (ARN) yang unik. Untuk informasi selengkapnya, lihat [Nama Sumber Daya Amazon (ARNs) di Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version` – Versi mesin untuk meningkatkan snapshot DB.
**Example**
Untuk Linux, macOS, atau Unix:
```
1. aws rds modify-db-snapshot \
2. --db-snapshot-identifier my_db_snapshot \
3. --engine-version new_version
```
Untuk Windows:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
## API RDS
Untuk memutakhirkan snapshot DB ke versi mesin database baru, hubungi operasi Amazon RDS API [Modify DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html).
+ `DBSnapshotIdentifier` – Pengidentifikasi untuk snapshot DB. Pengidentifikasi harus berupa Amazon Resource Name (ARN) yang unik. Untuk informasi selengkapnya, lihat [Nama Sumber Daya Amazon (ARNs) di Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion` – Versi mesin untuk meningkatkan snapshot DB.
# Menggunakan replika baca untuk Amazon RDS for PostgreSQL
Anda dapat menskalakan pembacaan untuk instans DB Amazon RDS for PostgreSQL dengan menambahkan replika baca ke instans. Seperti mesin basis data Amazon RDS lainnya, RDS for PostgreSQL menggunakan mekanisme replikasi native PostgreSQL untuk terus memperbarui replika baca dengan perubahan pada DB sumber. Untuk informasi umum tentang replika baca dan Amazon RDS, lihat [Menggunakan replika baca instans DB](USER_ReadRepl.md).
Di bagian berikut ini, Anda dapat menemukan informasi spesifik untuk menggunakan replika baca dengan RDS for PostgreSQL.
## Batasan replika baca dengan PostgreSQL
Berikut ini adalah batasan untuk replika baca PostgreSQL:
+ Replika baca PostgreSQL bersifat hanya baca. Meskipun replika baca bukan instans DB yang dapat ditulis, Anda dapat mempromosikannya menjadi instans DB RDS for PostgreSQL mandiri. Namun, prosesnya tidak dapat dikembalikan.
+ Anda tidak dapat membuat replika baca dari replika baca lain jika instans DB RDS for PostgreSQL Anda menjalankan versi PostgreSQL yang lebih lama dari 14.1. RDS for PostgreSQL mendukung replika baca kaskade pada RDS for PostgreSQL versi 14.1 dan rilis yang lebih tinggi saja. Untuk informasi selengkapnya, lihat [Menggunakan replika baca kaskade dengan RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Jika Anda mempromosikan replika baca PostgreSQL, replika baca ini akan menjadi instans DB yang dapat ditulis. Replika baca ini akan berhenti menerima file write-ahead log (WAL) dari instans DB sumber, dan bukan lagi merupakan instans hanya baca. Anda dapat membuat replika baca baru dari instans DB yang dipromosikan seperti halnya instans DB RDS for PostgreSQL apa pun. Untuk informasi selengkapnya, lihat [Mempromosikan replika baca menjadi instans DB mandiri](USER_ReadRepl.Promote.md).
+ Jika Anda mempromosikan replika baca PostgreSQL dari dalam rantai replikasi (serangkaian replika baca kaskade), setiap replika baca hilir yang ada akan terus menerima file WAL dari instans yang dipromosikan secara otomatis. Untuk informasi selengkapnya, lihat [Menggunakan replika baca kaskade dengan RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Jika tidak ada transaksi pengguna yang berjalan pada instans DB sumber, replika baca PostgreSQL terkait akan melaporkan lag replikasi hingga lima menit. Lag replika dihitung sebagai `currentTime - lastCommitedTransactionTimestamp`, yang berarti bahwa ketika tidak ada transaksi yang sedang diproses, nilai lag replika akan meningkat untuk jangka waktu tertentu sampai segmen write-ahead log (WAL) beralih. Secara default RDS for PostgreSQL mengganti segmen WAL setiap 5 menit, yang menghasilkan catatan transaksi dan penurunan lag yang dilaporkan.
+ Anda tidak dapat mengaktifkan pencadangan otomatis untuk replika baca PostgreSQL untuk versi RDS for PostgreSQL yang lebih lama dari 14.1. Pencadangan otomatis untuk replika baca didukung untuk RDS for PostgreSQL 14.1 dan versi yang lebih tinggi saja. Untuk RDS for PostgreSQL 13 dan versi yang lebih lama, buat snapshot dari replika baca jika Anda menginginkan cadangannya.
+ Point-in-time recovery (PITR) tidak didukung untuk replika baca. Anda dapat menggunakan PITR dengan instans primer (penulis) saja, bukan replika baca. Untuk mempelajari selengkapnya, lihat [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md).
+ Baca replika untuk PostgreSQL versi 12 dan yang lebih rendah secara otomatis reboot selama jendela pemeliharaan 60-90 hari untuk menerapkan rotasi kata sandi. Jika replika kehilangan koneksi ke sumber sebelum reboot yang dijadwalkan, replika masih reboot untuk melanjutkan replikasi. Untuk PostgreSQL versi 13 dan yang lebih tinggi, replika baca mungkin mengalami pemutusan replikasi singkat dan rekoneksi selama proses rotasi kata sandi.
# Konfigurasi replika baca dengan PostgreSQL
RDS for PostgreSQL menggunakan replikasi streaming native PostgreSQL untuk membuat salinan hanya baca instans DB sumber. Instans DB replika baca ini adalah replika fisik yang dibuat secara asinkron dari instans DB sumber. Instans ini dibuat oleh koneksi khusus yang mentransmisikan data write ahead log (WAL) dari instans DB sumber ke replika baca. Untuk informasi selengkapnya, lihat [Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) dalam dokumentasi PostgreSQL.
PostgreSQL secara asinkron mengalirkan perubahan basis data ke koneksi aman ini saat perubahan tersebut dibuat pada instans DB sumber. Anda dapat mengenkripsi komunikasi dari aplikasi klien Anda ke instans DB sumber atau replika baca apa pun dengan mengatur parameter `ssl` ke `1`. Untuk informasi selengkapnya, lihat [Menggunakan SSL dengan instans DB PostgreSQL](PostgreSQL.Concepts.General.SSL.md).
PostgreSQL menggunakan peran *replikasi* untuk melakukan replikasi streaming. Peran ini memiliki hak akses, tetapi Anda tidak dapat menggunakannya untuk mengubah data apa pun. PostgreSQL menggunakan proses tunggal untuk menangani replikasi.
Anda dapat membuat replika baca PostgreSQL tanpa memengaruhi operasi atau pengguna instans DB sumber. Amazon RDS menetapkan parameter dan izin yang diperlukan untuk Anda, pada instans DB sumber dan replika baca, tanpa memengaruhi layanan. Snapshot diambil dari instans DB sumber, dan snapshot ini digunakan untuk membuat replika baca. Jika Anda menghapus replika baca pada suatu waktu di masa mendatang, tidak ada pemadaman yang akan terjadi.
Anda dapat membuat hingga 15 replika baca dari satu instans DB sumber di Wilayah yang sama. Di RDS for PostgreSQL 14.1, Anda juga dapat membuat hingga tiga tingkat replika baca dalam rantai (kaskade) dari satu instans DB sumber. Untuk informasi selengkapnya, lihat [Menggunakan replika baca kaskade dengan RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). Dalam semua kasus, instans DB sumber perlu memiliki pencadangan otomatis yang dikonfigurasi. Anda melakukannya dengan mengatur periode retensi cadangan pada instans DB Anda ke nilai apa pun selain 0. Untuk informasi selengkapnya, lihat [Membuat replika baca](USER_ReadRepl.Create.md).
Anda dapat membuat replika baca untuk instans DB RDS for PostgreSQL Anda di Wilayah AWS yang sama dengan instans DB sumber Anda. Hal ini dikenal sebagai replikasi *dalam Wilayah*. Anda juga dapat membuat replika baca berbeda Wilayah AWS dari instance DB sumber. Hal ini dikenal sebagai replikasi *lintas Wilayah*. Untuk informasi selengkapnya tentang menyiapkan replika baca lintas Wilayah, lihat [Membuat replika baca di tempat yang berbeda Wilayah AWS](USER_ReadRepl.XRgn.md). Berbagai mekanisme yang mendukung proses replikasi untuk dalam Wilayah dan lintas Wilayah sedikit berbeda tergantung pada versi RDS for PostgreSQL seperti yang dijelaskan dalam [Cara kerja replikasi streaming untuk berbagai versi RDS for PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Agar replikasi beroperasi secara efektif, setiap replika baca harus memiliki jumlah sumber daya komputasi dan penyimpanan yang sama seperti instans DB sumber. Jika Anda menskalakan instans DB sumber, pastikan untuk juga menskalakan replika baca.
Amazon RDS mengganti parameter yang tidak kompatibel pada replika baca jika parameter tersebut mencegah replika baca dimulai. Misalnya, anggaplah nilai parameter `max_connections` pada instans DB sumber lebih tinggi daripada replika baca. Dalam hal ini, Amazon RDS memperbarui nilai parameter pada replika baca agar sama dengan nilai pada instans DB sumber.
RDS untuk replika baca PostgreSQL memiliki akses ke database eksternal yang tersedia melalui pembungkus data asing () pada instance DB sumber. FDWs Misalnya, anggaplah instans DB RDS for PostgreSQL Anda menggunakan wrapper `mysql_fdw` untuk mengakses data dari RDS for MySQL. Jika demikian, replika baca Anda juga dapat mengakses data tersebut. Dukungan lainnya FDWs termasuk`oracle_fdw`,`postgres_fdw`, dan`tds_fdw`. Untuk informasi selengkapnya, lihat [Bekerja dengan pembungkus data asing yang didukung untuk Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Menggunakan replika baca RDS for PostgreSQL dengan konfigurasi Multi-AZ
Anda dapat membuat replika baca dari instans DB AZ Tunggal atau Multi-AZ. Anda dapat menggunakan deployment Multi-AZ untuk meningkatkan durabilitas dan ketersediaan data kritis, dengan replika siaga. *Replika siaga* adalah replika baca khusus yang dapat mengambil alih beban kerja jika DB sumber melakukan failover. Anda tidak dapat menggunakan replika siaga Anda untuk melayani lalu lintas baca. Namun, Anda dapat membuat replika baca dari instans DB Multi-AZ yang memiliki lalu lintas tinggi untuk mengalihkan kueri hanya baca. Untuk mempelajari selengkapnya tentang deployment Multi-AZ, lihat [Penerapan instans DB multi-AZ untuk Amazon RDS](Concepts.MultiAZSingleStandby.md).
Jika instans DB sumber dari deployment Multi-AZ melakukan failover ke replika siaga, replika baca terkait akan beralih menggunakan replika siaga (sekarang menjadi replika primer) sebagai sumber replikasinya. Replika baca mungkin perlu diaktifkan ulang, tergantung pada versi RDS for PostgreSQL sebagai berikut:
+ **PostgreSQL 13 dan versi yang lebih tinggi** – Pengaktifan ulang tidak diperlukan. Replika baca secara otomatis disinkronkan dengan replika primer baru. Namun, dalam beberapa kasus, aplikasi klien Anda mungkin meng-cache detail Layanan Nama Domain (DNS) untuk replika baca Anda. Jika demikian, atur nilai time-to-live (TTL) menjadi kurang dari 30 detik. Tindakan ini akan mencegah replika baca mempertahankan alamat IP yang sudah tidak berlaku (dan dengan demikian, mencegah replika baca ini disinkronkan dengan replika primer baru). Untuk mempelajari selengkapnya tentang hal ini dan praktik terbaik lainnya, lihat [Pedoman operasional dasar Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 dan semua versi yang lebih lama** – Replika baca diaktifkan ulang secara otomatis setelah failover ke replika siaga karena replika siaga (sekarang menjadi replika primer) memiliki alamat IP dan nama instans yang berbeda. Pengaktifan ulang ini akan menyinkronkan replika baca dengan replika primer baru.
Untuk mempelajari selengkapnya tentang failover, lihat [Gagal dalam instans DB Multi-AZ untuk Amazon RDS](Concepts.MultiAZ.Failover.md). Untuk mempelajari selengkapnya tentang cara kerja replika baca dalam deployment Multi-AZ, lihat [Menggunakan replika baca instans DB](USER_ReadRepl.md).
Untuk memberikan dukungan failover untuk replika baca, Anda dapat membuat replika baca sebagai instans DB Multi-AZ sehingga Amazon RDS akan membuat replika siaga Anda di Zona Ketersediaan (AZ) lain. Membuat replika baca Anda sebagai instans DB Multi-AZ tidak tergantung pada apakah basis data sumber adalah instans DB Multi-AZ.
# Pendekodean logis pada replika baca
RDS for PostgreSQL mendukung replikasi logis dari replika siaga dengan PostgreSQL 16.1. Hal ini memungkinkan Anda membuat pendekodean logis dari replika siaga hanya baca yang mengurangi beban pada instans DB primer. Anda dapat mencapai ketersediaan yang lebih tinggi untuk aplikasi Anda yang perlu menyinkronkan data di beberapa sistem. Fitur ini meningkatkan performa gudang data dan analitik data Anda.
Selain itu, slot replikasi pada replika siaga tertentu akan mempersistensi promosi replika siaga tersebut menjadi replika primer. Artinya, jika terjadi failover instans DB primer atau promosi replika siaga menjadi replika primer baru, slot replikasi akan dipersistensi dan pelanggan replika siaga sebelumnya tidak akan terpengaruh.
**Untuk membuat pendekodean logis pada replika baca**
1. **Aktifkan replikasi logis** – Untuk membuat pendekodean logis pada replika siaga, Anda harus mengaktifkan replikasi logis pada instans DB sumber Anda dan replika fisiknya. Untuk informasi selengkapnya, lihat [Konfigurasi replika baca dengan PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Untuk mengaktifkan replikasi logis untuk instans DB RDS for PostgreSQL yang baru dibuat** – Buat grup parameter kustom DB baru dan atur parameter statis `rds.logical_replication` ke `1`. Kemudian, kaitkan grup parameter DB ini dengan instans DB sumber dan replika baca fisiknya. Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Associating.md).
+ **Untuk mengaktifkan replikasi logis untuk instans DB RDS for PostgreSQL yang ada** – Ubah grup parameter kustom DB dari instans DB sumber dan replika baca fisiknya untuk mengatur parameter statis `rds.logical_replication` ke `1`. Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Modifying.md).
**catatan**
Anda harus mem-boot ulang instans DB untuk menerapkan perubahan parameter ini.
Anda dapat menggunakan kueri berikut untuk memverifikasi nilai untuk `wal_level` dan `rds.logical_replication` pada instans DB sumber dan replika baca fisiknya.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Buat tabel di basis data sumber** – Hubungkan ke basis data di instans DB sumber Anda. Untuk informasi selengkapnya, lihat [Menghubungkan ke instans DB yang menjalankan mesin basis data PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Gunakan kueri berikut untuk membuat tabel di basis data sumber Anda dan untuk menyisipkan nilai:
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Buat penerbitan untuk tabel sumber** – Gunakan kueri berikut untuk membuat penerbitan untuk tabel pada instans DB sumber.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Gunakan kueri SELECT untuk memverifikasi detail penerbitan yang dibuat pada instans DB sumber dan instans replika baca fisik.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Buat langganan dari instans replika logis** – Buat instans DB RDS for PostgreSQL lain sebagai instans replika logis. Pastikan VPC diatur dengan benar untuk memastikan bahwa instans replika logis ini dapat mengakses instans replika baca fisik. Untuk informasi selengkapnya, lihat [Amazon VPC dan RDSAmazon ](USER_VPC.md). Jika instans DB sumber Anda dalam kondisi idle, masalah konektivitas mungkin terjadi dan replika primer tidak mengirim data ke replika siaga.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Gunakan kueri SELECT untuk memverifikasi detail langganan pada instans replika logis.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Periksa status slot replikasi logis** – Anda hanya dapat melihat slot replikasi fisik pada instans DB sumber Anda.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
Namun, pada instans replika baca Anda, Anda dapat melihat slot replikasi logis dan nilai `confirmed_flush_lsn` berubah saat aplikasi secara aktif mengonsumsi perubahan logis.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Menggunakan replika baca kaskade dengan RDS for PostgreSQL
Mulai dari versi 14.1, RDS for PostgreSQL mendukung replika baca kaskade. Dengan *replika baca kaskade*, Anda dapat menskalakan pembacaan tanpa menambahkan overhead ke instans DB RDS for PostgreSQL sumber Anda. Pembaruan pada log WAL tidak dikirim oleh instans DB sumber ke setiap replika baca. Sebagai gantinya, setiap replika baca dalam rangkaian kaskade akan mengirimkan pembaruan log WAL ke replika baca berikutnya dalam rangkaian tersebut. Hal ini akan mengurangi beban pada instans DB sumber.
Dengan replika baca kaskade, instans DB RDS for PostgreSQL Anda akan mengirimkan data WAL ke replika baca pertama dalam rantai. Replika baca tersebut kemudian mengirimkan data WAL ke replika kedua dalam rantai, dan seterusnya. Hasil akhirnya adalah bahwa semua replika baca dalam rantai memiliki perubahan dari instans DB RDS for PostgreSQL, tetapi overhead-nya tidak hanya berada pada instans DB sumber.
Anda dapat membuat rangkaian yang terdiri dari maksimal tiga replika baca dalam rantai dari instans DB RDS for PostgreSQL sumber. Misalnya, anggaplah bahwa Anda memiliki instans DB RDS for PostgreSQL 14.1, yaitu `rpg-db-main`. Anda dapat melakukan hal berikut:
+ Dimulai dengan `rpg-db-main`, buat replika baca pertama dalam rantai, `read-replica-1`.
+ Selanjutnya, dari `read-replica-1`, buat replika baca berikutnya dalam rantai, `read-replica-2`.
+ Akhirnya, dari `read-replica-2`, buat replika baca ketiga dalam rantai, `read-replica-3`.
Anda tidak dapat membuat replika baca lain di luar replika baca kaskade ketiga ini dalam rangkaian untuk `rpg-db-main`. Rangkaian lengkap instans dari instans DB sumber RDS for PostgreSQL hingga akhir rangkaian replika baca kaskade dapat terdiri dari maksimal empat instans DB.
Agar replika baca kaskade berfungsi, aktifkan pencadangan otomatis pada RDS for PostgreSQL Anda. Buat replika baca terlebih dahulu lalu aktifkan pencadangan otomatis pada instans DB RDS for PostgreSQL. Proses ini sama dengan mesin DB Amazon RDS lainnya. Untuk informasi selengkapnya, lihat [Membuat replika baca](USER_ReadRepl.Create.md).
Seperti halnya replika baca lainnya, Anda dapat mempromosikan replika baca yang merupakan bagian dari kaskade. Jika replika baca dipromosikan dari dalam rantai replika baca, replika baca ini akan dihapus dari rantai tersebut. Misalnya, anggaplah Anda ingin memindahkan sebagian beban kerja dari instans DB `rpg-db-main` Anda ke instans baru yang akan digunakan oleh departemen akuntansi saja. Berdasarkan rantai tiga replika baca dari contoh, Anda memutuskan untuk mempromosikan `read-replica-2`. Rantai terpengaruh sebagai berikut:
+ Mempromosikan `read-replica-2` menghapusnya dari rantai replikasi.
+ Sekarang ini adalah instance read/write DB penuh.
+ Replika ini terus mereplikasi menjadi `read-replica-3`, seperti yang dilakukan sebelum promosi.
+ `rpg-db-main` Anda terus mereplikasi ke `read-replica-1`.
Untuk informasi lebih lanjut tentang mempromosikan replika baca, lihat [Mempromosikan replika baca menjadi instans DB mandiri](USER_ReadRepl.Promote.md).
**catatan**
RDS untuk PostgreSQL tidak mendukung peningkatan versi utama untuk replika cascading. Sebelum melakukan upgrade versi utama, Anda perlu menghapus replika cascading. Anda dapat membuatnya kembali setelah menyelesaikan pemutakhiran pada instans DB sumber dan replika tingkat pertama Anda.
Untuk replika baca kaskade, RDS for PostgreSQL mendukung 15 replika baca untuk setiap instans DB sumber pada replikasi tingkat pertama, dan 5 replika baca untuk setiap instans DB sumber pada tingkat replikasi kedua dan ketiga.
# Membuat replika baca cascading lintas wilayah dengan RDS untuk PostgreSQL
RDS untuk PostgreSQL mendukung replika baca cascading lintas wilayah. Anda dapat membuat replika Lintas wilayah dari instans DB sumber, dan kemudian membuat replika wilayah yang sama darinya. Anda juga dapat membuat replika wilayah yang sama dari instans DB sumber, dan kemudian membuat replika Lintas wilayah darinya.
**Buat replika Lintas wilayah dan kemudian buat replika wilayah yang sama**
Anda dapat menggunakan instans RDS untuk PostgreSQL DB dengan versi 14.1 atau lebih tinggi, untuk melakukan hal berikut: `rpg-db-main`
1. Mulailah dengan `rpg-db-main` (US-EAST-1), buat replika baca Lintas wilayah pertama dalam rantai, (US-WEST-2). `read-replica-1`
1. Menggunakan Cross-region pertama `read-replica-1` (US-WEST-2), buat replika baca kedua dalam rantai, (US-WEST-2). `read-replica-2`
1. Menggunakan`read-replica-2`, buat replika baca ketiga dalam rantai, `read-replica-3` (US-WEST-2).
**Buat replika wilayah yang sama dan kemudian buat replika Lintas wilayah**
Anda dapat menggunakan instans RDS untuk PostgreSQL DB dengan versi 14.1 atau lebih tinggi, untuk melakukan hal berikut: `rpg-db-main`
1. Dimulai dengan `rpg-db-main` (US-EAST-1), buat replika baca pertama dalam rantai, `read-replica-1` (US-EAST-1).
1. Menggunakan `read-replica-1` (US-EAST-1), buat replika baca Lintas wilayah pertama dalam rantai, (US-WEST-2). `read-replica-2`
1. Menggunakan `read-replica-2` (US-WEST-2), buat replika baca ketiga dalam rantai, `read-replica-3` (US-WEST-2).
**Keterbatasan dalam membuat replika baca lintas wilayah**
+ Rantai cascading cross-region dari replika database dapat menjangkau maksimal dua Wilayah, dengan maksimum empat tingkat. Empat tingkat termasuk sumber database dan tiga replika baca.
**Keuntungan menggunakan replika baca cascading**
+ Peningkatan skalabilitas baca - Dengan mendistribusikan kueri baca di beberapa replika, replikasi cascading membantu menyeimbangkan beban. Ini meningkatkan kinerja, terutama dalam aplikasi read-heavy, dengan mengurangi ketegangan pada database penulis.
+ Distribusi geografis — Replika Cascading dapat ditemukan di lokasi geografis yang berbeda. Ini mengurangi latensi bagi pengguna yang berada jauh dari database utama dan menyediakan replika baca lokal, meningkatkan kinerja dan pengalaman pengguna.
+ Ketersediaan tinggi dan pemulihan bencana - Jika terjadi kegagalan server utama, replika dapat dipromosikan ke primer, memastikan kontinuitas. replikasi cascading semakin meningkatkan ini dengan menyediakan beberapa lapisan opsi failover, meningkatkan ketahanan keseluruhan sistem.
+ Fleksibilitas dan pertumbuhan modular — Seiring pertumbuhan sistem, replika baru dapat ditambahkan pada tingkat yang berbeda tanpa konfigurasi ulang besar dari database utama. Pendekatan modular ini memungkinkan pertumbuhan pengaturan replikasi yang dapat diskalakan dan dikelola.
**Praktik terbaik untuk menggunakan replika baca lintas wilayah**
+ Sebelum mempromosikan replika, buat replika tambahan. Ini akan menghemat waktu, dan memberikan penanganan beban kerja yang efisien.
# Cara kerja replikasi streaming untuk berbagai versi RDS for PostgreSQL
Seperti dibahas dalam [Konfigurasi replika baca dengan PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), RDS for PostgreSQL menggunakan protokol replikasi streaming native PostgreSQL untuk mengirim data WAL dari instans DB sumber. Layanan ini mengirimkan data WAL sumber ke replika baca untuk replika baca dalam Wilayah dan lintas Wilayah. Dengan versi 9.4, PostgreSQL memperkenalkan slot replikasi fisik sebagai mekanisme pendukung untuk proses replikasi.
*Slot replikasi fisik* mencegah instans DB sumber menghapus data WAL sebelum dikonsumsi oleh semua replika baca. Setiap replika baca memiliki slot fisiknya sendiri pada instans DB sumber. Slot melacak WAL terlama (berdasarkan nomor urutan logis, LSN) yang mungkin diperlukan oleh replika. Setelah semua slot dan koneksi DB telah berkembang melampaui WAL (LSN) tertentu, LSN tersebut akan menjadi kandidat yang akan dihapus di checkpoint berikutnya.
Amazon RDS menggunakan Amazon S3 untuk mengarsipkan data WAL. Untuk replika baca dalam Wilayah, Anda dapat menggunakan data yang diarsipkan ini untuk memulihkan replika baca jika diperlukan. Contoh situasi saat Anda mungkin perlu melakukannya adalah jika koneksi antara DB sumber dan replika baca terputus karena alasan apa pun.
Dalam tabel berikut, Anda dapat menemukan ringkasan perbedaan antara versi PostgreSQL dan mekanisme pendukung untuk dalam Wilayah dan lintas Wilayah yang digunakan oleh RDS for PostgreSQL.
| Versi | Dalam Wilayah | Lintas Wilayah |
| --- | --- | --- |
| PostgreSQL 14.1 dan versi yang lebih tinggi | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 dan versi yang lebih rendah | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Untuk informasi selengkapnya, lihat [Memantau dan menyetel proses replikasi](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Memahami parameter yang mengontrol replikasi PostgreSQL
Parameter berikut memengaruhi proses replikasi dan menentukan seberapa baik replika baca dalam mengikuti instans DB sumber:
**max\$1wal\$1senders**
Parameter `max_wal_senders` menentukan jumlah maksimum koneksi yang dapat didukung oleh instans DB sumber pada saat yang sama melalui protokol replikasi streaming.
Nilai default bervariasi untuk RDS untuk versi PostgreSQL:
+ Untuk versi 13, 14, dan 15, nilai defaultnya adalah 20.
+ Untuk versi 16 ke atas, nilai defaultnya adalah 35.
Parameter ini harus diatur sedikit lebih tinggi dari jumlah replika baca sebenarnya. Jika parameter ini diatur terlalu rendah untuk jumlah replika baca, replikasi akan berhenti.
Untuk informasi selengkapnya, lihat [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) dalam dokumentasi PostgreSQL.
`max_wal_senders`adalah parameter statis yang memerlukan reboot instance DB agar perubahan diterapkan.
**wal\$1keep\$1segments**
Parameter `wal_keep_segments` menentukan jumlah file write-ahead log (WAL) yang dipertahankan oleh instans DB sumber di direktori `pg_wal`. Pengaturan default adalah 32.
Jika `wal_keep_segments` tidak diatur ke nilai yang cukup besar untuk deployment Anda, replika baca dapat tertinggal jauh sehingga replikasi streaming berhenti. Jika itu terjadi, Amazon RDS akan menghasilkan kesalahan replikasi dan memulai pemulihan pada replika baca. Layanan ini melakukannya dengan memutar ulang data WAL yang diarsipkan milik instans DB sumber dari Amazon S3. Proses pemulihan ini berlanjut sampai replika baca tersebut dapat melanjutkan replikasi streaming. Anda dapat melihat proses ini dalam praktiknya seperti yang dicatat oleh log PostgreSQL dalam [Contoh: Bagaimana replika baca pulih dari interupsi replikasiContoh: Baca pemulihan replika dari gangguan replikasi](#USER_PostgreSQL.Replication.example-how-it-works).
Di PostgreSQL versi 13, parameter `wal_keep_segments` diberi nama `wal_keep_size`. Hal ini memiliki fungsi yang sama seperti `wal_keep_segments`, tetapi nilai default-nya menggunakan megabyte (MB) (2048 MB), bukan jumlah file. Untuk informasi selengkapnya, lihat [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) dan [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) dalam dokumentasi PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
Parameter `max_slot_wal_keep_size` mengontrol kuantitas data WAL yang dipertahankan oleh DB RDS for PostgreSQL dalam direktori `pg_wal` untuk melayani slot. Parameter ini digunakan untuk konfigurasi yang menggunakan slot replikasi. Nilai default untuk parameter ini adalah `-1`, artinya tidak ada batasan berapa banyak data WAL yang dipertahankan pada instans DB sumber. Untuk informasi tentang cara memantau slot replikasi Anda, lihat [Memantau slot replikasi untuk instans DB RDS for PostgreSQL Anda](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Untuk informasi selengkapnya tentang parameter ini, lihat [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) dalam dokumentasi PostgreSQL.
Setiap kali stream yang menyediakan data WAL ke replika baca terputus, PostgreSQL akan beralih ke mode pemulihan. Ini mengembalikan replika baca dengan menggunakan data WAL yang diarsipkan dari Amazon S3 atau dengan menggunakan data WAL yang terkait dengan slot replikasi. Saat proses ini selesai, PostgreSQL membuat ulang replikasi streaming.
### Contoh: Bagaimana replika baca pulih dari interupsi replikasi
Dalam contoh berikut, Anda akan menemukan detail log yang menunjukkan proses pemulihan untuk replika baca. Contohnya adalah dari RDS untuk instance PostgreSQL DB yang menjalankan PostgreSQL versi 12.9 sama dengan DB sumber, jadi slot replikasi tidak digunakan. Wilayah AWS Proses pemulihannya sama untuk instans DB RDS for PostgreSQL lain yang menjalankan PostgreSQL yang lebih lama dari versi 14.1 dengan replika baca dalam Wilayah.
Ketika replika baca kehilangan kontak dengan instans DB sumber, Amazon RDS mencatat masalahnya di log sebagai pesan `FATAL: could not receive data from WAL stream`, bersama dengan `ERROR: requested WAL segment ... has already been removed`. Seperti yang ditunjukkan pada baris tebal, Amazon RDS memulihkan replika dengan memutar ulang file WAL yang diarsipkan.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Saat Amazon RDS memutar ulang data WAL yang diarsipkan pada replika untuk mengejar ketinggalan, streaming ke replika baca dimulai lagi. Saat streaming dilanjutkan, Amazon RDS menulis entri ke file log seperti yang berikut ini.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Mengatur parameter yang mengontrol memori bersama
Parameter yang Anda tetapkan menentukan ukuran memori bersama untuk melacak transaksi IDs, kunci, dan transaksi yang disiapkan. **Struktur memori bersama instans siaga harus sama atau lebih besar dari instans primer.** Hal ini memastikan bahwa instans siaga tidak kehabisan memori bersama selama pemulihan. Jika nilai parameter pada replika kurang dari nilai parameter pada instans primer, Amazon RDS akan secara otomatis menyesuaikan parameter replika dan mengaktifkan ulang mesin.
Parameter yang terpengaruh adalah:
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Untuk menghindari boot ulang replika RDS karena memori yang tidak mencukupi, kami sarankan untuk menerapkan perubahan parameter sebagai boot ulang bergulir pada setiap replika. Anda harus menerapkan aturan berikut saat Anda mengatur parameter:
+ **Meningkatkan nilai parameter:**
+ Anda harus selalu meningkatkan nilai parameter dari semua replika baca terlebih dahulu, dan melakukan boot ulang bergulir pada semua replika. Kemudian, terapkan perubahan parameter pada instans primer dan boot ulang.
+ **Menurunkan nilai parameter:**
+ Anda harus terlebih dahulu mengurangi nilai parameter instans primer dan melakukan boot ulang. Kemudian, terapkan perubahan parameter ke semua replika baca terkait dan lakukan boot ulang bergulir.
# Memantau dan menyetel proses replikasi
Kami sangat menyarankan agar Anda secara rutin memantau instans DB dan replika baca RDS for PostgreSQL Anda. Anda perlu memastikan bahwa replika baca Anda mengikuti perubahan pada instans DB sumber. Amazon RDS secara transparan memulihkan replika baca Anda saat terjadi gangguan pada proses replikasi. Namun, yang terbaik adalah menghindari kebutuhan pemulihan sama sekali. Pemulihan menggunakan slot replikasi akan lebih cepat daripada menggunakan arsip Amazon S3, tetapi proses pemulihan apa pun dapat memengaruhi performa baca.
Untuk menentukan seberapa baik replika baca Anda dalam mengikuti instans DB sumber, Anda dapat melakukan hal berikut:
+ **Periksa jumlah `ReplicaLag` antara instans DB sumber dan replika.** *Lag replika* adalah jumlah waktu, dalam hitungan detik, untuk ketertinggalan replika baca dari instans DB sumbernya. Metrik ini melaporkan hasil dari kueri berikut.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
Lag replika adalah indikasi seberapa baik replika baca dalam mengikuti instans DB sumber. Lag replika adalah jumlah latensi antara instans DB sumber dan instans baca tertentu. Nilai tinggi untuk lag replika dapat menunjukkan ketidakcocokan antara kelas instans DB atau jenis penyimpanan (atau keduanya) yang digunakan oleh instans DB sumber dan replika bacanya. Kelas instans DB dan jenis penyimpanan untuk instans DB sumber dan semua replika baca harus sama.
Lag replika juga dapat diakibatkan oleh masalah koneksi intermiten. Anda dapat memantau kelambatan replikasi di Amazon CloudWatch dengan melihat metrik Amazon RDS. `ReplicaLag` Untuk mempelajari selengkapnya tentang `ReplicaLag` dan metrik lainnya untuk Amazon RDS, lihat [CloudWatch Metrik Amazon untuk Amazon RDS](rds-metrics.md).
+ **Periksa log PostgreSQL untuk menemukan informasi yang dapat Anda gunakan untuk menyesuaikan pengaturan Anda.** Di setiap checkpoint, log PostgreSQL mengambil jumlah file log transaksi yang didaur ulang, seperti yang ditunjukkan pada contoh berikut.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
Anda dapat menggunakan informasi ini untuk mengetahui berapa banyak file transaksi yang didaur ulang dalam periode waktu tertentu. Anda kemudian dapat mengubah pengaturan `wal_keep_segments` jika perlu. Misalnya, anggaplah log PostgreSQL di `checkpoint complete` menampilkan `35 recycled` selama interval 5 menit. Dalam hal ini, `wal_keep_segments` dengan nilai default 32 tidak cukup untuk mengimbangi aktivitas streaming, jadi Anda harus meningkatkan nilai parameter ini.
+ **Gunakan Amazon CloudWatch untuk memantau metrik yang dapat memprediksi masalah replikasi.** Daripada menganalisis log PostgreSQL secara langsung, Anda dapat menggunakan CloudWatch Amazon untuk memeriksa metrik yang telah dikumpulkan. Misalnya, Anda dapat memeriksa nilai metrik `TransactionLogsGeneration` untuk melihat berapa banyak data WAL yang dihasilkan oleh instans DB sumber. Dalam beberapa kasus, beban kerja pada instans DB Anda mungkin menghasilkan sejumlah besar data WAL. Jika demikian, Anda mungkin perlu mengubah kelas instans DB untuk instans DB sumber dan replika baca Anda. Penggunaan kelas instans dengan performa jaringan tinggi (10 Gbps) dapat mengurangi lag replika.
## Memantau slot replikasi untuk instans DB RDS for PostgreSQL Anda
Semua versi RDS for PostgreSQL menggunakan slot replikasi untuk replika baca lintas Wilayah. RDS for PostgreSQL 14.1 dan versi yang lebih tinggi menggunakan slot replikasi untuk replika baca dalam Wilayah. Replika baca dalam Wilayah juga menggunakan Amazon S3 untuk mengarsipkan data WAL. Dengan kata lain, jika instans DB dan replika baca Anda menjalankan PostgreSQL 14.1 atau lebih tinggi, slot replikasi dan arsip Amazon S3 keduanya tersedia untuk memulihkan replika baca. Memulihkan replika baca menggunakan slot replikasi lebih cepat daripada memulihkan dari arsip Amazon S3. Jadi, kami menyarankan Anda memantau slot replikasi dan metrik terkait.
Anda dapat melihat slot replikasi pada instans DB RDS for PostgreSQL Anda dengan mengueri tampilan `pg_replication_slots`, sebagai berikut.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
`wal_status` dengan nilai `reserved` berarti bahwa jumlah data WAL yang dipegang oleh slot berada dalam batas-batas parameter `max_wal_size`. Dengan kata lain, slot replikasi berukuran sesuai. Kemungkinan nilai lainnya adalah sebagai berikut:
+ `extended` – Slot melebihi pengaturan `max_wal_size`, tetapi data WAL dipertahankan.
+ `unreserved` – Slot tidak lagi memiliki semua data WAL yang diperlukan. Beberapa di antaranya akan dihapus di checkpoint berikutnya.
+ `lost` – Beberapa data WAL yang diperlukan telah dihapus. Slot tidak lagi dapat digunakan.
Keadaan `unreserved` dan `lost` keadaan hanya `wal_status` terlihat ketika `max_slot_wal_keep_size` tidak negatif.
Tampilan `pg_replication_slots` menunjukkan status slot replikasi Anda saat ini. Untuk menilai kinerja slot replikasi Anda, Anda dapat menggunakan Amazon CloudWatch dan memantau metrik berikut:
+ **`OldestReplicationSlotLag`**— Menunjukkan jumlah data Write-Ahead Log (WAL) pada sumber yang belum dikonsumsi oleh replika yang paling tertinggal.
+ **`TransactionLogsDiskUsage`** – Menunjukkan berapa banyak penyimpanan yang digunakan untuk data WAL. Ketika replika baca mengalami lag yang signifikan, nilai metrik ini dapat meningkat secara substansial.
Untuk mempelajari selengkapnya tentang menggunakan Amazon CloudWatch dan metriknya untuk RDS untuk PostgreSQL, lihat. [Memantau metrik Amazon RDS Aurora dengan Amazon CloudWatch](monitoring-cloudwatch.md) Untuk informasi selengkapnya tentang memantau replikasi streaming pada instans DB RDS for PostgreSQL Anda, lihat [Praktik terbaik untuk replikasi Amazon RDS PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) di *Blog Basis Data AWS *.
# Mengkonfigurasi replikasi tertunda dengan RDS untuk PostgreSQL
## Ikhtisar dan Manfaat
Fitur replikasi tertunda di RDS untuk PostgreSQL memungkinkan Anda untuk secara sengaja menunda replikasi perubahan data dari database utama Anda ke satu atau lebih server siaga (baca replika). Ini memberikan perlindungan yang berharga terhadap korupsi data, kehilangan data yang tidak disengaja, atau transaksi yang salah yang dapat segera disebarkan ke semua replika.
Replikasi tertunda didukung dalam RDS berikut untuk versi PostgreSQL:
+ 14.19 dan versi 14 yang lebih tinggi
+ 15.14 dan versi 15 yang lebih tinggi
+ 16.10 dan versi 16 yang lebih tinggi
+ 17.6 dan versi 17 yang lebih tinggi
Dengan memperkenalkan jeda waktu dalam proses replikasi, Anda mendapatkan kesempatan untuk mendeteksi dan menanggapi insiden terkait data sebelum mempengaruhi seluruh cluster DB Anda. Manfaat utama dari replikasi tertunda meliputi:
+ Memungkinkan Anda pulih dari penghapusan, pembaruan, atau kesalahan logis lainnya yang tidak disengaja.
+ Menyediakan buffer terhadap penyebaran data yang rusak di seluruh cluster DB Anda.
+ Menawarkan opsi titik pemulihan tambahan untuk melengkapi strategi pencadangan tradisional Anda.
+ Memungkinkan Anda mengonfigurasi periode penundaan berdasarkan kebutuhan spesifik organisasi Anda dan toleransi risiko.
## Mengaktifkan dan Mengkonfigurasi Replikasi Tertunda
Untuk mengaktifkan replikasi tertunda pada replika baca RDS untuk PostgreSQL, ikuti langkah-langkah berikut:
**catatan**
Untuk replika baca bertingkat, gunakan `recovery_min_apply_delay` parameter dan langkah yang sama yang dijelaskan di bawah ini.
**Untuk mengaktifkan replikasi tertunda**
1. Buat grup parameter kustom baru atau modifikasi yang sudah ada. Untuk informasi selengkapnya, lihat [Grup parameter DB untuk instans Amazon RDS Aurora DB](USER_WorkingWithDBInstanceParamGroups.md).
1. Dalam grup parameter, konfigurasikan `recovery_min_apply_delay` parameter:
+ Atur nilai ke penundaan yang diinginkan dalam milidetik. Misalnya, 3600000 untuk penundaan 1 jam.
+ Rentang yang diizinkan: 0 hingga 86400000 ms (0 hingga 24 jam)
+ Default: 0
1. Terapkan grup parameter ke instance replika baca yang ingin Anda konfigurasikan untuk replikasi tertunda.
1. Reboot instance replika baca agar perubahan diterapkan.
**catatan**
Parameter `recovery_min_apply_delay` bersifat dinamis. Jika Anda memodifikasi grup parameter yang sudah ada yang sudah dilampirkan ke instance, perubahan akan segera berlaku tanpa memerlukan reboot. Namun, saat menerapkan grup parameter baru ke instance, Anda harus reboot agar perubahan diterapkan.
## Mengelola Pemulihan Replikasi Tertunda
Replikasi yang tertunda sangat berguna dalam skenario di mana metode point-in-time pemulihan tradisional mungkin tidak mencukupi atau terlalu memakan waktu.
Selama periode replikasi tertunda, Anda dapat menggunakan fungsi PostgreSQL berikut untuk mengelola proses pemulihan:
+ `pg_wal_replay_pause()`: Permintaan untuk menjeda proses pemulihan pada replika yang tertunda.
+ `pg_wal_replay_resume()`: Mulai ulang proses pemulihan jika sebelumnya dijeda.
+ `pg_is_wal_replay_paused()`: Periksa apakah proses pemulihan saat ini dijeda.
+ `pg_get_wal_replay_pause_state()`: Dapatkan status proses pemulihan saat ini (tidak dijeda, jeda diminta, atau dijeda).
Pengguna dengan `rds_superuser` peran memiliki hak EXECUTE pada `pg_wal_replay_pause()` dan`pg_wal_replay_resume()`. Jika pengguna database lain memerlukan akses ke fungsi-fungsi ini, Anda harus memberi mereka `rds_superuser` peran. Untuk informasi selengkapnya tentang peran `rds_superuser` ini, lihat [Memahami peran rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
Akses ke fungsi lain seperti `pg_is_wal_replay_paused()` dan `pg_get_wal_replay_pause_state()` tidak memerlukan `rds_superuser` peran.
Anda dapat menggunakan parameter target pemulihan berikut untuk secara tepat mengontrol titik waktu di mana replika yang tertunda dipulihkan. Parameter ini statis dan memerlukan reboot database untuk menerapkan perubahan:
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**penting**
Anda hanya dapat menentukan satu parameter target pemulihan pada satu waktu. Mengkonfigurasi beberapa parameter target pemulihan dalam file konfigurasi menghasilkan kesalahan.
## Pertimbangan perencanaan
Pertimbangkan hal berikut saat merencanakan replikasi tertunda dengan RDS untuk PostgreSQL:
+ Selama rotasi `rdsrepladmin` kredensil otomatis (yang terjadi setiap 90 hari), replika baca yang tertunda dapat memasuki status sementara. `REPLICATION_ERROR` Jika replika yang tertunda memiliki log WAL yang cukup untuk mempertahankan penundaan yang dikonfigurasi, itu dapat menjeda proses penerima WAL, menyebabkan akumulasi WAL pada sumber. Anda harus memantau status replikasi pada replika dan konsumsi penyimpanan pada sumber untuk menghindari penyimpanan penuh.
+ Ketika replika baca yang tertunda menghadapi peristiwa sistem (seperti reboot atau restart), replika tersebut memasuki `REPLICATION_ERROR` keadaan di mana proses penerima WAL tetap tidak aktif hingga periode penundaan yang dikonfigurasi berakhir. Perilaku ini dapat menyebabkan akumulasi WAL pada instance sumber, yang berpotensi menyebabkan kelelahan penyimpanan. Pertimbangkan langkah-langkah pencegahan berikut:
+ Konfigurasikan CloudWatch alarm untuk memantau pemanfaatan penyimpanan pada instance sumber.
+ Aktifkan auto-scaling penyimpanan untuk menangani pertumbuhan WAL yang tidak terduga.
+ Atur `max_slot_wal_keep_size` parameter pada instance sumber untuk membatasi retensi WAL per slot replikasi.
+ Pantau kelambatan replikasi dan status slot secara teratur.
+ Penundaan yang lebih lama meningkatkan log WAL pada replika, menghabiskan lebih banyak penyimpanan. Pantau ruang penyimpanan menggunakan CloudWatch alarm, aktifkan auto-scaling, atau catch up replika bila diperlukan.
+ Saat mempromosikan replika baca yang tertunda, `recovery_min_apply_delay` parameter tidak dihormati, dan semua catatan WAL yang tertunda segera diterapkan.
+ `recovery_min_apply_delay`Parameter independen pada setiap tingkat pengaturan replikasi berjenjang. Menyetel penundaan pada replika tidak menambah penundaan replika bertingkat.
[Untuk informasi selengkapnya, lihat dokumentasi [RDS untuk PostgreSQL Read Replicas dan dokumentasi RDS untuk PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) Disaster Recovery.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html)
## Memahami keterbatasan
Fitur replikasi tertunda untuk Amazon RDS for PostgreSQL memiliki batasan berikut:
+ Penerapan Biru/Hijau memiliki batasan berikut saat mengonfigurasi replikasi yang tertunda:
+ **Instance sumber hijau** - `recovery_min_apply_delay parameter` Ini diabaikan, bahkan jika dikonfigurasi dalam grup parameter. Pengaturan penundaan apa pun pada instance sumber hijau tidak berlaku.
+ **Instance replika hijau** - `recovery_min_apply_delay parameter` Ini sepenuhnya didukung dan diterapkan ke file konfigurasi PostgreSQL. Pengaturan tunda berfungsi seperti yang diharapkan selama alur kerja switchover.
+ Blue/Green Penerapan RDS untuk peningkatan versi utama
+ Selama upgrade versi utama, setiap replika baca yang tertunda akan secara otomatis dihentikan untuk memungkinkan instance sumber untuk melanjutkan proses upgrade untuk memastikan downtime minimal. Setelah instance sumber menyelesaikan pemutakhiran, Anda harus membuat ulang replika yang tertunda secara manual.
+ Replikasi tertunda tidak kompatibel dengan fitur berikut.
+ RDS untuk Replikasi Logis PostgreSQL
+ RDS untuk PostgreSQL Multi-AZ Clusters (termasuk replikasi inbound dan outbound)
+ Aurora PostgreSQL
# Pemecahan masalah untuk RDS untuk PostgreSQL baca replika
Berikut ini, Anda dapat menemukan ide pemecahan masalah untuk beberapa RDS umum untuk masalah replika baca PostgreSQL.
**Mengakhiri kueri yang menyebabkan kelambatan replika baca**
Transaksi baik dalam keadaan aktif atau idle dalam keadaan transaksi yang berjalan untuk waktu yang lama dalam database dapat mengganggu proses replikasi WAL, sehingga meningkatkan kelambatan replikasi. Oleh karena itu, pastikan untuk memantau runtime transaksi ini dengan tampilan `pg_stat_activity` PostgreSQL.
Jalankan kueri pada instance utama yang mirip dengan berikut ini untuk menemukan ID proses (PID) kueri yang berjalan untuk waktu yang lama:
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Setelah mengidentifikasi PID kueri, Anda dapat memilih untuk mengakhiri kueri.
Jalankan kueri pada instance utama yang mirip dengan berikut ini untuk menghentikan kueri yang berjalan dalam waktu lama:
```
SELECT pg_terminate_backend(PID);
```
# Meningkatkan performa kueri untuk RDS for PostgreSQL dengan Amazon RDS Optimized Reads
Anda dapat mencapai pemrosesan kueri yang lebih cepat untuk RDS for PostgreSQL dengan Amazon RDS Optimized Reads. Instans DB RDS for PostgreSQL atau klaster DB Multi-AZ yang menggunakan RDS Optimized Reads dapat mencapai pemrosesan kueri hingga 50% lebih cepat dibandingkan dengan yang tidak menggunakannya.
**Topics**
+ [Ikhtisar RDS Optimized Reads di PostgreSQL](#USER_PostgreSQL.optimizedreads-overview)
+ [Kasus penggunaan untuk RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-use-cases)
+ [Praktik terbaik RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-best-practices)
+ [Menggunakan RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-using)
+ [Memantau instans DB yang menggunakan RDS Optimized Reads](#USER_PostgreSQL.optimizedreads-monitoring)
+ [Batasan untuk RDS Optimized Reads di PostgreSQL](#USER_PostgreSQL.optimizedreads-limitations)
## Ikhtisar RDS Optimized Reads di PostgreSQL
Bacaan yang Dioptimalkan tersedia secara default pada RDS untuk PostgreSQL versi 15.2 dan lebih tinggi, 14.7 dan lebih tinggi, dan 13.10 dan lebih tinggi saat menggunakan kelas instans DB berbasis. NVMe Untuk spesifikasi perangkat keras yang menunjukkan instance mana yang digunakan NVMe, lihat[Spesifikasi perangkat keras untuk kelas instans DB ](Concepts.DBInstanceClass.Summary.md).
Saat Anda menggunakan RDS untuk instans PostgreSQL DB atau cluster DB multi-AZ yang mengaktifkan RDS Optimized Reads, ini mencapai kinerja kueri hingga 50% lebih cepat menggunakan penyimpanan tingkat blok solid state drive (SSD) berbasis Non-Volatile Memory Express NVMe () lokal. Anda dapat mencapai pemrosesan kueri yang lebih cepat dengan menempatkan tabel sementara yang dihasilkan oleh PostgreSQL di penyimpanan lokal, yang akan mengurangi lalu lintas ke Elastic Block Storage (EBS) melalui jaringan.
Di PostgreSQL, objek sementara ditetapkan ke namespace sementara yang menurun secara otomatis di akhir sesi. Saat menurun, namespace sementara menghapus objek apa pun yang bergantung pada sesi, termasuk objek yang memenuhi syarat skema, seperti tabel, fungsi, operator, atau bahkan ekstensi.
Di RDS for PostgreSQL, parameter `temp_tablespaces` dikonfigurasi untuk area kerja sementara ini di mana objek sementara disimpan.
Kueri berikut mengembalikan nama tablespace dan lokasinya.
```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
rds_temp_tablespace
(1 row)
```
`rds_temp_tablespace`Ini adalah tablespace yang dikonfigurasi oleh RDS yang menunjuk ke penyimpanan NVMe lokal. Anda selalu dapat beralih kembali ke penyimpanan Amazon EBS dengan memodifikasi parameter ini dalam `Parameter group` menggunakan Konsol Manajemen AWS to point ke tablespace selain. `rds_temp_tablespace` Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Modifying.md). Anda juga dapat menggunakan perintah SET untuk memodifikasi nilai parameter `temp_tablespaces` menjadi `pg_default` di tingkat sesi menggunakan perintah SET. Memodifikasi parameter akan mengalihkan area kerja sementara ke Amazon EBS. Peralihan kembali ke Amazon EBS akan membantu ketika penyimpanan lokal untuk klaster atau instans RDS Anda tidak cukup untuk melakukan operasi SQL tertentu.
```
postgres=> SET temp_tablespaces TO 'pg_default';
SET
```
```
postgres=> show temp_tablespaces;
temp_tablespaces
------------------
pg_default
```
## Kasus penggunaan untuk RDS Optimized Reads
Berikut ini adalah beberapa kasus penggunaan yang dapat memperoleh manfaat dari Optimized Reads:
+ Kueri analitis yang mencakup Ekspresi Tabel Umum (CTEs), tabel turunan, dan operasi pengelompokan.
+ Replika baca yang menangani kueri yang tidak dioptimalkan untuk aplikasi.
+ Kueri pelaporan sesuai permintaan atau dinamis dengan operasi kompleks seperti GROUP BY dan ORDER BY yang tidak selalu dapat menggunakan indeks yang sesuai.
+ Beban kerja lain yang menggunakan tabel sementara internal.
+ `CREATE INDEX`atau `REINDEX` operasi untuk menyortir.
## Praktik terbaik RDS Optimized Reads
Gunakan praktik terbaik RDS Optimized Reads berikut:
+ Tambahkan logika coba lagi untuk kueri hanya baca jika terjadi kegagalan karena penyimpanan instans penuh selama eksekusi.
+ Pantau ruang penyimpanan yang tersedia di penyimpanan instans dengan CloudWatch metrik`FreeLocalStorage`. Jika penyimpanan instans mencapai batasnya karena beban kerja pada instans DB atau klaster DB Multi-AZ, modifikasi untuk menggunakan kelas instans DB yang lebih besar.
## Menggunakan RDS Optimized Reads
Saat Anda menyediakan RDS untuk instans PostgreSQL DB dengan salah satu kelas instans DB berbasis dalam penerapan NVMe instans DB tunggal AZ, penerapan instans DB multi-AZ, atau penerapan klaster DB multi-AZ, instans DB secara otomatis menggunakan RDS Optimized Reads.
Untuk informasi selengkapnya tentang penerapan Multi-AZ, lihat. [Mengonfigurasi dan mengelola penyebaran Multi-AZ untuk Amazon RDS](Concepts.MultiAZ.md)
Untuk mengaktifkan RDS Optimized Reads, lakukan salah satu tindakan berikut ini:
+ Buat RDS untuk instance PostgreSQL DB atau cluster DB multi-AZ menggunakan salah satu kelas instans DB berbasis. NVMe Untuk informasi selengkapnya, lihat [Membuat instans DB Amazon RDS](USER_CreateDBInstance.md).
+ Ubah RDS yang ada untuk instans PostgreSQL DB atau cluster DB multi-AZ untuk menggunakan salah satu kelas instans DB berbasis. NVMe Untuk informasi selengkapnya, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
RDS Optimized Reads tersedia di semua Wilayah AWS tempat satu atau lebih kelas instans DB dengan penyimpanan NVMe SSD lokal didukung. Untuk informasi selengkapnya, lihat [ DB](Concepts.DBInstanceClass.md).
Untuk beralih kembali ke instans RDS baca yang tidak dioptimalkan, modifikasi kelas instans DB dari klaster atau instans RDS Anda menjadi kelas instans serupa yang hanya mendukung penyimpanan EBS untuk beban kerja basis data Anda. Misalnya, jika kelas instans DB saat ini adalah db.r6gd.4xlarge, pilih db.r6g.4xlarge untuk beralih kembali. Untuk informasi selengkapnya, lihat [Memodifikasi instans DB Amazon RDS](Overview.DBInstance.Modifying.md).
## Memantau instans DB yang menggunakan RDS Optimized Reads
Anda dapat memantau instans DB yang menggunakan Bacaan yang Dioptimalkan RDS menggunakan metrik berikut: CloudWatch
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Metrik ini menyediakan data tentang penyimpanan instans, IOPS, dan throughput yang tersedia. Untuk informasi selengkapnya tentang metrik ini, lihat [Metrik CloudWatch tingkat instans Amazon untuk Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
Untuk memantau penggunaan penyimpanan lokal Anda saat ini, masuk ke database Anda dan jalankan kueri berikut:
```
SELECT
spcname AS "Name",
pg_catalog.pg_size_pretty(pg_catalog.pg_tablespace_size(oid)) AS "size"
FROM
pg_catalog.pg_tablespace
WHERE
spcname IN ('rds_temp_tablespace');
```
Untuk informasi selengkapnya tentang file sementara dan penggunaannya, lihat[Mengelola file sementara dengan PostgreSQL](PostgreSQL.ManagingTempFiles.md).
## Batasan untuk RDS Optimized Reads di PostgreSQL
Batasan berikut berlaku untuk RDS Optimized Reads di PostgreSQL:
+ Transaksi dapat gagal ketika penyimpanan instans penuh.
# Mengimpor data ke PostgreSQL di Amazon RDS
Misalkan Anda memiliki deployment PostgreSQL yang ingin Anda pindahkan ke Amazon RDS. Kompleksitas tugas Anda bergantung pada ukuran basis data Anda dan jenis objek basis data yang Anda transfer. Misalnya, pertimbangkan basis data yang berisi set data dalam urutan gigabyte, bersama dengan prosedur yang tersimpan dan pemicu. Basis data seperti itu akan menjadi lebih rumit dibandingkan basis data sederhana dengan hanya beberapa megabyte data uji dan tanpa pemicu atau prosedur tersimpan.
Kami menyarankan Anda untuk menggunakan alat migrasi basis data PostgreSQL native dalam kondisi berikut:
+ Anda memiliki migrasi yang homogen, yaitu Anda bermigrasi dari basis data dengan mesin basis data yang sama dengan basis data target.
+ Anda memigrasikan seluruh basis data.
+ Alat native memungkinkan Anda untuk memigrasi sistem Anda dengan waktu henti minimal.
Dalam kebanyakan kasus lain, melakukan migrasi AWS database menggunakan Database Migration Service (AWS DMS) adalah pendekatan terbaik. AWS DMS dapat memigrasikan database tanpa downtime dan, untuk banyak mesin database, melanjutkan replikasi yang sedang berlangsung sampai Anda siap untuk beralih ke database target. Anda dapat bermigrasi ke mesin database yang sama atau mesin database yang berbeda menggunakan AWS DMS. Jika Anda bermigrasi ke mesin database yang berbeda dari database sumber Anda, Anda dapat menggunakan AWS Schema Conversion Tool (AWS SCT). Anda gunakan AWS SCT untuk memigrasikan objek skema yang tidak dimigrasikan oleh. AWS DMS Untuk informasi lebih lanjut tentang AWS DMS, lihat [Apa itu? AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)
Ubah grup parameter DB Anda untuk menyertakan pengaturan berikut *hanya untuk impor Anda*. Selain itu, uji juga pengaturan parameter guna menemukan pengaturan yang paling efisien untuk instans DB Anda. Anda juga perlu mengembalikan parameter ini ke nilai produksi setelah pengimporan selesai.
Ubah pengaturan instans DB Anda sebagai berikut:
+ Nonaktifkan pencadangan instans DB (ubah backup\$1retention menjadi 0).
+ Nonaktifkan Multi-AZ.
Ubah grup parameter DB Anda untuk menyertakan pengaturan berikut. Anda sebaiknya hanya menggunakan pengaturan ini saat mengimpor data. Selain itu, uji juga pengaturan parameter guna menemukan pengaturan yang paling efisien untuk instans DB Anda. Anda juga perlu mengembalikan parameter ini ke nilai produksi setelah pengimporan selesai.
| Parameter | Nilai yang disarankan saat mengimpor | Deskripsi |
| --- | --- | --- |
| `maintenance_work_mem` | 524288, 1048576, 2097152 atau 4194304 (dalam KB). Pengaturan ini setara dengan 512 MB, 1 GB, 2 GB, dan 4 GB. | Nilai untuk pengaturan ini bergantung pada ukuran host Anda. Parameter ini digunakan selama pernyataan CREATE INDEX dan setiap perintah paralel dapat menggunakan memori sebanyak ini. Hitung nilai terbaik agar Anda tidak mengatur nilai ini terlalu tinggi dan kehabisan memori. |
| `max_wal_size` | 256 (untuk versi 9.6), 4096 (untuk versi 10 dan yang lebih tinggi) | Ukuran maksimum untuk membiarkan WAL tumbuh selama pemeriksaan otomatis. Meningkatkan parameter ini dapat meningkatkan jumlah waktu yang dibutuhkan untuk pemulihan setelah crash. Parameter ini menggantikan `checkpoint_segments` untuk PostgreSQL 9.6 dan yang lebih baru. Untuk PostgreSQL versi 9.6, nilai ini dalam unit 16 MB. Untuk versi yang lebih baru, nilainya dalam unit 1 MB. Misalnya, dalam versi 9.6, 128 berarti 128 potongan yang masing-masing berukuran 16 MB. Misalnya, dalam versi 12.4, 2048 berarti 2048 potongan yang masing-masing berukuran 1 MB. |
| `checkpoint_timeout` | 1800 | Nilai untuk pengaturan ini memungkinkan rotasi WAL yang lebih jarang. |
| `synchronous_commit` | Mati | Nonaktifkan pengaturan ini untuk mempercepat penulisan. Menonaktifkan parameter ini dapat meningkatkan risiko kehilangan data jika terjadi crash pada server (jangan menonaktifkan FSYNC). |
| `wal_buffers` | 8192 | Ini adalah nilai dalam unit 8 KB. Ini juga membantu kecepatan pembuatan WAL Anda |
| `autovacuum` | 0 | Nonaktifkan parameter vakum otomatis PostgreSQL saat Anda memuat data agar sumber daya tidak digunakan |
Gunakan perintah `pg_dump -Fc` (terkompresi) atau `pg_restore -j` (paralel) dengan pengaturan ini.
**catatan**
Perintah PostgreSQL `pg_dumpall` memerlukan izin super\$1user yang tidak diberikan saat Anda membuat instans DB, sehingga tidak dapat digunakan untuk mengimpor data.
**Topics**
+ [Mengimpor basis data PostgreSQL dari instans Amazon EC2](PostgreSQL.Procedural.Importing.EC2.md)
+ [Menggunakan perintah \$1copy untuk mengimpor data ke tabel di instans DB PostgreSQL](PostgreSQL.Procedural.Importing.Copy.md)
+ [Mengimpor data dari Amazon S3 ke instans DB RDS for PostgreSQL](USER_PostgreSQL.S3Import.md)
+ [Mengangkut basis data PostgreSQL antara instans DB](PostgreSQL.TransportableDB.md)
# Mengimpor basis data PostgreSQL dari instans Amazon EC2
Jika Anda memiliki data di server PostgreSQL pada instans Amazon EC2 dan ingin memindahkannya ke instans PostgreSQL DB, Anda dapat mengikuti proses ini untuk memigrasikan data.
1. Buat berkas menggunakan pg\$1dump yang berisi data yang akan dimuat
1. Buat instans DB target
1. Gunakan *psql* untuk membuat basis data pada instans DB dan muat data
1. Buat snapshot DB dari instans DB
Bagian berikut memberikan rincian lebih lanjut pada setiap langkah yang tercantum di atas.
## Langkah 1: Buat file menggunakan pg\$1dump yang berisi data yang akan dimuat
Utilitas `pg_dump` menggunakan perintah COPY untuk membuat skema dan dump data dari basis data PostgreSQL. Skrip dump yang dibuat oleh `pg_dump` memuat data ke dalam basis data dengan nama yang sama dan membuat ulang tabel, indeks, dan kunci asing. Anda dapat menggunakan perintah `pg_restore` dan parameter `-d` untuk memulihkan data ke basis data dengan nama yang berbeda.
Sebelum Anda membuat dump data, Anda harus melakukan kueri tabel yang akan di-dump untuk mendapatkan jumlah baris sehingga Anda dapat mengonfirmasi jumlah pada instans DB target.
Perintah berikut membuat file dump bernama mydb2dump.sql untuk basis data bernama mydb2.
```
prompt>pg_dump dbname=mydb2 -f mydb2dump.sql
```
## Langkah 2: Buat instans DB target
Buat instans DB PostgreSQL target menggunakan konsol Amazon RDS, AWS CLI, atau API. Buat instans dengan pengaturan retensi cadangan yang diatur ke 0 dan nonaktifkan Multi-AZ. Hal ini akan mempercepat impor data. Anda harus membuat basis data pada instans tersebut sebelum data dapat di-dump. Basis data tersebut bisa memiliki nama yang sama dengan basis data yang berisi data yang di-dump. Anda juga dapat membuat basis data dengan nama berbeda. Dalam kasus ini, gunakan perintah `pg_restore` dan parameter `-d` untuk memulihkan data ke basis data yang baru diberi nama.
Misalnya, perintah berikut dapat digunakan untuk mengeluarkan, memulihkan, dan mengubah nama basis data.
```
pg_dump -Fc -v -h [endpoint of instance] -U [master username] [database] > [database].dump
createdb [new database name]
pg_restore -v -h [endpoint of instance] -U [master username] -d [new database name] [database].dump
```
## Langkah 3: Gunakan psql untuk membuat basis data pada instans DB dan muat data
Anda dapat menggunakan koneksi yang sama yang Anda gunakan untuk menjalankan perintah pg\$1dump untuk terhubung ke instans DB target dan membuat ulang basis data. Menggunakan *psql*, Anda bisa menggunakan nama pengguna master dan kata sandi master untuk membuat basis data pada instans DB
Contoh berikut menggunakan *psql* dan file dump bernama mydb2dump.sql untuk membuat basis data bernama mydb2 di instans DB PostgreSQL bernama mypginstance:
Untuk Linux, macOS, atau Unix:
```
psql \
-f mydb2dump.sql \
--host mypginstance.555555555555.aws-region.rds.amazonaws.com \
--port 8199 \
--username myawsuser \
--password password \
--dbname mydb2
```
Untuk Windows:
```
psql ^
-f mydb2dump.sql ^
--host mypginstance.555555555555.aws-region.rds.amazonaws.com ^
--port 8199 ^
--username myawsuser ^
--password password ^
--dbname mydb2
```
**catatan**
Tentukan kata sandi selain perintah yang ditampilkan di sini sebagai praktik terbaik keamanan.
## Langkah 4: Buat snapshot DB dari instans DB
Setelah Anda memverifikasi bahwa data telah dimuat ke dalam instans DB Anda, kami sarankan Anda membuat snapshot DB dari instans DB PostgreSQL target. Snapshot DB adalah cadangan lengkap instans DB Anda yang dapat digunakan untuk memulihkan instans DB Anda ke status yang diketahui. Dengan snapshot DB yang diambil segera setelah pemuatan, Anda tidak perlu memuat data lagi jika terjadi hal yang tidak diinginkan. Anda juga dapat menggunakan snapshot tersebut untuk memulai instans DB baru. Untuk informasi selengkapnya tentang cara membuat snapshot DB secara manual, lihat [Membuat snapshot DB untuk instans DB AZ tunggal untuk Amazon RDS](USER_CreateSnapshot.md).
# Menggunakan perintah \$1copy untuk mengimpor data ke tabel di instans DB PostgreSQL
Perintah `\copy` PostgreSQL adalah perintah meta yang tersedia dari alat klien interaktif `psql`. Anda dapat menggunakan `\copy` untuk mengimpor data ke tabel di instans DB RDS for PostgreSQL. Untuk menggunakan perintah `\copy`, Anda harus membuat struktur tabel pada instans DB target terlebih dahulu agar `\copy` memiliki tujuan untuk salinan data.
Anda dapat menggunakan `\copy` untuk memuat data dari file nilai yang dipisahkan koma (CSV), seperti file yang telah diekspor dan disimpan ke workstation klien Anda.
Untuk mengimpor data CSV ke instans DB RDS for PostgreSQL target, pertama-tama sambungkan ke instans DB target menggunakan `psql`.
```
psql --host=db-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=target-db
```
Anda kemudian menjalankan perintah `\copy` dengan parameter berikut untuk mengidentifikasi target untuk data dan formatnya.
+ `target_table` – Nama tabel yang akan menerima data yang disalin dari file CSV.
+ `column_list` – Spesifikasi kolom untuk tabel.
+ `'filename'` – Jalur lengkap ke file CSV di workstation lokal Anda.
```
\copy target_table from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV;
```
Jika file CSV Anda memiliki informasi judul kolom, Anda dapat menggunakan versi perintah dan parameter ini.
```
\copy target_table (column-1, column-2, column-3, ...)
from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV HEADER;
```
Jika perintah `\copy` gagal, PostgreSQL mengeluarkan pesan kesalahan.
Membuat instans DB baru di lingkungan Database Preview menggunakan perintah `psql` dengan perintah meta `\copy` seperti yang ditunjukkan pada contoh berikut. Contoh ini menggunakan *source-table* sebagai nama tabel sumber, *source-table.csv* sebagai file .csv, dan *target-db* sebagai basis data target:
Untuk Linux, macOS, atau Unix:
```
$psql target-db \
-U \
-p \
-h \
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Untuk Windows:
```
$psql target-db ^
-U ^
-p ^
-h ^
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Untuk detail lengkap tentang perintah `\copy`, lihat halaman [psql](http://www.postgresql.org/docs/current/static/app-psql.html) dalam dokumentasi PostgreSQL, di bagian *Meta-Commands*.
# Mengimpor data dari Amazon S3 ke instans DB RDS for PostgreSQL
Anda dapat mengimpor data yang telah disimpan menggunakan Amazon Simple Storage Service ke dalam tabel pada instans RDS for PostgreSQL. Untuk melakukannya, instal ekstensi RDS for PostgreSQL `aws_s3` terlebih dahulu. Ekstensi ini menyediakan fungsi yang Anda gunakan untuk mengimpor data dari bucket Amazon S3. *Bucket* adalah kontainer Amazon S3 untuk objek dan file. Data dapat berada dalam file nilai yang dipisahkan koma (CSV), file teks, atau file terkompresi (gzip). Berikut ini, Anda dapat mempelajari cara menginstal ekstensi dan cara mengimpor data dari Amazon S3 ke dalam tabel.
Basis data Anda harus menjalankan PostgreSQL versi 10.7 atau yang lebih tinggi untuk mengimpor dari Amazon S3 ke RDS for PostgreSQL.
Jika tidak memiliki data yang tersimpan di Amazon S3, Anda harus terlebih dahulu membuat bucket dan menyimpan data. Untuk informasi selengkapnya, lihat topik berikut di *Panduan Pengguna Amazon Simple Storage Service*.
+ [Membuat bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [Menambahkan objek ke bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
Impor lintas akun dari Amazon S3 didukung. Untuk informasi selengkapnya, lihat [ Memberikan izin lintas akun](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) di *Panduan Pengguna Amazon Simple Storage Service User Guide*.
Anda dapat menggunakan kunci yang dikelola pelanggan untuk enkripsi saat mengimpor data dari S3. Untuk informasi selengkapnya, lihat [ kunci KMS yang disimpan di AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) dalam *Panduan Pengguna Amazon Simple Storage Service*.
**Topics**
+ [Menginstal ekstensi aws\$1s3](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [Ikhtisar impor data dari data Amazon S3](USER_PostgreSQL.S3Import.Overview.md)
+ [Menyiapkan akses ke bucket Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [Mengimpor data dari Amazon S3 ke](USER_PostgreSQL.S3Import.FileFormats.md)
+ [Referensi fungsi](USER_PostgreSQL.S3Import.Reference.md)
# Menginstal ekstensi aws\$1s3
Sebelum Anda dapat menggunakan Amazon S3 dengan Anda perlu menginstal ekstensi. `aws_s3` Ekstensi ini menyediakan fungsi untuk mengimpor data dari Amazon S3. Ini juga menyediakan fungsi untuk mengekspor data dari ke SQL bucket Amazon S3. Untuk informasi selengkapnya, lihat [Mengekspor data dari instans DB RDS for PostgreSQL ke Amazon S3](postgresql-s3-export.md). Ekstensi `aws_s3` bergantung pada beberapa fungsi pembantu dalam ekstensi `aws_commons`, yang diinstal secara otomatis bila diperlukan.
**Untuk menginstal ekstensi `aws_s3`**
1. Gunakan psql (ataupgAdmin) untuk terhubung ke sebagai pengguna yang memiliki hak SQL istimewa. `rds_superuser` Jika Anda menyimpan nama default selama proses penyiapan, Anda terhubung sebagai `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Untuk menginstal ekstensi, jalankan perintah berikut.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Untuk memverifikasi bahwa ekstensi sudah diinstal, Anda dapat menggunakan metacommand psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Fungsi untuk mengimpor data dari Amazon S3 dan mengekspor data ke Amazon S3 kini dapat digunakan.
# Ikhtisar impor data dari data Amazon S3
**Untuk mengimpor data S3 ke Amazon RDS**
Pertama, kumpulkan detail yang perlu Anda suplai ke fungsi tersebut. Ini termasuk nama tabel pada instance klaster dan nama bucket, jalur file, jenis file, dan tempat penyimpanan data Amazon S3. Wilayah AWS Untuk informasi selengkapnya, buka [Melihat objek](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) di *Panduan Pengguna Amazon Simple Storage Service*.
**catatan**
Impor data multi bagian dari Amazon S3 saat ini tidak didukung.
1. Dapatkan nama tabel di mana fungsi `aws_s3.table_import_from_s3` adalah untuk mengimpor data. Sebagai contoh, perintah berikut membuat tabel `t1` yang dapat digunakan di langkah selanjutnya.
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Dapatkan detail tentang bucket Amazon S3 dan data yang akan diimpor. **Untuk melakukan ini, buka konsol Amazon S3 di [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/), dan pilih Bucket.** Temukan bucket yang berisi data Anda dalam daftar. Pilih bucket, buka halaman ikhtisar Object, lalu pilih Properti.
Catat nama bucket, path Wilayah AWS, dan jenis file. Anda memerlukan Amazon Resource Name (ARN) nanti, untuk menyiapkan akses ke Amazon S3 melalui peran IAM. Untuk informasi selengkapnya, lihat [Menyiapkan akses ke bucket Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md). Bagian berikut menunjukkan satu contoh.
![\[Gambar objek file dalam bucket Amazon S3.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. Anda dapat memverifikasi jalur ke data di bucket Amazon S3 dengan menggunakan perintah. AWS CLI `aws s3 cp` Jika informasinya benar, perintah ini akan mengunduh salinan file Amazon S3.
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. Siapkan izin di instans DB RDS for PostgreSQL untuk mengizinkan akses ke file di bucket Amazon S3. Untuk melakukannya, Anda menggunakan peran AWS Identity and Access Management (IAM) atau kredensil keamanan. Untuk informasi selengkapnya, lihat [Menyiapkan akses ke bucket Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md).
1. Berikan jalur dan detail objek Amazon S3 lainnya yang dikumpulkan (lihat langkah 2) ke fungsi `create_s3_uri` untuk membuat konsep objek URI Amazon S3. Untuk mempelajari selengkapnya tentang fungsi ini, lihat [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri). Berikut ini adalah contoh pembuatan konsep objek ini selama sesi psql.
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
Pada langkah berikutnya, Anda meneruskan objek ini (`aws_commons._s3_uri_1`) ke fungsi `aws_s3.table_import_from_s3` untuk mengimpor data ke tabel.
1. Invokasi fungsi `aws_s3.table_import_from_s3` untuk mengimpor data dari Amazon S3 ke dalam tabel Anda. Untuk informasi referensi, lihat [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3). Sebagai contoh, lihat [Mengimpor data dari Amazon S3 ke ](USER_PostgreSQL.S3Import.FileFormats.md).
# Menyiapkan akses ke bucket Amazon S3
Untuk mengimpor data dari file Amazon S3, beri izin instans DB RDS for PostgreSQL untuk mengakses bucket Amazon S3 yang berisi file tersebut. Berikan akses ke bucket Amazon S3 dengan satu dari dua cara, seperti yang dijelaskan dalam topik berikut.
**Topics**
+ [Menggunakan peran IAM untuk mengakses bucket Amazon S3](#USER_PostgreSQL.S3Import.ARNRole)
+ [Menggunakan kredensial rahasia untuk mengakses bucket Amazon S3](#USER_PostgreSQL.S3Import.Credentials)
+ [Memecahkan masalah akses ke Amazon S3](#USER_PostgreSQL.S3Import.troubleshooting)
## Menggunakan peran IAM untuk mengakses bucket Amazon S3
Sebelum Anda memuat data dari file Amazon S3, beri izin instans DB RDS for PostgreSQL untuk mengakses bucket Amazon S3 tempat file berada. Dengan cara ini, Anda tidak perlu mengelola informasi kredensial tambahan atau menyediakannya di panggilan fungsi [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Untuk melakukannya, buat kebijakan IAM yang memberikan akses ke bucket Amazon S3. Buat peran IAM lampirkan kebijakan ke peran tersebut. Kemudian, tetapkan peran IAM ke instans DB Anda.
**Untuk memberikan instans DB RDS for PostgreSQL izin akses ke Amazon S3 melalui IAM role**
1. Buat kebijakan IAM.
Kebijakan ini memberi bucket dan objek izin yang memungkinkan instans DB RDS for PostgreSQL Anda mengakses Amazon S3.
Sertakan tindakan yang diperlukan berikut dalam kebijakan untuk mengizinkan transfer file dari bucket Amazon S3 ke Amazon RDS:
+ `s3:GetObject`
+ `s3:ListBucket`
Sertakan sumber daya berikut dalam kebijakan untuk mengidentifikasi bucket dan objek Amazon S3 dalam bucket. Ini menunjukkan format Amazon Resource Name (ARN) untuk mengakses Amazon S3.
+ arn:aws:s3::: *amzn-s3-demo-bucket*
+ arn:aws:s3::: /\$1 *amzn-s3-demo-bucket*
Untuk informasi selengkapnya tentang cara membuat kebijakan IAM untuk RDS for PostgreSQL, lihat [Membuat dan menggunakan kebijakan IAM untuk akses basis data IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Lihat juga [Tutorial: Membuat dan melampirkan kebijakan yang dikelola pelanggan pertama Anda](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) di *Panduan Pengguna IAM*.
AWS CLI Perintah berikut membuat kebijakan IAM bernama `rds-s3-import-policy` dengan opsi ini. Perintah ini akan memberikan akses ke bucket bernama *amzn-s3-demo-bucket*.
**catatan**
Catat Amazon Resource Name (ARN) dari kebijakan yang ditampilkan oleh perintah ini. Anda memerlukan ARN di langkah berikutnya saat Anda melampirkan kebijakan ke peran IAM.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
Untuk Windows:
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Buat peran IAM.
Anda melakukan ini sehingga Amazon RDS dapat mengambil peran IAM ini untuk mengakses bucket Amazon S3 Anda. Untuk informasi selengkapnya, lihat [Membuat peran untuk mendelegasikan izin ke pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dalam *Panduan Pengguna IAM*.
Sebaiknya gunakan kunci konteks kondisi global `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` dan `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` dalam kebijakan berbasis sumber daya untuk membatasi izin layanan ke sumber daya tertentu. Ini adalah cara paling efektif untuk melindungi dari [masalah deputi yang membingungkan](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Jika Anda menggunakan kunci konteks kondisi global dan nilai `aws:SourceArn` berisi ID akun, nilai `aws:SourceAccount` dan akun dalam nilai `aws:SourceArn` harus menggunakan ID akun yang sama saat digunakan dalam pernyataan kebijakan yang sama.
+ Gunakan `aws:SourceArn` jika Anda menginginkan akses lintas layanan untuk satu sumber daya.
+ Gunakan `aws:SourceAccount` jika Anda ingin mengizinkan sumber daya apa pun di akun tersebut dikaitkan dengan penggunaan lintas layanan.
Dalam kebijakan, pastikan untuk menggunakan kunci konteks kondisi global `aws:SourceArn` dengan ARN penuh sumber daya. Contoh berikut menunjukkan bagaimana melakukannya dengan menggunakan AWS CLI perintah untuk membuat peran bernama`rds-s3-import-role`.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Untuk Windows:
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Lampirkan kebijakan IAM yang Anda buat ke peran IAM yang Anda buat.
AWS CLI Perintah berikut melampirkan kebijakan yang dibuat pada langkah sebelumnya ke peran bernama `rds-s3-import-role` Ganti `your-policy-arn` dengan ARN kebijakan yang Anda catat di langkah sebelumnya.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
Untuk Windows:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. Tambahkan peran IAM ke instans DB.
Anda melakukannya dengan menggunakan Konsol Manajemen AWS atau AWS CLI, seperti yang dijelaskan berikut.
### Konsol
**Untuk menambahkan peran IAM untuk instans DB PostgreSQL menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih nama instans DB PostgreSQL untuk menampilkan detailnya.
1. Di tab **Konektivitas & keamanan**, di bagian **Kelola peran IAM**, pilih peran yang akan ditambahkan pada bagian **Tambahkan peran IAM ke instans ** ini.
1. Di bagian **Fitur**, pilih **s3Import**.
1. Pilih **Tambahkan peran**.
### AWS CLI
**Untuk menambahkan peran IAM untuk instans DB PostgreSQL menggunakan CLI**
+ Gunakan perintah berikut untuk menambahkan peran ke instans DB PostgreSQL bernama `my-db-instance`. Ganti *`your-role-arn`* dengan ARN peran yang Anda catat pada langkah sebelumnya. Gunakan `s3Import` untuk nilai opsi `--feature-name`.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
Untuk Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### API RDS
Untuk menambahkan peran IAM untuk instance PostgreSQL DB menggunakan Amazon RDS API, panggil operasi.
## Menggunakan kredensial rahasia untuk mengakses bucket Amazon S3
Jika ingin, Anda dapat menggunakan kredensial rahasia untuk memberikan akses ke bucket Amazon S3, alih-alih memberikan akses ke peran IAM. Anda melakukannya dengan menentukan parameter `credentials` dalam panggilan fungsi [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
`credentials`Parameternya adalah struktur tipe`aws_commons._aws_credentials_1`, yang berisi AWS kredensyal. Gunakan fungsi [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) untuk mengatur kunci akses dan kunci rahasia dalam struktur `aws_commons._aws_credentials_1`, seperti yang ditunjukkan berikut ini.
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
Setelah membuat struktur `aws_commons._aws_credentials_1 `, gunakan fungsi [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) yang dengan parameter `credentials` untuk mengimpor data, seperti yang ditunjukkan berikut.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
Atau Anda dapat menyertakan panggilan fungsi [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) sebaris dalam panggilan fungsi `aws_s3.table_import_from_s3`.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Memecahkan masalah akses ke Amazon S3
Jika Anda mengalami masalah koneksi saat mencoba mengimpor data dari Amazon S3, lihat rekomendasi berikut:
+ [Memecahkan masalah identitas dan akses Amazon RDS](security_iam_troubleshoot.md)
+ [Memecahkan Masalah Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) di *Panduan Pengguna Amazon Simple Storage Service*
+ [Memecahkan Masalah Amazon S3 dan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) di *Panduan Pengguna IAM*
# Mengimpor data dari Amazon S3 ke
Anda mengimpor data dari bucket Amazon S3 dengan menggunakan fungsi `table_import_from_s3` aws\$1s3. Untuk informasi referensi, lihat [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
**catatan**
Contoh berikut menggunakan metode peran IAM untuk mengizinkan akses ke bucket Amazon S3. Dengan demikian, panggilan fungsi `aws_s3.table_import_from_s3` tidak termasuk parameter kredensial.
Berikut ini menunjukkan contoh khas.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
Parameternya sebagai berikut:
+ `t1` – Nama untuk tabel dalam instans DB PostgreSQL tempat tujuan penyalinan data.
+ `''` – Daftar opsional kolom dalam tabel basis data. Anda dapat menggunakan parameter ini untuk menunjukkan kolom data S3 mana yang masuk ke kolom tabel mana. Jika tidak ada kolom yang ditentukan, semua kolom akan disalin ke tabel. Untuk contoh cara menggunakan daftar kolom, lihat [Mengimpor file Amazon S3 yang menggunakan pemisah kustom](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
+ `(format csv)` – Argumen PostgreSQL COPY. Proses penyalinan menggunakan argumen dan format perintah [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) untuk mengimpor data. Pilihan untuk format mencakup nilai yang dipisahkan koma (CSV) seperti yang ditunjukkan dalam contoh ini, teks, dan biner. Defaultnya adalah teks.
+ `s3_uri` – Struktur yang berisi informasi yang mengidentifikasi file Amazon S3. Untuk contoh penggunaan fungsi [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) untuk membuat struktur `s3_uri`, lihat [Ikhtisar impor data dari data Amazon S3](USER_PostgreSQL.S3Import.Overview.md).
Untuk informasi selengkapnya tentang fungsi ini, lihat [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Fungsi `aws_s3.table_import_from_s3` menampilkan teks. Untuk menentukan jenis file lain yang akan diimpor dari bucket Amazon S3, lihat salah satu contoh berikut.
**catatan**
Mengimpor file 0 byte akan menyebabkan kesalahan.
**Topics**
+ [Mengimpor file Amazon S3 yang menggunakan pemisah kustom](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [Mengimpor file terkompresi (gzip) Amazon S3](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [Mengimpor file Amazon S3 yang dienkode](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## Mengimpor file Amazon S3 yang menggunakan pemisah kustom
Contoh berikut menunjukkan cara mengimpor file yang menggunakan pemisah kustom. Ini juga menunjukkan cara mengontrol lokasi penempatan data dalam tabel basis data menggunakan parameter `column_list` fungsi [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Untuk contoh ini, asumsikan bahwa informasi berikut ini diatur ke dalam kolom yang dipisahkan tanda pipa di file Amazon S3.
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**Untuk mengimpor file yang menggunakan pemisah kustom**
1. Buat tabel dalam basis data untuk data yang diimpor.
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. Gunakan bentuk berikut fungsi [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) berikut untuk mengimpor data dari file Amazon S3.
Anda dapat memasukkan panggilan fungsi [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) sebaris dalam panggilan fungsi `aws_s3.table_import_from_s3` untuk menentukan file.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
Data tersebut ini berada dalam tabel di kolom berikut.
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Mengimpor file terkompresi (gzip) Amazon S3
Contoh berikut menunjukkan cara mengimpor file dari Amazon S3 yang dikompresi menggunakan gzip. File yang Anda impor harus memiliki metadata Amazon S3 berikut:
+ Kunci: `Content-Encoding`
+ Nilai: `gzip`
Jika Anda mengunggah file menggunakan Konsol Manajemen AWS, metadata biasanya diterapkan oleh sistem. Untuk informasi tentang mengunggah file ke Amazon S3 menggunakan Konsol Manajemen AWS, API, AWS CLI atau API, [lihat Mengunggah](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) objek di Panduan Pengguna Layanan *Penyimpanan Sederhana Amazon*.
Untuk informasi selengkapnya tentang metadata Amazon S3 dan detail tentang metadata yang disediakan sistem, lihat [Mengedit metadata objek di konsol Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) di *Panduan Pengguna Amazon Simple Storage Service*.
Impor file gzip ke dalam instans DB RDS for PostgreSQL seperti yang ditunjukkan berikut ini.
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## Mengimpor file Amazon S3 yang dienkode
Contoh berikut menunjukkan cara mengimpor file dari Amazon S3 yang memiliki pengodean Windows-1252.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# Referensi fungsi
**Topics**
+ [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3)
+ [aws\$1commons.create\$1s3\$1uri](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Mengimpor data Amazon S3 ke tabel Amazon RDS. Ekstensi `aws_s3` memberikan fungsi `aws_s3.table_import_from_s3`. Nilai yang ditampilkan berupa teks.
### Sintaksis
Parameter yang diperlukan adalah `table_name`, `column_list`, dan `options`. Parameter ini mengidentifikasi tabel basis data dan menentukan cara data disalin ke dalam tabel.
Anda juga dapat menggunakan parameter berikut:
+ Parameter `s3_info` menentukan file Amazon S3 yang akan diimpor. Saat Anda menggunakan parameter ini, akses ke Amazon S3 disediakan oleh peran IAM untuk instans DB PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ Parameter `credentials` menentukan kredensial untuk mengakses Amazon S3. Saat Anda menggunakan parameter ini, jangan menggunakan peran IAM.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### Parameter
*table\$1name*
String teks yang diperlukan yang berisi nama tabel basis data PostgreSQL sebagai tujuan impor data.
*column\$1list*
String teks yang diperlukan yang berisi daftar opsional kolom tabel basis data PostgreSQL tempat tujuan data akan disalin. Jika string kosong, semua kolom tabel akan digunakan. Sebagai contoh, lihat [Mengimpor file Amazon S3 yang menggunakan pemisah kustom](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
*options*
String teks yang diperlukan yang berisi argumen untuk perintah `COPY` PostgreSQL. Argumen ini menentukan cara data akan disalin ke dalam tabel PostgreSQL. Untuk detail selengkapnya, lihat [Dokumentasi PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html).
*s3\$1info*
Jenis komposit `aws_commons._s3_uri_1` yang berisi informasi tentang objek S3 berikut:
+ `bucket` – Nama bucket Amazon S3 yang berisi file.
+ `file_path` – Nama file Amazon S3 yang mencakup jalur file.
+ `region`— AWS Wilayah tempat file tersebut berada. Untuk daftar nama AWS Wilayah dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
*credentials*
Jenis komposit `aws_commons._aws_credentials_1` yang berisi kredensial berikut yang akan digunakan untuk operasi impor:
+ Kunci akses
+ Kunci rahasia
+ Token sesi
Untuk informasi tentang cara membuat struktur komposit `aws_commons._aws_credentials_1`, lihat [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials).
### Sintaksis alternatif
Untuk memudahkan pengujian, Anda dapat menggunakan serangkaian parameter yang diperluas, bukan parameter `s3_info` dan `credentials`. Berikut ini adalah variasi sintaks tambahan untuk fungsi `aws_s3.table_import_from_s3`:
+ Alih-alih menggunakan parameter `s3_info` untuk mengidentifikasi file Amazon S3, gunakan kombinasi parameter `bucket`, `file_path`, dan `region`. Dengan bentuk fungsi ini, akses ke Amazon S3 disediakan oleh peran IAM pada instans DB PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ Alih-alih menggunakan parameter `credentials` untuk menentukan akses Amazon S3, gunakan kombinasi parameter `access_key`, `session_key`, dan `session_token`.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### Parameter alternatif
*bucket*
String teks yang berisi nama bucket Amazon S3 yang berisi file.
*file\$1path*
String teks yang berisi nama file Amazon S3 beserta jalur file.
*region*
String teks yang mengidentifikasi Wilayah AWS lokasi file. Untuk daftar Wilayah AWS nama dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
*access\$1key*
String teks yang berisi kunci akses untuk digunakan dalam operasi impor. Default-nya adalah NULL.
*secret\$1key*
String teks yang berisi kunci rahasia yang akan digunakan dalam operasi impor. Default-nya adalah NULL.
*session\$1token*
(Opsional) String teks yang berisi kunci sesi yang akan digunakan dalam operasi impor. Default-nya adalah NULL.
## aws\$1commons.create\$1s3\$1uri
Membuat struktur `aws_commons._s3_uri_1` untuk menyimpan informasi file Amazon S3. Gunakan hasil dari fungsi `aws_commons.create_s3_uri` di parameter `s3_info` dari fungsi [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Sintaksis
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### Parameter
*bucket*
String teks yang diperlukan yang berisi nama bucket Amazon S3 untuk file tersebut.
*file\$1path*
String teks yang diperlukan yang berisi nama file Amazon S3 beserta jalurnya.
*region*
String teks yang diperlukan Wilayah AWS yang berisi file tersebut. Untuk daftar Wilayah AWS nama dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1commons.create\$1aws\$1credentials
Mengatur kunci akses dan kunci rahasia dalam struktur `aws_commons._aws_credentials_1`. Gunakan hasil dari fungsi `aws_commons.create_aws_credentials` di parameter `credentials` dari fungsi [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Sintaksis
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### Parameter
*access\$1key*
String teks yang diperlukan berisi kunci akses yang digunakan untuk mengimpor file Amazon S3. Default-nya adalah NULL.
*secret\$1key*
String teks yang diperlukan yang berisi kunci rahasia yang akan digunakan untuk mengimpor file Amazon S3. Default-nya adalah NULL.
*session\$1token*
String teks opsional yang berisi token sesi yang akan digunakan untuk mengimpor file Amazon S3. Default-nya adalah NULL. Jika Anda memberikan `session_token` opsional, Anda dapat menggunakan kredensial sementara.
# Mengangkut basis data PostgreSQL antara instans DB
Dengan menggunakan basis data PostgreSQL yang dapat ditranspor untuk Amazon RDS, Anda dapat memindahkan basis data PostgreSQL antara dua instans DB. Ini adalah cara yang sangat cepat untuk memigrasikan basis data besar antara instans DB yang berbeda. Untuk menggunakan pendekatan ini, instans DB Anda harus menjalankan PostgreSQL versi utama.
Kemampuan ini mengharuskan Anda menginstal ekstensi `pg_transport` di instans DB sumber dan tujuan. Ekstensi `pg_transport` menyediakan mekanisme transportasi fisik yang memindahkan file basis data dengan pemrosesan minimal. Mekanisme ini memindahkan data jauh lebih cepat daripada proses dump dan load tradisional, dengan waktu henti yang lebih sedikit.
**catatan**
Basis data PostgreSQL yang dapat ditranspor tersedia dalam RDS for PostgreSQL 11.5 dan yang lebih tinggi, dan RDS for PostgreSQL versi 10.10 dan yang lebih tinggi.
Untuk mentranspor instans DB PostgreSQL dari satu instans DB RDS for PostgreSQL ke instans DB lainnya, pertama-tama siapkan instans sumber dan tujuan sebagaimana dijelaskan dalam [ Menyiapkan instans DB untuk transportasi](PostgreSQL.TransportableDB.Setup.md). Anda kemudian dapat mentranspor basis data menggunakan fungsi yang dijelaskan dalam [ Mentranspor basis data PostgreSQL](PostgreSQL.TransportableDB.Transporting.md).
**Topics**
+ [Apa yang terjadi selama transportasi basis data](#PostgreSQL.TransportableDB.DuringTransport)
+ [Batasan dalam penggunaan basis data PostgreSQL yang dapat ditranspor](#PostgreSQL.TransportableDB.Limits)
+ [Bersiap untuk mentranspor basis data PostgreSQL](PostgreSQL.TransportableDB.Setup.md)
+ [Mentranspor basis data PostgreSQL ke tujuan dari sumber](PostgreSQL.TransportableDB.Transporting.md)
+ [Referensi fungsi basis data yang dapat ditranspor](PostgreSQL.TransportableDB.transport.import_from_server.md)
+ [Referensi parameter basis data yang dapat ditranspor](PostgreSQL.TransportableDB.Parameters.md)
## Apa yang terjadi selama transportasi basis data
Fitur basis data PostgreSQL yang dapat ditranspor menggunakan model tarik untuk mengimpor basis data dari instans DB sumber ke tujuan. Fungsi `transport.import_from_server` membuat basis data bergerak pada instans DB tujuan. Basis data bergerak tidak dapat diakses pada instans DB tujuan selama durasi transportasi.
Ketika transportasi dimulai, semua sesi saat ini pada basis data sumber berakhir. Setiap basis data selain basis data sumber pada instans DB sumber tidak terpengaruh oleh transportasi.
Basis data sumber dibuat menjadi mode hanya-baca khusus. Saat berada dalam mode ini, Anda dapat terhubung ke basis data sumber dan menjalankan kueri hanya baca. Namun, kueri berkemampuan tulis dan beberapa jenis perintah lainnya diblokir. Hanya basis data sumber spesifik yang ditranspor yang terpengaruh oleh pembatasan ini.
Selama transportasi, Anda tidak dapat memulihkan instans DB tujuan ke suatu titik waktu. Ini karena transportasi tersebut tidak bersifat transaksional dan tidak menggunakan log write-ahead PostgreSQL untuk mencatat perubahan. Jika instans DB tujuan mengaktifkan pencadangan otomatis, cadangan akan diambil secara otomatis setelah transportasi selesai. Point-in-timepemulihan tersedia beberapa kali *setelah* pencadangan selesai.
Jika transportasi gagal, ekstensi `pg_transport` berupaya untuk membatalkan semua perubahan ke instans DB sumber dan tujuan. Ini termasuk menghapus basis data yang ditranspor sebagian di tujuan. Bergantung pada jenis kegagalan, basis data sumber dapat terus menolak kueri berkemampuan tulis. Jika ini terjadi, gunakan perintah berikut untuk memungkinkan kueri berkemampuan tulis.
```
ALTER DATABASE db-name SET default_transaction_read_only = false;
```
## Batasan dalam penggunaan basis data PostgreSQL yang dapat ditranspor
Basis data yang dapat ditranspor memiliki batasan berikut:
+ **Replika baca** – Anda tidak dapat menggunakan basis data yang dapat ditranspor pada replika baca atau instans induk replika baca.
+ **Jenis kolom yang tidak didukung** – Anda tidak dapat menggunakan jenis data `reg` dalam tabel basis data apa pun yang akan Anda transportasikan dengan metode ini. Jenis ini tergantung pada sistem katalog objek IDs (OIDs), yang sering berubah selama transportasi.
+ **Tablespace** – Semua objek basis data sumber harus dalam tablespace `pg_default` default.
+ **Kompatibilitas** – Instans DB sumber dan tujuan harus menjalankan PostgreSQL dalam versi utama yang sama.
+ **Ekstensi** — Instans DB sumber hanya dapat memiliki penginstalan `pg_transport`.
+ **Peran dan ACLs** — Hak akses database sumber dan informasi kepemilikan tidak dibawa ke database tujuan. Semua objek basis data dibuat dan dimiliki oleh pengguna tujuan transportasi lokal.
+ **Transportasi bersamaan** — Instans DB tunggal dapat mendukung hingga 32 transportasi bersamaan, termasuk impor dan ekspor, jika proses pekerja telah dikonfigurasi dengan benar.
+ **Khusus instans DB RDS for PostgreSQL** - Basis data PostgreSQL yang dapat ditranspor didukung hanya pada instans DB RDS for PostgreSQL. Anda tidak dapat menggunakannya dengan basis data on-premise atau basis data yang berjalan di Amazon EC2.
# Bersiap untuk mentranspor basis data PostgreSQL
Sebelum memulai, pastikan bahwa instans DB RDS for PostgreSQL Anda memenuhi persyaratan berikut:
+ Instans DB RDS for PostgreSQL untuk sumber dan tujuan harus menjalankan versi PostgreSQL yang sama.
+ DB tujuan tidak dapat memiliki basis data dengan nama yang sama dengan DB sumber yang ingin Anda transportasikan.
+ Akun yang Anda gunakan untuk menjalankan transportasi membutuhkan hak istimewa `rds_superuser` pada DB sumber dan DB tujuan.
+ Grup keamanan untuk instans DB sumber harus mengizinkan akses masuk dari instans DB tujuan. Izin ini mungkin sudah ada jika instans DB sumber dan tujuan Anda berada di VPC. Untuk mengetahui informasi selengkapnya tentang grup keamanan, lihat [Mengontrol akses dengan grup keamanan](Overview.RDSSecurityGroups.md).
Mentranspor basis data dari instans DB sumber ke instans DB tujuan memerlukan beberapa perubahan pada grup parameter DB yang terkait dengan setiap instans. Artinya Anda harus membuat grup parameter DB kustom untuk instans DB sumber dan membuat grup parameter DB kustom untuk instans DB tujuan.
**catatan**
Jika instans DB Anda sudah dikonfigurasi menggunakan grup parameter DB kustom, Anda dapat memulai dengan langkah 2 dalam prosedur berikut.
**Cara mengonfigurasi parameter grup DB kustom untuk mentranspor basis data**
Untuk langkah-langkah berikut, gunakan akun yang memiliki hak istimewa `rds_superuser`.
1. Jika instans DB sumber dan tujuan menggunakan grup parameter DB default, Anda perlu membuat grup parameter DB khusus menggunakan versi yang sesuai untuk instance Anda. Ini dilakukan agar Anda dapat mengubah nilai untuk beberapa parameter. Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
1. Dalam grup parameter DB kustom, ubah nilai untuk parameter berikut:
+ `shared_preload_libraries`— Tambahkan `pg_transport` ke daftar pustaka.
+ `pg_transport.num_workers` – Nilai default-nya adalah 3. Tingkatkan atau kurangi nilai ini sesuai kebutuhan untuk basis data Anda. Untuk basis data 200 GB, kami sarankan tidak lebih dari 8. Perlu diingat bahwa jika Anda meningkatkan nilai default untuk parameter ini, Anda juga harus meningkatkan nilai `max_worker_processes`.
+ `pg_transport.work_mem` – Nilai default-nya adalah 128 MB atau 256 MB, tergantung versi PostgreSQL. Pengaturan default biasanya dapat dibiarkan saja.
+ `max_worker_processes` – Nilai parameter ini perlu diatur menggunakan perhitungan berikut:
```
(3 * pg_transport.num_workers) + 9
```
Nilai ini diperlukan di tujuan untuk menangani berbagai proses pekerja latar belakang yang terlibat dalam transportasi. Untuk mempelajari lebih lanjut tentang `max_worker_processes,`, lihat [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) dalam dokumentasi PostgreSQL.
Untuk informasi selengkapnya tentang parameter `pg_transport`, lihat [Referensi parameter basis data yang dapat ditranspor](PostgreSQL.TransportableDB.Parameters.md).
1. Boot ulang instans DB RDS for PostgreSQL sumber dan instans tujuan agar pengaturan untuk parameter tersebut berlaku.
1. Terhubung ke instans DB RDS for PostgreSQL sumber Anda.
```
psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Hapus ekstensi asing dari skema publik instans DB. Hanya ekstensi `pg_transport` yang diizinkan selama operasi transportasi aktual.
1. Instal ekstensi `pg_transport` sebagai berikut:
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
1. Terhubung ke instans DB RDS for PostgreSQL tujuan Anda. Hapus ekstensi asing apa pun, lalu instal ekstensi `pg_transport`.
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
# Mentranspor basis data PostgreSQL ke tujuan dari sumber
Setelah Anda menyelesaikan proses yang dijelaskan dalam [Bersiap untuk mentranspor basis data PostgreSQL](PostgreSQL.TransportableDB.Setup.md), Anda dapat memulai transportasi. Untuk melakukannya, jalankan fungsi `transport.import_from_server` pada instans DB tujuan. Dalam sintaks berikut ini Anda dapat menemukan parameter fungsi.
```
SELECT transport.import_from_server(
'source-db-instance-endpoint',
source-db-instance-port,
'source-db-instance-user',
'source-user-password',
'source-database-name',
'destination-user-password',
false);
```
Nilai `false` yang ditunjukkan dalam contoh memberi tahu fungsi bahwa ini bukan dry run. Untuk menguji penyiapan transportasi, Anda dapat menentukan `true` untuk opsi `dry_run` saat memanggil fungsi, seperti yang ditunjukkan berikut ini:
```
postgres=> SELECT transport.import_from_server(
'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
'postgres', '********', 'labdb', '******', true);
INFO: Starting dry-run of import of database "labdb".
INFO: Created connections to remote database (took 0.03 seconds).
INFO: Checked remote cluster compatibility (took 0.05 seconds).
INFO: Dry-run complete (took 0.08 seconds total).
import_from_server
--------------------
(1 row)
```
Baris INFO adalah output karena parameter `pg_transport.timing` diatur ke nilai default-nya, `true`. Atur `dry_run` ke `false` ketika Anda menjalankan perintah dan basis data sumber diimpor ke tujuan, seperti yang ditunjukkan berikut:
```
INFO: Starting import of database "labdb".
INFO: Created connections to remote database (took 0.02 seconds).
INFO: Marked remote database as read only (took 0.13 seconds).
INFO: Checked remote cluster compatibility (took 0.03 seconds).
INFO: Signaled creation of PITR blackout window (took 2.01 seconds).
INFO: Applied remote database schema pre-data (took 0.50 seconds).
INFO: Created connections to local cluster (took 0.01 seconds).
INFO: Locked down destination database (took 0.00 seconds).
INFO: Completed transfer of database files (took 0.24 seconds).
INFO: Completed clean up (took 1.02 seconds).
INFO: Physical transport complete (took 3.97 seconds total).
import_from_server
--------------------
(1 row)
```
Fungsi ini mengharuskan Anda memberikan kata sandi pengguna basis data. Oleh karena itu, kami menyarankan Anda untuk mengubah kata sandi dari peran pengguna yang Anda gunakan setelah transportasi selesai. Atau, Anda dapat menggunakan variabel terikat SQL untuk membuat peran pengguna sementara. Gunakan peran sementara ini untuk transportasi, lalu buang peran tersebut setelahnya.
Jika transportasi Anda tidak berhasil, Anda mungkin melihat pesan kesalahan yang mirip dengan yang berikut ini:
```
pg_transport.num_workers=8 25% of files transported failed to download file data
```
Pesan kesalahan "gagal mengunduh data file" menunjukkan bahwa jumlah proses pekerja tidak diatur dengan benar untuk ukuran basis data. Anda mungkin perlu meningkatkan atau mengurangi nilai yang diatur untuk `pg_transport.num_workers`. Setiap kegagalan melaporkan persentase penyelesaian, sehingga Anda dapat melihat dampak perubahan Anda. Misalnya, mengubah pengaturan dari 8 menjadi 4 dalam satu kasus menghasilkan hal berikut:
```
pg_transport.num_workers=4 75% of files transported failed to download file data
```
Perlu diingat bahwa parameter `max_worker_processes` juga diperhitungkan selama proses transportasi. Dengan kata lain, Anda mungkin perlu memodifikasi `pg_transport.num_workers` dan `max_worker_processes` agar transportasi basis data berhasil dijalankan. Contoh yang ditampilkan akhirnya berfungsi ketika `pg_transport.num_workers` diatur ke 2:
```
pg_transport.num_workers=2 100% of files transported
```
Lihat informasi selengkapnya tentang fungsi `transport.import_from_server` dan parameternya di [Referensi fungsi basis data yang dapat ditranspor](PostgreSQL.TransportableDB.transport.import_from_server.md).
# Referensi fungsi basis data yang dapat ditranspor
`transport.import_from_server`Fungsi ini mengangkut SQL database Postgre dengan mengimpornya dari instance DB sumber ke instance DB tujuan. Hal ini dilakukan menggunakan mekanisme transportasi koneksi basis data fisik.
Sebelum memulai transportasi, fungsi ini memverifikasi bahwa instans DB sumber dan tujuan merupakan versi yang sama dan kompatibel untuk migrasi. Hal ini juga menegaskan bahwa instans DB tujuan memiliki cukup ruang untuk sumbernya.
**Sintaks**
```
transport.import_from_server(
host text,
port int,
username text,
password text,
database text,
local_password text,
dry_run bool
)
```
**Nilai yang Ditampilkan**
Tidak ada.
**Parameter**
Anda dapat menemukan deskripsi parameter fungsi `transport.import_from_server` dalam tabel berikut.
****
| Parameter | Deskripsi |
| --- | --- |
| host | Titik akhir instans DB sumber. |
| port | Integer yang mewakili port instans DB sumber. Instans Postgre SQL DB sering menggunakan port 5432. |
| username | Pengguna instans DB sumber. Pengguna ini harus menjadi anggota peran `rds_superuser`. |
| password | Kata sandi pengguna instans DB sumber. |
| database | Nama basis data dalam instans DB sumber untuk ditranspor. |
| local\$1password | Kata sandi lokal pengguna saat ini untuk instans DB tujuan. Pengguna ini harus menjadi anggota peran `rds_superuser`. |
| dry\$1run | Nilai Boolean opsional yang menetapkan apakah dry run akan dijalankan. Default-nya adalah `false`, yang artinya transportasi berlanjut.Untuk mengonfirmasi kompatibilitas antara instans DB sumber dan tujuan tanpa benar-benar melakukan transportasi, atur dry\$1run ke true. |
**Contoh**
Sebagai contoh, lihat [Mentranspor basis data PostgreSQL ke tujuan dari sumber](PostgreSQL.TransportableDB.Transporting.md).
# Referensi parameter basis data yang dapat ditranspor
Beberapa parameter mengontrol perilaku ekstensi `pg_transport`. Selanjutnya, Anda dapat menemukan deskripsi parameter ini.
**`pg_transport.num_workers`**
Jumlah pekerja yang akan digunakan dalam proses transportasi. Default-nya adalah 3. Nilai yang valid adalah 1–32. Bahkan transportasi basis data terbesar biasanya membutuhkan kurang dari 8 pekerja. Nilai pengaturan ini pada instans DB tujuan digunakan oleh tujuan dan sumber selama transportasi.
**`pg_transport.timing` **
Menentukan apakah akan melaporkan informasi waktu selama transportasi. Default-nya adalah `true`, artinya informasi waktu dilaporkan. Kami menyarankan agar Anda membiarkan parameter ini diatur ke `true` agar Anda dapat memantau progresnya. Untuk contoh hasilnya, lihat [Mentranspor basis data PostgreSQL ke tujuan dari sumber](PostgreSQL.TransportableDB.Transporting.md).
**`pg_transport.work_mem`**
Jumlah maksimum memori untuk dialokasikan kepada setiap pekerja. Default-nya adalah 131072 kilobyte (KB) atau 262144 KB (256 MB), tergantung versi PostgreSQL. Nilai minimumnya adalah 64 megabyte (65536 KB). Nilai yang valid dalam kilobyte (KBs) sebagai unit basis-2 biner, di mana 1 KB = 1024 byte.
Transportasi mungkin menggunakan lebih sedikit memori dari yang ditentukan dalam parameter ini. Bahkan transportasi basis data besar biasanya membutuhkan kurang dari 256 MB (262144 KB) memori per pekerja.
# Mengekspor data dari instans DB RDS for PostgreSQL ke Amazon S3
Anda dapat mengueri data dari instans DB RDS for PostgreSQL dan mengekspornya langsung ke file yang disimpan dalam bucket Amazon S3. Untuk melakukannya, instal ekstensi RDS for PostgreSQL `aws_s3` terlebih dahulu. Ekstensi ini memberi Anda fungsi yang Anda gunakan untuk mengekspor hasil kueri ke Amazon S3. Berikut ini, Anda dapat mengetahui cara menginstal ekstensi dan cara mengekspor data ke Amazon S3.
**catatan**
Ekspor lintas akun ke Amazon S3 tidak didukung.
Semua versi RDS for PostgreSQL yang tersedia saat ini mendukung ekspor data ke Amazon Simple Storage Service. Untuk informasi versi terperinci, lihat [Pembaruan Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) dalam *Catatan Rilis Amazon RDS for PostgreSQL*.
Jika Anda belum menyiapkan bucket untuk ekspor, lihat topik berikut, *Panduan Pengguna Amazon Simple Storage Service*.
+ [Menyiapkan Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html)
+ [Membuat bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
Secara default, data yang diekspor dari RDS untuk PostgreSQL ke Amazon S3 menggunakan enkripsi sisi server dengan file. Kunci yang dikelola AWS Jika Anda menggunakan enkripsi bucket, bucket Amazon S3 harus dienkripsi dengan kunci AWS Key Management Service (AWS KMS) (SSE-KMS). Saat ini, bucket yang dienkripsi dengan kunci terkelola Amazon S3 (SSE-S3) tidak didukung.
**catatan**
Anda dapat menyimpan data snapshot DB ke Amazon S3 menggunakan Konsol Manajemen AWS AWS CLI,, atau Amazon RDS API. Untuk informasi selengkapnya, lihat [Mengekspor data snapshot DB ke Amazon S3 untuk Amazon RDS](USER_ExportSnapshot.md).
**Topics**
+ [Menginstal ekstensi aws\$1s3](#USER_PostgreSQL.S3Export.InstallExtension)
+ [Ikhtisar ekspor data ke Amazon S3](#postgresql-s3-export-overview)
+ [Menentukan jalur file Amazon S3 tujuan ekspor](#postgresql-s3-export-file)
+ [Menyiapkan akses ke bucket Amazon S3](postgresql-s3-export-access-bucket.md)
+ [Mengekspor data kueri menggunakan fungsi aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md)
+ [Referensi fungsi](postgresql-s3-export-functions.md)
+ [Memecahkan masalah akses ke Amazon S3](postgresql-s3-export-troubleshoot.md)
## Menginstal ekstensi aws\$1s3
Sebelum Anda dapat menggunakan Amazon Simple Storage Service dengan instans DB RDS for PostgreSQL, Anda perlu menginstal ekstensi `aws_s3`. Ekstensi ini memberikan fungsi untuk mengekspor data dari instans DB RDS for PostgreSQL ke bucket Amazon S3. Ini juga menyediakan fungsi untuk mengimpor data dari Amazon S3. Untuk informasi selengkapnya, lihat [Mengimpor data dari Amazon S3 ke instans DB RDS for PostgreSQL](USER_PostgreSQL.S3Import.md). Ekstensi `aws_s3` bergantung pada beberapa fungsi pembantu dalam ekstensi `aws_commons`, yang diinstal secara otomatis bila diperlukan.
**Untuk menginstal ekstensi `aws_s3`**
1. Gunakan psql (atau pgAdmin) untuk terhubung ke instans DB RDS for PostgreSQL sebagai pengguna yang memiliki hak istimewa `rds_superuser`. Jika Anda menyimpan nama default selama proses penyiapan, Anda terhubung sebagai `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Untuk menginstal ekstensi, jalankan perintah berikut.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Untuk memverifikasi bahwa ekstensi sudah diinstal, Anda dapat menggunakan metacommand psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Fungsi untuk mengimpor data dari Amazon S3 dan mengekspor data ke Amazon S3 kini dapat digunakan.
### Verifikasi bahwa RDS Anda untuk PostgreSQL Aurora PostgreSQL ke Amazon S3
Anda dapat memverifikasi bahwa versi RDS for PostgreSQL mendukung ekspor ke Amazon S3 dengan menggunakan perintah `describe-db-engine-versions`. Contoh berikut memverifikasi dukungan untuk versi 10.14.
```
aws rds describe-db-engine-versions --region us-east-1
--engine postgres --engine-version 10.14 | grep s3Export
```
Jika output-nya menyertakan string `"s3Export"`, berarti mesinnya mendukung ekspor Amazon S3. Jika tidak, mesin tidak mendukungnya.
## Ikhtisar ekspor data ke Amazon S3
Untuk mengekspor data yang disimpan dalam basis data RDS for PostgreSQL ke bucket Amazon S3, gunakan prosedur berikut.
**Untuk mengekspor data RDS for PostgreSQL ke S3**
1. Identifikasi jalur file Amazon S3 yang akan digunakan untuk mengekspor data. Untuk detail tentang proses ini, lihat [Menentukan jalur file Amazon S3 tujuan ekspor](#postgresql-s3-export-file).
1. Berikan izin untuk mengakses bucket Amazon S3.
Untuk mengekspor data ke file Amazon S3, beri instans DB RDS for PostgreSQL izin untuk mengakses bucket Amazon S3 yang akan digunakan untuk penyimpanan data yang diekspor. Berikut adalah langkah-langkahnya:
1. Buat kebijakan IAM yang memberikan akses ke bucket Amazon S3 tempat tujuan ekspor.
1. Buat peran IAM.
1. Lampirkan kebijakan yang Anda buat ke peran yang Anda buat.
1. Tambahkan peran IAM ini ke instans DB.
Untuk detail tentang proses ini, lihat [Menyiapkan akses ke bucket Amazon S3](postgresql-s3-export-access-bucket.md).
1. Identifikasi kueri basis data untuk mendapatkan data. Ekspor data kueri dengan memanggil fungsi `aws_s3.query_export_to_s3`.
Setelah menyelesaikan tugas persiapan sebelumnya, gunakan fungsi [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) untuk mengekspor hasil kueri ke Amazon S3. Untuk detail tentang proses ini, lihat [Mengekspor data kueri menggunakan fungsi aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
## Menentukan jalur file Amazon S3 tujuan ekspor
Tentukan informasi berikut untuk mengidentifikasi lokasi di Amazon S3 tempat Anda ingin mengekspor data:
+ Nama bucket – *Bucket* adalah kontainer untuk objek atau file Amazon S3.
Untuk informasi selengkapnya tentang menyimpan data dengan Amazon S3, lihat [Membuat bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dan [Bekerja dengan objek](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
+ Jalur file – Jalur file mengidentifikasi tempat penyimpanan data yang diekspor dalam bucket Amazon S3. Jalur file terdiri atas:
+ Awalan jalur opsional yang mengidentifikasi jalur folder virtual.
+ Awalan file yang mengidentifikasi satu atau beberapa file yang akan disimpan. Ekspor yang lebih besar disimpan dalam beberapa file, masing-masing berukuran maksimum sekitar 6 GB. Nama file tambahan memiliki awalan file yang sama, tetapi dengan penambahan `_partXX`. `XX` mewakili 2, lalu 3, dan seterusnya.
Misalnya, jalur file dengan folder `exports` dan awalan file `query-1-export` adalah `/exports/query-1-export`.
+ AWS Wilayah (opsional) - AWS Wilayah tempat bucket Amazon S3 berada.
**catatan**
Saat ini, AWS Wilayah harus sama dengan wilayah instans yang mengekspor.
Untuk daftar nama AWS Wilayah dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
Untuk menyimpan informasi file Amazon S3 tentang lokasi penyimpanan file yang diekspor, Anda dapat menggunakan fungsi [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) untuk membuat struktur komposit `aws_commons._s3_uri_1` sebagai berikut.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Kemudian, berikan nilai `s3_uri_1` ini sebagai parameter untuk memanggil fungsi [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Sebagai contoh, lihat [Mengekspor data kueri menggunakan fungsi aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
# Menyiapkan akses ke bucket Amazon S3
Untuk mengekspor data ke Amazon S3, berikan izin kepada instans DB PostgreSQL Anda untuk mengakses bucket Amazon S3 yang akan dimasuki file.
Untuk melakukannya, gunakan prosedur berikut.
**Untuk memberi instans DB PostgreSQL akses ke Amazon S3 melalui peran IAM**
1. Buat kebijakan IAM.
Kebijakan ini memberikan izin kepada bucket dan objek yang memungkinkan instans DB PostgreSQL Anda mengakses Amazon S3.
Sebagai bagian dari pembuatan kebijakan ini, lakukan langkah-langkah berikut:
1. Sertakan tindakan yang diperlukan berikut dalam kebijakan untuk mengizinkan transfer file dari instans DB PostgreSQL ke bucket Amazon S3:
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Sertakan Amazon Resource Name (ARN) yang mengidentifikasi bucket dan objek Amazon S3 dalam bucket. Format ARN untuk mengakses Amazon S3 adalah: `arn:aws:s3:::amzn-s3-demo-bucket/*`
Untuk informasi selengkapnya tentang cara membuat kebijakan IAM untuk Amazon RDS for PostgreSQL, lihat [Membuat dan menggunakan kebijakan IAM untuk akses basis data IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Lihat juga [Tutorial: Membuat dan melampirkan kebijakan yang dikelola pelanggan pertama Anda](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) di *Panduan Pengguna IAM*.
AWS CLI Perintah berikut membuat kebijakan IAM bernama `rds-s3-export-policy` dengan opsi ini. Ini memberikan akses ke bucket bernama *amzn-s3-demo-bucket*.
**Awas**
Sebaiknya Anda menyiapkan basis data Anda dengan VPC privat yang memiliki kebijakan titik akhir yang dikonfigurasi untuk mengakses bucket tertentu. Untuk informasi selengkapnya, lihat [ Menggunakan kebijakan titik akhir untuk Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3) di Panduan Pengguna Amazon VPC.
Kami sangat menyarankan Anda agar tidak membuat kebijakan dengan akses semua sumber daya. Akses ini dapat menjadi ancaman bagi data keamanan. Jika Anda membuat kebijakan yang memberi akses `S3:PutObject` ke semua sumber daya menggunakan `"Resource":"*"`, pengguna yang memiliki hak istimewa ekspor dapat mengekspor data ke semua bucket di akun Anda. Selain itu, pengguna dapat mengekspor data ke *bucket yang dapat ditulis secara publik Wilayah AWS Anda*.
Setelah Anda membuat kebijakan, catat Amazon Resource Name (ARN) dari kebijakan tersebut. Anda memerlukan ARN ini untuk langkah berikutnya ketika Anda melampirkan kebijakan ke peran IAM.
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Buat peran IAM.
Lakukan langkah ini agar Amazon RDS dapat mengambil peran IAM ini atas nama Anda untuk mengakses bucket Amazon S3. Untuk informasi selengkapnya, lihat [Membuat peran untuk mendelegasikan izin ke pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dalam *Panduan Pengguna IAM*.
Sebaiknya gunakan kunci konteks kondisi global `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` dan `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` dalam kebijakan berbasis sumber daya untuk membatasi izin layanan ke sumber daya tertentu. Ini adalah cara paling efektif untuk melindungi dari [masalah deputi yang membingungkan](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Jika Anda menggunakan kunci konteks kondisi global dan nilai `aws:SourceArn` berisi ID akun, nilai `aws:SourceAccount` dan akun dalam nilai `aws:SourceArn` harus menggunakan ID akun yang sama saat digunakan dalam pernyataan kebijakan yang sama.
+ Gunakan `aws:SourceArn` jika Anda menginginkan akses lintas layanan untuk satu sumber daya.
+ Gunakan `aws:SourceAccount` jika Anda ingin mengizinkan sumber daya apa pun di akun tersebut dikaitkan dengan penggunaan lintas layanan.
Dalam kebijakan, pastikan untuk menggunakan kunci konteks kondisi global `aws:SourceArn` dengan ARN penuh sumber daya. Contoh berikut menunjukkan bagaimana melakukannya dengan menggunakan AWS CLI perintah untuk membuat peran bernama`rds-s3-export-role`.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Untuk Windows:
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Lampirkan kebijakan IAM yang Anda buat ke peran IAM yang Anda buat.
AWS CLI Perintah berikut melampirkan kebijakan yang dibuat sebelumnya ke peran bernama `rds-s3-export-role.` Ganti `your-policy-arn` dengan ARN kebijakan yang Anda catat di langkah sebelumnya.
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. Tambahkan peran IAM ke instans DB. Anda melakukannya dengan menggunakan Konsol Manajemen AWS atau AWS CLI, seperti yang dijelaskan berikut.
## Konsol
**Untuk menambahkan peran IAM untuk instans DB PostgreSQL menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih nama instans DB PostgreSQL untuk menampilkan detailnya.
1. Di tab **Konektivitas & keamanan**, di bagian **Kelola peran IAM**, pilih peran yang akan ditambahkan pada bagian **Tambahkan peran IAM ke instans ini**.
1. Di bagian **Fitur**, pilih **s3Export**.
1. Pilih **Tambahkan peran**.
## AWS CLI
**Untuk menambahkan peran IAM untuk instans DB PostgreSQL menggunakan CLI**
+ Gunakan perintah berikut untuk menambahkan peran ke instans DB PostgreSQL bernama `my-db-instance`. Ganti *`your-role-arn`* dengan ARN peran yang Anda catat pada langkah sebelumnya. Gunakan `s3Export` untuk nilai opsi `--feature-name`.
**Example**
Untuk Linux, macOS, atau Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
Untuk Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# Mengekspor data kueri menggunakan fungsi aws\$1s3.query\$1export\$1to\$1s3
Ekspor data PostgreSQL Anda ke Amazon S3 dengan memanggil fungsi [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
**Topics**
+ [Prasyarat](#postgresql-s3-export-examples-prerequisites)
+ [Memanggil aws\$1s3.query\$1export\$1to\$1s3](#postgresql-s3-export-examples-basic)
+ [Mengekspor ke file CSV yang menggunakan pembatas kustom](#postgresql-s3-export-examples-custom-delimiter)
+ [Mengekspor ke file biner dengan pengodean](#postgresql-s3-export-examples-encoded)
## Prasyarat
Sebelum menggunakan fungsi `aws_s3.query_export_to_s3`, pastikan untuk melengkapi prasyarat berikut:
+ Instal ekstensi PostgreSQL yang diperlukan seperti yang dijelaskan di [Ikhtisar ekspor data ke Amazon S3](postgresql-s3-export.md#postgresql-s3-export-overview).
+ Tentukan tempat untuk mengekspor data Anda ke Amazon S3 seperti yang dijelaskan di [Menentukan jalur file Amazon S3 tujuan ekspor](postgresql-s3-export.md#postgresql-s3-export-file).
+ Pastikan bahwa instans DB memiliki akses ekspor ke Amazon S3 seperti yang dijelaskan di [Menyiapkan akses ke bucket Amazon S3](postgresql-s3-export-access-bucket.md).
Contoh berikut menggunakan tabel basis data yang disebut `sample_table`. Contoh ini mengekspor data ke dalam bucket bernama *amzn-s3-demo-bucket*. Contoh tabel dan data dibuat dengan pernyataan SQL berikut di psql.
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## Memanggil aws\$1s3.query\$1export\$1to\$1s3
Berikut ini adalah cara-cara dasar untuk memanggil fungsi [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
Contoh ini menggunakan variabel `s3_uri_1` untuk mengidentifikasi struktur berisi informasi yang mengidentifikasi file Amazon S3. Gunakan fungsi [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) untuk membuat struktur.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Meskipun parameter bervariasi untuk dua panggilan fungsi `aws_s3.query_export_to_s3` berikut, hasilnya sama untuk contoh ini. Semua baris dari tabel `sample_table` diekspor ke dalam bucket yang disebut *amzn-s3-demo-bucket*.
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
Parameternya dijelaskan sebagai berikut:
+ `'SELECT * FROM sample_table'` – Parameter pertama adalah string teks wajib yang berisi kueri SQL. Mesin PostgreSQL menjalankan kueri ini. Hasil kueri disalin ke bucket S3 yang diidentifikasi dalam parameter lain.
+ `:'s3_uri_1'` – Parameter ini adalah struktur yang mengidentifikasi file Amazon S3. Contoh ini menggunakan variabel untuk mengidentifikasi struktur yang dibuat sebelumnya. Anda dapat membuat struktur dengan menyertakan baris panggilan fungsi `aws_commons.create_s3_uri` sebaris dalam panggilan fungsi `aws_s3.query_export_to_s3` sebagai berikut.
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'` – Parameter `options` adalah string teks opsional yang berisi argumen `COPY` PostgreSQL. Proses penyalinan menggunakan argumen dan format perintah [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html).
Jika file yang ditentukan tidak ada dalam bucket Amazon S3, file tersebut akan dibuat. Jika file sudah ada, file tersebut akan ditimpa. Sintaks untuk mengakses data yang diekspor di Amazon S3 adalah sebagai berikut.
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
Ekspor yang lebih besar disimpan dalam beberapa file, masing-masing berukuran maksimum sekitar 6 GB. Nama file tambahan memiliki awalan file yang sama, tetapi dengan penambahan `_partXX`. `XX` mewakili 2, lalu 3, dan seterusnya. Sebagai contoh, misalkan Anda menentukan jalur tempat Anda menyimpan file data sebagai berikut.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
Jika ekspor harus membuat tiga file data, bucket Amazon S3 berisi file data berikut.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
Untuk referensi selengkapnya tentang fungsi ini dan cara lain untuk memanggilnya, lihat [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Untuk informasi selengkapnya tentang cara mengakses file di Amazon S3, buka [Melihat objek](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) dalam *Panduan Pengguna Amazon Simple Storage Service*.
## Mengekspor ke file CSV yang menggunakan pembatas kustom
Contoh berikut menunjukkan cara memanggil fungsi [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) untuk mengekspor data ke file yang menggunakan pembatas kustom. Contoh ini menggunakan argumen perintah [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) untuk menetapkan format nilai yang dipisahkan koma (CSV) dan pembatas titik dua (:).
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## Mengekspor ke file biner dengan pengodean
Contoh berikut menunjukkan cara memanggil fungsi [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) untuk mengekspor data ke file biner yang memiliki pengodean Windows-1253.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# Referensi fungsi
**Topics**
+ [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3)
+ [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
Mengekspor hasil kueri PostgreSQL ke bucket Amazon S3. Ekstensi `aws_s3` memberikan fungsi `aws_s3.query_export_to_s3`.
Dua parameter yang dibutuhkan adalah `query` dan `s3_info`. Parameter ini menentukan kueri yang akan diekspor dan mengidentifikasi bucket Amazon S3 tempat tujuan ekspor. Parameter opsional yang disebut `options` disediakan untuk menentukan berbagai parameter ekspor. Sebagai contoh penggunaan fungsi `aws_s3.query_export_to_s3`, lihat [Mengekspor data kueri menggunakan fungsi aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
**Sintaksis**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```Parameter input
*query*
String teks yang diperlukan yang berisi kueri SQL yang dijalankan mesin PostgreSQL. Hasil kueri ini disalin ke bucket S3 yang diidentifikasi dalam parameter `s3_info`.
*s3\$1info*
Jenis komposit `aws_commons._s3_uri_1` yang berisi informasi tentang objek S3 berikut:
+ `bucket` – Nama bucket Amazon S3 yang akan diisi file.
+ `file_path` – Nama dan jalur file Amazon S3.
+ `region`— AWS Wilayah tempat ember berada. Untuk daftar nama AWS Wilayah dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
Saat ini, nilai ini harus AWS Wilayah yang sama dengan instans yang mengekspor. Defaultnya adalah AWS Wilayah instance yang mengekspor.
Untuk membuat struktur komposit `aws_commons._s3_uri_1`, lihat fungsi [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri).
*options*
String teks opsional yang berisi argumen untuk perintah `COPY` PostgreSQL. Argumen ini menentukan cara menyalin data saat diekspor. Untuk detail selengkapnya, lihat [Dokumentasi PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html).
*teks kms\$1key*
String teks opsional yang berisi kunci KMS yang dikelola pelanggan dari bucket S3 untuk mengekspor data.
### Parameter input alternatif
Untuk memudahkan pengujian, Anda dapat menggunakan serangkaian parameter yang diperluas, bukan parameter `s3_info`. Berikut ini adalah variasi sintaks tambahan untuk fungsi `aws_s3.query_export_to_s3`.
Alih-alih menggunakan parameter `s3_info` untuk mengidentifikasi file Amazon S3, gunakan kombinasi parameter `bucket`, `file_path`, dan `region`.
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*
String teks yang diperlukan yang berisi kueri SQL yang dijalankan mesin PostgreSQL. Hasil kueri ini disalin ke bucket S3 yang diidentifikasi dalam parameter `s3_info`.
*bucket*
String teks yang diperlukan yang berisi nama bucket Amazon S3 yang berisi file.
*file\$1path*
String teks yang diperlukan yang berisi nama file Amazon S3 beserta jalurnya.
*region*
String teks opsional yang berisi AWS Wilayah tempat bucket berada. Untuk daftar nama AWS Wilayah dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
Saat ini, nilai ini harus AWS Wilayah yang sama dengan instans yang mengekspor. Defaultnya adalah AWS Wilayah instance yang mengekspor.
*options*
String teks opsional yang berisi argumen untuk perintah `COPY` PostgreSQL. Argumen ini menentukan cara menyalin data saat diekspor. Untuk detail selengkapnya, lihat [Dokumentasi PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html).
*teks kms\$1key*
String teks opsional yang berisi kunci KMS yang dikelola pelanggan dari bucket S3 untuk mengekspor data.
### Parameter output
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
Jumlah baris tabel yang berhasil diunggah ke Amazon S3 untuk kueri tertentu.
*files\$1uploaded*
Jumlah file yang diunggah ke Amazon S3. File dibuat dalam ukuran kira-kira 6 GB. Setiap file tambahan yang dibuat memiliki `_partXX` yang ditambahkan pada namanya. `XX` mewakili 2, kemudian 3, dan seterusnya sesuai kebutuhan.
*bytes\$1uploaded*
Jumlah total byte yang diunggah ke Amazon S3.
### Contoh
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Membuat struktur `aws_commons._s3_uri_1` untuk menyimpan informasi file Amazon S3. Gunakan hasil dari fungsi `aws_commons.create_s3_uri` dalam parameter `s3_info` dari fungsi [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3). Untuk contoh penggunaan fungsi `aws_commons.create_s3_uri`, lihat [Menentukan jalur file Amazon S3 tujuan ekspor](postgresql-s3-export.md#postgresql-s3-export-file).
**Sintaksis**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```Parameter input
*bucket*
String teks yang diperlukan yang berisi nama bucket Amazon S3 untuk file tersebut.
*file\$1path*
String teks yang diperlukan yang berisi nama file Amazon S3 beserta jalurnya.
*region*
String teks yang diperlukan yang berisi AWS Wilayah tempat file tersebut berada. Untuk daftar nama AWS Wilayah dan nilai terkait, lihat[Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
# Memecahkan masalah akses ke Amazon S3
Jika Anda mengalami masalah koneksi saat mencoba mengekspor data ke Amazon S3, pertama pastikan aturan akses keluar untuk grup keamanan VPC yang terkait dengan instans DB Anda mengizinkan konektivitas jaringan. Secara khusus, grup keamanan harus memiliki aturan yang memungkinkan instans DB mengirim lalu lintas TCP ke port 443 dan ke IPv4 alamat apa pun (0.0.0.0/0). Untuk informasi selengkapnya, lihat [Memberikan akses ke instans DB di VPC Anda dengan membuat grup keamanan](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Lihat juga rekomendasi berikut:
+ [Memecahkan masalah identitas dan akses Amazon RDS](security_iam_troubleshoot.md)
+ [Memecahkan Masalah Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) di *Panduan Pengguna Amazon Simple Storage Service*
+ [Memecahkan Masalah Amazon S3 dan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) di *Panduan Pengguna IAM*
# Memanggil AWS Lambda fungsi dari
AWS Lambda adalah layanan komputasi berbasis peristiwa yang memungkinkan Anda menjalankan kode tanpa menyediakan atau mengelola server. Ini tersedia untuk digunakan dengan banyak AWS layanan, termasuk . Misalnya, Anda dapat menggunakan fungsi Lambda untuk memproses pemberitahuan peristiwa dari basis data, atau memuat data dari file setiap kali file baru diunggah ke Amazon S3. Untuk mempelajari lebih lanjut tentang Lambda, lihat [Apa itu? AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) di *Panduan AWS Lambda Pengembang.*
**catatan**
Memanggil AWS Lambda fungsi didukung dalam RDS ini untuk versi PostgreSQL:
Semua PostgreSQL 18 versi
Semua PostgreSQL 17 versi
Semua PostgreSQL versi 16
Semua PostgreSQL versi 15
PostgreSQL 14.1 dan versi minor yang lebih tinggi
PostgreSQL 13.2 dan versi minor yang lebih tinggi
PostgreSQL 12.6 dan versi minor yang lebih tinggi
Berikut ini, Anda dapat menemukan ringkasan langkah-langkah yang diperlukan.
Untuk informasi selengkapnya tentang fungsi Lambda, lihat [Mulai menggunakan Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) dan [Dasar-dasar AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) di *Panduan Developer AWS Lambda *.
**Topics**
+ [Langkah 1: Konfigurasikan untuk koneksi keluar ke AWS Lambda](#PostgreSQL-Lambda-network)
+ [Langkah 2: Konfigurasikan IAM untuk dan AWS Lambda](#PostgreSQL-Lambda-access)
+ [Langkah 3: Instal `aws_lambda` ekstensi untuk](#PostgreSQL-Lambda-install-extension)
+ [Langkah 4: Gunakan fungsi pembantu Lambda dengan instans DB RDS for PostgreSQL (Opsional)](#PostgreSQL-Lambda-specify-function)
+ [Langkah 5: Invokasi fungsi Lambda dari instans DB RDS for PostgreSQL Anda](#PostgreSQL-Lambda-invoke)
+ [Langkah 6: Berikan pengguna lain izin untuk menginvokasi fungsi Lambda](#PostgreSQL-Lambda-grant-users-permissions)
+ [Contoh: Menginvokasi fungsi Lambda dari instans DB RDS for PostgreSQL](PostgreSQL-Lambda-examples.md)
+ [Pesan kesalahan fungsi Lambda](PostgreSQL-Lambda-errors.md)
+ [AWS Lambdafungsi dan referensi parameter](PostgreSQL-Lambda-functions.md)
## Langkah 1: Konfigurasikan untuk koneksi keluar ke AWS Lambda
Fungsi Lambda selalu berjalan di dalam VPC Amazon yang dimiliki oleh layanan. AWS Lambda Lambda menerapkan akses jaringan dan aturan keamanan untuk VPC ini dan mempertahankan serta memantau VPC secara otomatis. Instans DB RDS for PostgreSQL Anda mengirimkan lalu lintas jaringan ke VPC layanan Lambda. Cara Anda mengonfigurasi ini bergantung pada apakah instans DB Anda bersifat publik atau pribadi.
+ **Public RDS untuk instans PostgreSQL DB — Instans DB instans DB** adalah publik jika terletak di subnet publik di VPC Anda, dan jika properti “” instans adalah. PubliclyAccessible `true` Untuk menemukan nilai properti ini, Anda dapat menggunakan [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI perintah. Atau, Anda dapat menggunakan Konsol Manajemen AWS untuk membuka tab **Konektivitas & keamanan** dan memeriksa apakah opsi **Dapat diakses publik** adalah **Ya**. Untuk memverifikasi bahwa instans ini ada di subnet publik VPC, Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI.
Untuk mengatur akses ke Lambda, Anda menggunakan Konsol Manajemen AWS atau AWS CLI untuk membuat aturan keluar pada grup keamanan VPC Anda. Aturan keluar menentukan bahwa TCP dapat menggunakan port 443 untuk mengirim paket ke alamat apa pun IPv4 (0.0.0.0/0).
+ **Private RDS untuk instance PostgreSQL DB** — Dalam hal ini, properti “” instance berada di subnet pribadi. PubliclyAccessible `false` Agar instans dapat berfungsi dengan Lambda, Anda dapat menggunakan gateway Network Address Translation (NAT). Untuk informasi selengkapnya, silakan lihat [Gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). Atau, Anda dapat mengonfigurasi VPC dengan titik akhir VPC untuk Lambda. Untuk informasi selengkapnya, lihat [Titik akhir VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) di *Panduan Pengguna Amazon VPC*. Titik akhir ini merespons panggilan yang dilakukan oleh instans DB RDS for PostgreSQL ke fungsi Lambda Anda. Titik akhir VPC menggunakan resolusi DNS pribadinya sendiri. RDS for PostgreSQL tidak dapat menggunakan titik akhir VPC Lambda hingga Anda mengubah nilai `rds.custom_dns_resolution` dari default-nya 0 (tidak aktif) menjadi 1. Untuk melakukannya:
+ Buat grup parameter DB kustom.
+ Ubah nilai parameter `rds.custom_dns_resolution` dari default `0` ke `1`.
+ Ubah instans DB Anda untuk menggunakan grup parameter DB kustom.
+ Boot ulang instans agar parameter yang diubah dapat diterapkan.
VPC Anda sekarang dapat berinteraksi dengan AWS Lambda VPC di tingkat jaringan. Selanjutnya, konfigurasikan izin menggunakan IAM.
## Langkah 2: Konfigurasikan IAM untuk dan AWS Lambda
Menginvokasi fungsi Lambda dari instans DB RDS for PostgreSQL memerlukan hak istimewa tertentu. Untuk mengonfigurasi hak istimewa yang diperlukan, sebaiknya Anda membuat kebijakan IAM yang memungkinkan invokasi fungsi Lambda, menetapkan kebijakan ke peran, dan kemudian menerapkan peran tersebut ke instans DB Anda. Pendekatan ini memberikan hak istimewa instans DB untuk menginvokasi fungsi Lambda yang ditentukan atas nama Anda. Langkah-langkah berikut menunjukkan cara melakukannya dengan menggunakan AWS CLI.
**Untuk mengonfigurasi izin IAM untuk menggunakan instans Amazon RDS dengan Lambda**
1. Gunakan AWS CLI perintah [create-policy untuk membuat kebijakan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) IAM yang memungkinkan Aurora untuk menjalankan fungsi Lambda yang ditentukan. (ID pernyataan (Sid) adalah deskripsi opsional untuk pernyataan kebijakan Anda dan tidak berpengaruh pada penggunaan.) Kebijakan ini memberi instans DB izin minimum yang diperlukan untuk menginvokasi fungsi Lambda yang ditentukan.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
Sebagai alternatif, Anda dapat menggunakan kebijakan `AWSLambdaRole` yang ditentukan sebelumnya yang memungkinkan Anda menginvokasi fungsi Lambda apa pun. Untuk informasi selengkapnya, lihat [Kebijakan IAM berbasis identitas untuk Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed)
1. Gunakan AWS CLI perintah [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) untuk membuat peran IAM yang dapat diasumsikan oleh kebijakan saat runtime.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Terapkan kebijakan ke peran dengan menggunakan [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) AWS CLI perintah.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. AWS CLI Langkah terakhir ini memungkinkan pengguna basis data instans DB menginvokasi fungsi Lambda.
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
Setelah menyelesaikan konfigurasi VPC dan IAM, Anda sekarang dapat menginstal ekstensi `aws_lambda`. (Perhatikan bahwa Anda dapat menginstal ekstensi kapan saja, tetapi sebelum menyiapkan dukungan VPC dan hak istimewa IAM yang benar, ekstensi `aws_lambda` tidak menambahkan apa pun ke kapabilitas instans DB RDS for PostgreSQL.)
## Langkah 3: Instal `aws_lambda` ekstensi untuk
Ekstensi ini memberi instans DB RDS for PostgreSQL kemampuan untuk memanggil fungsi Lambda dari PostgreSQL.
**Untuk menginstal `aws_lambda` ekstensi di**
Gunakan baris perintah `psql` PostgreSQL atau alat pgAdmin untuk terhubung ke instans DB RDS for PostgreSQL.
1. Hubungkan ke instans DB RDS for PostgreSQL sebagai pengguna dengan hak istimewa `rds_superuser`. Pengguna `postgres` default ditampilkan dalam contoh.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Instal ekstensi `aws_lambda`. Ekstensi `aws_commons` juga diperlukan. Ini memberikan fungsi pembantu `aws_lambda` dan berbagai ekstensi Aurora lainnya untuk PostgreSQL. Jika belum ada di instans DB RDS for PostgreSQL, ekstensi akan diinstal dengan `aws_lambda` seperti yang ditunjukkan sebagai berikut.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
Ekstensi `aws_lambda` diinstal di instans DB . Anda sekarang dapat membuat struktur kemudahan untuk menginvokasi fungsi Lambda.
## Langkah 4: Gunakan fungsi pembantu Lambda dengan instans DB RDS for PostgreSQL (Opsional)
Anda dapat menggunakan fungsi pembantu di ekstensi `aws_commons` untuk menyiapkan entitas yang dapat diinvokasi dengan lebih mudah dari PostgreSQL. Untuk melakukannya, Anda harus memiliki informasi berikut tentang fungsi Lambda:
+ **Nama fungsi** – Nama, Amazon Resource Name (ARN), versi, atau alias fungsi Lambda. Kebijakan IAM yang dibuat [Langkah 2: Konfigurasikan IAM untuk instans dan Lambda](#PostgreSQL-Lambda-access) memerlukan ARN, jadi kami sarankan Anda menggunakan ARN fungsi Anda.
+ **AWS Wilayah** - (Opsional) AWS Wilayah tempat fungsi Lambda berada jika tidak berada di Wilayah yang sama dengan Kluster PostgreSQL DB Aurora Anda RDS untuk instans .
Untuk menyimpan informasi nama fungsi Lambda, Anda menggunakan fungsi [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn). Fungsi pembantu ini menciptakan struktur komposit `aws_commons._lambda_function_arn_1` dengan detail yang dibutuhkan oleh fungsi invokasi. Berikut ini, Anda dapat menemukan tiga pendekatan alternatif untuk menyiapkan struktur komposit ini.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
Salah satu dari nilai ini dapat digunakan dalam panggilan ke fungsi [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). Sebagai contoh, lihat [Langkah 5: Invokasi fungsi Lambda dari instans DB RDS for PostgreSQL Anda](#PostgreSQL-Lambda-invoke).
## Langkah 5: Invokasi fungsi Lambda dari instans DB RDS for PostgreSQL Anda
Fungsi `aws_lambda.invoke` berperilaku sinkron atau asinkron, bergantung pada `invocation_type`. Dua alternatif untuk parameter ini adalah `RequestResponse` (default) dan `Event`, sebagai berikut.
+ **`RequestResponse`** – Jenis invokasi ini *sinkron*. Ini adalah perilaku default saat panggilan dilakukan tanpa menentukan jenis invokasi. Payload respons mencakup hasil dari fungsi `aws_lambda.invoke`. Gunakan jenis invokasi ini jika alur kerja Anda perlu menerima hasil dari fungsi Lambda sebelum melanjutkan.
+ **`Event`** – Jenis invokasi ini *asinkron*. Respons tidak mencakup payload yang berisi hasil. Gunakan jenis invokasi ini jika alur kerja Anda tidak memerlukan hasil dari fungsi Lambda untuk melanjutkan pemrosesan.
Sebagai pengujian sederhana terhadap pengaturan Anda, Anda dapat terhubung ke instans DB menggunakan `psql` dan menginvokasi contoh fungsi dari baris perintah. Misalkan Anda memiliki salah satu fungsi dasar yang disiapkan pada layanan Lambda, seperti fungsi Python sederhana yang diperlihatkan pada tangkapan layar berikut.
![\[Contoh fungsi Lambda yang ditampilkan di for AWS CLI AWS Lambda\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**Untuk menginvokasi contoh fungsi**
1. Hubungkan ke instans DB menggunakan `psql` atau pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Invokasi fungsi menggunakan ARN-nya.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
Respons-nya terlihat sebagai berikut.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
Jika upaya invokasi tidak berhasil, lihat [Pesan kesalahan fungsi Lambda](PostgreSQL-Lambda-errors.md).
## Langkah 6: Berikan pengguna lain izin untuk menginvokasi fungsi Lambda
Dalam langkah ini, hanya Anda sebagai `rds_superuser` yang dapat menginvokasi fungsi Lambda. Untuk mengizinkan pengguna lain menginvokasi fungsi apa pun yang Anda buat, Anda harus memberi mereka izin.
**Untuk memberi pengguna lain izin untuk menginvokasi fungsi Lambda**
1. Hubungkan ke instans DB menggunakan `psql` atau pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Jalankan perintah SQL berikut:
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Contoh: Menginvokasi fungsi Lambda dari instans DB RDS for PostgreSQL
Berikut ini, Anda dapat menemukan beberapa contoh pemanggilan fungsi [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). Sebagian besar contoh menggunakan struktur komposit `aws_lambda_arn_1` yang Anda buat [Langkah 4: Gunakan fungsi pembantu Lambda dengan instans DB RDS for PostgreSQL (Opsional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) untuk menyederhanakan meneruskan detail fungsi. Untuk contoh panggilan asinkron, lihat [Contoh: Invokasi fungsi Lambda asinkron (Event)](#PostgreSQL-Lambda-Event). Semua contoh lain yang tercantum menggunakan panggilan sinkron.
Untuk mempelajari lebih lanjut tentang jenis invokasi Lambda, lihat [Menginvokasi fungsi Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) di *Panduan Developer AWS Lambda *. Untuk informasi selengkapnya tentang `aws_lambda_arn_1`, lihat [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [Contoh: Synchronous (RequestResponse) pemanggilan fungsi Lambda](#PostgreSQL-Lambda-RequestResponse)
+ [Contoh: Invokasi fungsi Lambda asinkron (Event)](#PostgreSQL-Lambda-Event)
+ [Contoh: Menangkap log eksekusi Lambda dalam respons fungsi](#PostgreSQL-Lambda-log-response)
+ [Contoh: Menyertakan konteks klien dalam fungsi Lambda](#PostgreSQL-Lambda-client-context)
+ [Contoh: Menginvokasi fungsi Lambda versi spesifik](#PostgreSQL-Lambda-function-version)
## Contoh: Synchronous (RequestResponse) pemanggilan fungsi Lambda
Berikut ini adalah dua contoh dari invokasi fungsi Lambda sinkron. Hasil dari panggilan fungsi `aws_lambda.invoke` ini sama.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
Parameternya dijelaskan sebagai berikut:
+ `:'aws_lambda_arn_1'` – Parameter ini mengidentifikasi struktur komposit yang dibuat di[Langkah 4: Gunakan fungsi pembantu Lambda dengan instans DB RDS for PostgreSQL (Opsional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function), dengan fungsi pembantu `aws_commons.create_lambda_function_arn`. Anda juga dapat membuat struktur ini sebaris dalam panggilan `aws_lambda.invoke` Anda sebagai berikut.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` – Payload JSON untuk diteruskan ke fungsi Lambda.
+ `'RequestResponse'` – Jenis invokasi Lambda.
## Contoh: Invokasi fungsi Lambda asinkron (Event)
Berikut ini adalah contoh invokasi fungsi Lambda asinkron. Jenis invokasi `Event` menjadwalkan invokasi fungsi Lambda dengan payload input yang ditentukan dan segera kembali. Gunakan jenis invokasi `Event` di alur kerja tertentu yang tidak bergantung pada hasil fungsi Lambda.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Contoh: Menangkap log eksekusi Lambda dalam respons fungsi
Anda dapat menyertakan 4 KB terakhir log eksekusi di respons fungsi dengan menggunakan parameter `log_type` dalam panggilan fungsi `aws_lambda.invoke` Anda. Secara default, parameter ini diatur ke `None`, tetapi Anda dapat menentukan `Tail` untuk menangkap hasil log eksekusi Lambda dalam respons, seperti yang ditunjukkan berikut.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Atur parameter `log_type` fungsi [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) ke `Tail` untuk menyertakan log eksekusi dalam respons. Nilai default untuk parameter `log_type` adalah `None`.
`log_result` yang ditampilkan string yang dienkode `base64`. Anda dapat mendekode kontennya menggunakan kombinasi fungsi PostgreSQL `decode` dan `convert_from`.
Untuk informasi selengkapnya tentang `log_type`, lihat [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Contoh: Menyertakan konteks klien dalam fungsi Lambda
Fungsi `aws_lambda.invoke` memiliki parameter `context` yang dapat Anda gunakan untuk meneruskan informasi yang terpisah dari payload, seperti yang diperlihatkan di bawah.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Untuk menyertakan konteks klien, gunakan objek JSON untuk parameter `context` fungsi [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
Untuk informasi selengkapnya tentang parameter `context`, lihat referensi [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Contoh: Menginvokasi fungsi Lambda versi spesifik
Anda dapat menentukan versi tertentu dari fungsi Lambda dengan menyertakan parameter `qualifier` dengan panggilan `aws_lambda.invoke`. Berikut ini, Anda dapat menemukan contoh yang melakukan ini menggunakan `'custom_version'` sebagai alias untuk versi.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
Anda juga dapat menyediakan pengualifikasi fungsi Lambda dengan detail nama fungsi sebagai berikut.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
Untuk informasi selengkapnya tentang `qualifier` dan parameter lainnya, lihat referensi [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
# Pesan kesalahan fungsi Lambda
Dalam daftar berikut, Anda dapat menemukan informasi tentang pesan kesalahan, dengan kemungkinan penyebab dan solusi.
+ **Masalah konfigurasi VPC**
Masalah konfigurasi VPC dapat memunculkan pesan kesalahan berikut saat mencoba menghubungkan:
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
Penyebab umum kesalahan ini adalah grup keamanan VPC tidak dikonfigurasi dengan benar. Pastikan Anda memiliki aturan keluar untuk TCP yang terbuka pada di 443 grup keamanan VPC Anda, sehingga VPC Anda dapat terhubung ke VPC Lambda.
Jika instans DB Anda bersifat pribadi, periksa penyiapan DNS pribadi untuk VPC Anda. Pastikan bahwa Anda mengatur `rds.custom_dns_resolution` parameter ke 1 dan setup AWS PrivateLink seperti yang diuraikan dalam[Langkah 1: Konfigurasikan untuk koneksi keluar ke AWS Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network). Untuk informasi selengkapnya, lihat [Titik akhir VPC Antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns) ().AWS PrivateLink
+ **Kurangnya izin yang diperlukan untuk menginvokasi fungsi Lambda**
Jika Anda melihat salah satu pesan galat berikut, berarti pengguna (peran) yang menginvokasi fungsi ini tidak memiliki izin yang tepat.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Pengguna (peran) harus diberi izin khusus untuk menginvokasi fungsi Lambda. Untuk informasi selengkapnya, lihat [Langkah 6: Berikan pengguna lain izin untuk menginvokasi fungsi Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Penanganan kesalahan yang tidak tepat dalam fungsi Lambda**
Jika fungsi Lambda menampilkan pengecualian selama pemrosesan permintaan, berarti `aws_lambda.invoke` gagal dengan kesalahan PostgreSQL seperti berikut.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Pastikan untuk menangani kesalahan dalam fungsi Lambda Anda atau di aplikasi PostgreSQL Anda.
# AWS Lambdafungsi dan referensi parameter
Berikut ini adalah referensi untuk fungsi dan parameter yang akan digunakan untuk memanggil Lambda dengan PostgreSQL RDS untuk PostgreSQL.
**Topics**
+ [aws\$1lambda.invoke](#aws_lambda.invoke)
+ [aws\$1commons.create\$1lambda\$1function\$1arn](#aws_commons.create_lambda_function_arn)
+ [parameter aws\$1lambda](#aws_lambda.parameters)
## aws\$1lambda.invoke
Menjalankan fungsi Lambda untuk instans DB RDS for PostgreSQL.
Untuk detail lebih lanjut tentang memanggil fungsi Lambda, lihat juga [Invokasi](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) di *Panduan Developer AWS Lambda.*
**Sintaksis**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Parameter input
**function\$1name**
Nama yang mengidentifikasi fungsi Lambda. Nilai tersebut dapat berupa nama fungsi, sebuah ARN, atau ARN parsial. Untuk daftar format yang memungkinkan, lihat [Format nama fungsi Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) dalam *Panduan Developer AWS Lambda.*
*payload*
Input untuk fungsi Lambda. Formatnya dapat berupa JSON atau JSONB. Untuk informasi selengkapnya, lihat [Jenis JSON](https://www.postgresql.org/docs/current/datatype-json.html) dalam dokumentasi PostgreSQL.
*region*
(Opsional) Wilayah Lambda untuk fungsi tersebut. Secara default, RDS menyelesaikan Wilayah AWS dari ARN penuh di `function_name` atau menggunakan Wilayah instans DB RDS for PostgreSQL. Jika nilai Wilayah ini bertentangan dengan nilai yang disediakan dalam ARN `function_name`, pesan kesalahan akan muncul.
*invocation\$1type*
Jenis invokasi fungsi Lambda. Nilai ini peka huruf besar/kecil. Kemungkinan nilainya termasuk yang berikut ini:
+ `RequestResponse` – Default. Jenis invokasi untuk fungsi Lambda bersifat sinkron dan menampilkan payload respons dalam hasilnya. Gunakan jenis invokasi `RequestResponse` ketika alur kerja Anda bergantung pada penerimaan hasil fungsi Lambda dengan segera.
+ `Event` – Jenis invokasi untuk fungsi Lambda ini bersifat asinkron dan segera kembali tanpa menampilkan payload. Gunakan jenis invokasi `Event` ketika Anda tidak membutuhkan hasil dari fungsi Lambda sebelum alur kerja Anda berlanjut.
+ `DryRun` – Jenis invokasi ini menguji akses tanpa menjalankan fungsi Lambda.
*log\$1type*
Jenis log Lambda untuk ditampilkan dalam parameter output `log_result`. Nilai ini peka huruf besar/kecil. Kemungkinan nilainya termasuk yang berikut ini:
+ Ekor – Parameter output `log_result` yang ditampilkan akan mencakup 4 KB terakhir log eksekusi.
+ Tidak Ada – Tidak ada informasi log Lambda yang ditampilkan.
*context*
Konteks klien dalam format JSON atau JSONB. Kolom yang akan digunakan termasuk `custom` dan `env`.
*qualifier*
Pengualifikasi yang mengidentifikasi versi fungsi Lambda yang akan diinvokasi. Jika nilai ini bertentangan dengan nilai yang disediakan dalam ARN `function_name`, pesan kesalahan akan muncul.Parameter output
*status\$1code*
Kode respons status HTTP. Untuk informasi selengkapnya, lihat [Elemen respons invokasi Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) di *Panduan Developer AWS Lambda.*
*payload*
Informasi yang ditampilkan dari fungsi Lambda yang berjalan. Formatnya berupa JSON atau JSONB.
*executed\$1version*
Versi fungsi Lambda yang berjalan.
*log\$1result*
Informasi log eksekusi yang ditampilkan jika nilai `log_type` adalah `Tail` ketika fungsi Lambda diinvokasi. Hasilnya berisi 4 KB terakhir log eksekusi yang dikodekan dalam Base64.
## aws\$1commons.create\$1lambda\$1function\$1arn
Membuat struktur `aws_commons._lambda_function_arn_1` untuk menyimpan informasi nama fungsi Lambda. Gunakan hasil fungsi `aws_commons.create_lambda_function_arn` dalam parameter `function_name` dari fungsi [aws\$1lambda.invoke](#aws_lambda.invoke) aws\$1lambda.invoke.
**Sintaksis**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Parameter input
*function\$1name*
String teks yang diperlukan berisi nama fungsi Lambda. Nilai tersebut dapat berupa nama fungsi, ARN penuh, atau ARN parsial.
*region*
String teks opsional yang berisi Wilayah AWS tempat fungsi Lambda berada. Untuk daftar nama Wilayah dan nilai terkait, lihat [Wilayah, Zona Ketersediaan, dan Zona Lokal](Concepts.RegionsAndAvailabilityZones.md).
## parameter aws\$1lambda
Dalam tabel ini, Anda dapat menemukan parameter yang terkait dengan `aws_lambda` fungsi tersebut.
| Parameter | Deskripsi |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | Ini adalah parameter dinamis dan menetapkan waktu tunggu maksimum saat menghubungkan ke AWS Lambda. Nilai defaultnya adalah`1000`. Nilai yang diizinkan untuk parameter ini adalah 1 - 900000. |
| `aws_lambda.request_timeout_ms` | Ini adalah parameter dinamis dan menetapkan waktu tunggu maksimum sambil menunggu respons dari AWS Lambda. Nilai defaultnya adalah`3000`. Nilai yang diizinkan untuk parameter ini adalah 1 - 900000. |
| `aws_lambda.endpoint_override` | Menentukan endpoint yang dapat digunakan untuk terhubung ke LambdaAWS. String kosong memilih titik akhir AWS Lambda default untuk wilayah tersebut. Anda harus me-restart database agar perubahan parameter statis ini berlaku. |
# Tugas DBA umum untuk Amazon RDS for PostgreSQL
Administrator database (DBAs) melakukan berbagai tugas saat mengelola Amazon RDS for PostgreSQL DB instance. Jika Anda seorang DBA yang sudah terbiasa dengan PostgreSQL, Anda perlu menyadari beberapa perbedaan penting antara menjalankan PostgreSQL di perangkat keras Anda dan RDS for PostgreSQL. Misalnya, karena ini adalah layanan terkelola, Amazon RDS tidak mengizinkan akses shell ke instans DB Anda. Ini berarti Anda tidak memiliki akses langsung ke file `pg_hba.conf` dan file konfigurasi lainnya. Untuk RDS for PostgreSQL, perubahan yang biasanya dilakukan pada file konfigurasi PostgreSQL dari instans on-premise dibuat ke grup parameter DB kustom yang terkait dengan instans DB RDS for PostgreSQL. Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Anda juga tidak dapat mengakses file log dengan cara yang sama seperti yang Anda lakukan dengan instans PostgreSQL on-premise. Untuk mempelajari pencatatan selengkapnya, lihat [](USER_LogAccess.Concepts.PostgreSQL.md).
Sebagai contoh lain, Anda tidak memiliki akses ke akun PostgreSQL `superuser`. Di RDS for PostgreSQL, peran `rds_superuser` merupakan peran yang paling istimewa, dan diberikan ke `postgres` pada saat penyiapan. Meskipun Anda telah terbiasa menggunakan PostgreSQL on-premise atau baru menggunakan RDS for PostgreSQL, sebaiknya Anda memahami peran `rds_superuser`, serta cara bekerja dengan peran, pengguna, grup, dan izin. Untuk informasi selengkapnya, lihat [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Berikut ini adalah beberapa tugas DBA umum untuk RDS for PostgreSQL.
**Topics**
+ [Koleksi didukung di Aurora](PostgreSQL-Collations.md)
+ [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Penanganan koneksi mati di PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Mengelola jumlah objek tinggi di Amazon RDS untuk PostgreSQL Amazon Aurora](PostgreSQL.HighObjectCount.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [Bekerja dengan mekanisme pencatatan log yang didukung oleh RDS for PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Mengelola file sementara dengan PostgreSQL](PostgreSQL.ManagingTempFiles.md)
+ [Menggunakan pgBadger untuk analisis log dengan PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [Menggunakan PGSnapper untuk memantau PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [](PostgreSQL.CustomCasts.md)
+ [Praktik Terbaik untuk Kueri Paralel di PostgreSQL RDS untuk PostgreSQL](PostgreSQL.ParallelQueries.md)
+ [Bekerja dengan parameter pada instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Koleksi didukung di Aurora
Kolasi adalah serangkaian aturan yang menentukan cara pengurutan dan perbandingan string karakter yang disimpan di basis data. Kolasi memiliki peran mendasar dalam sistem komputer dan dimasukkan sebagai bagian dari sistem operasi. Kolasi berubah dari waktu ke waktu ketika karakter baru ditambahkan ke bahasa atau ketika aturan urutan berubah.
Pustaka kolasi menentukan aturan dan algoritma khusus untuk kolasi. Pustaka kolasi paling populer yang digunakan dalam PostgreSQL adalah GNU C (glibc) dan komponen Internasionalisasi untuk Unicode (ICU). Secara default, RDS for PostgreSQL menggunakan kolasi glibc yang mencakup urutan karakter unicode untuk urutan karakter multi-byte.
Saat Anda membuat instans DB di RDS for PostgreSQL baru, ini akan memeriksa sistem operasi untuk kolasi yang tersedia. Parameter PostgreSQL dari perintah `CREATE DATABASE`, `LC_COLLATE`, dan `LC_CTYPE` digunakan untuk menentukan kolasi, yang merupakan kolasi default dalam basis data tersebut. Atau, Anda juga dapat menggunakan parameter `LOCALE` di `CREATE DATABASE` untuk menetapkan parameter ini. Parameter ini menentukan kolasi default untuk string karakter dalam basis data dan aturan untuk mengklasifikasikan karakter sebagai huruf, angka, atau simbol. Anda juga dapat memilih kolasi untuk digunakan pada kolom, indeks, atau kueri.
RDS for PostgreSQL bergantung pada pustaka glibc di sistem operasi untuk dukungan kolasi. Instans RDS for PostgreSQL diperbarui secara berkala dengan versi terbaru sistem operasi. Pembaruan ini terkadang menyertakan versi pustaka glibc yang lebih baru. Jarang sekali versi glibc yang lebih baru mengubah tata urutan atau kolasi beberapa karakter, yang dapat menyebabkan data diurutkan secara berbeda atau menghasilkan entri indeks yang tidak valid. Jika terjadi masalah terkait tata urutan kolasi selama pembaruan, Anda mungkin perlu membuat ulang indeks.
Untuk memperkecil potensi dampak pembaruan glibc, RDS for PostgreSQL kini menyertakan pustaka kolasi default independen. Pustaka kolasi ini tersedia di RDS for PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23, dan rilis versi minor yang lebih baru. Pustaka ini kompatibel dengan glibc 2.26-59.amzn2, dan menyediakan stabilitas tata urutan untuk mencegah kesalahan hasil kueri.
# Memahami peran dan izin PostgreSQL
Bila Anda membuat menggunakan, akun administrator dibuat pada saat yang sama. Konsol Manajemen AWS Secara default, akun tersebut akan dinamakan `postgres`, seperti yang ditunjukkan pada gambar berikut:
![\[Identitas login default untuk Kredensial di halaman Buat basis data adalah postgres.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Anda dapat memilih nama lain daripada menerima nama default (`postgres`). Jika ya, nama yang Anda pilih harus dimulai dengan huruf dan terdiri atas 1 hingga 16 karakter alfanumerik. Untuk menyederhanakan, kami merujuk ke akun pengguna utama ini dengan nilai default-nya (`postgres`) di seluruh panduan ini.
Jika Anda menggunakan `create-db-instance` AWS CLI bukan Konsol Manajemen AWS, Anda membuat nama dengan meneruskannya dengan `master-username` parameter dalam perintah. Untuk informasi selengkapnya, lihat [Membuat instans DB Amazon RDS](USER_CreateDBInstance.md).
Baik Anda menggunakan Konsol Manajemen AWS, API AWS CLI, atau Amazon RDS, dan apakah Anda menggunakan `postgres` nama default atau memilih nama yang berbeda, akun pengguna database pertama ini adalah anggota `rds_superuser` grup dan memiliki `rds_superuser` hak istimewa.
**Topics**
+ [Memahami peran rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Mengontrol akses pengguna ke basis data PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Menyerahkan dan mengendalikan manajemen kata sandi pengguna](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL](PostgreSQL_Password_Encryption_configuration.md)
# Memahami peran rds\$1superuser
Dalam PostgreSQL, *peran* dapat menentukan pengguna, grup, atau sekumpulan izin tertentu yang diberikan kepada grup atau pengguna untuk berbagai objek dalam basis data. Perintah PostgreSQL untuk `CREATE USER` dan `CREATE GROUP` telah digantikan oleh `CREATE ROLE` yang lebih umum dengan properti khusus untuk membedakan pengguna basis data. Pengguna basis data dapat dianggap sebagai peran dengan hak akses LOGIN.
**catatan**
Perintah `CREATE USER` dan `CREATE GROUP` masih dapat digunakan. Untuk informasi selengkapnya, lihat [Database Roles](https://www.postgresql.org/docs/current/user-manag.html) dalam dokumentasi PostgreSQL.
Pengguna `postgres` adalah pengguna basis data dengan hak akses tertinggi di instans DB RDS for PostgreSQL. Pengguna tersebut memiliki karakteristik yang ditentukan oleh pernyataan `CREATE ROLE` berikut.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Properti`NOSUPERUSER`, `NOREPLICATION`, `INHERIT`, dan `VALID UNTIL 'infinity'` merupakan opsi default untuk CREATE ROLE, kecuali ditentukan lain.
Secara default, `postgres` memiliki hak akses yang diberikan kepada peran `rds_superuser`, serta izin untuk membuat peran dan basis data. Peran `rds_superuser` mengizinkan pengguna `postgres` untuk melakukan tindakan berikut:
+ Menambahkan ekstensi yang tersedia untuk digunakan dengan Amazon RDS. Untuk informasi selengkapnya, lihat [Menggunakan fitur PostgreSQL yang didukung oleh Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Buat peran dan berikan hak akses kepada pengguna. Untuk informasi selengkapnya, lihat [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) dan [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) dalam dokumentasi PostgreSQL.
+ Membuat basis data. Untuk informasi selengkapnya, lihat [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) dalam dokumentasi PostgreSQL.
+ Berikan hak akses `rds_superuser` untuk peran pengguna yang tidak memiliki hak akses ini, dan cabut hak akses sesuai kebutuhan. Sebaiknya berikan peran ini hanya untuk pengguna yang menjalankan tugas superuser. Dengan kata lain, Anda dapat memberikan peran ini kepada administrator database (DBAs) atau administrator sistem.
+ Berikan (dan cabut) peran `rds_replication` kepada pengguna basis data yang tidak memiliki peran `rds_superuser`.
+ Berikan (dan cabut) peran `rds_password` kepada pengguna basis data yang tidak memiliki peran `rds_superuser`.
+ Dapatkan informasi status tentang semua koneksi basis data dengan menggunakan tampilan `pg_stat_activity`. Bila diperlukan, `rds_superuser` dapat menghentikan semua koneksi menggunakan `pg_terminate_backend` atau `pg_cancel_backend`.
Dalam pernyataan `CREATE ROLE postgres...`, Anda dapat melihat bahwa peran pengguna `postgres` secara khusus melarang izin `superuser` PostgreSQL. RDS for PostgreSQL adalah layanan terkelola, jadi Anda tidak dapat mengakses OS host, dan terhubung menggunakan akun `superuser` PostgreSQL. Banyak tugas yang memerlukan akses `superuser` pada PostgreSQL mandiri dikelola secara otomatis oleh Amazon RDS.
Untuk informasi selengkapnya tentang pemberian hak akses, lihat [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) dalam dokumentasi PostgreSQL.
Peran `rds_superuser` adalah satu dari beberapa peran yang *telah ditentukan* dalam . instans DB RDS for PostgreSQL.
**catatan**
Dalam PostgreSQL 13 dan rilis sebelumnya, peran yang *telah ditentukan* dikenal sebagai peran *default*.
Dalam daftar berikut, Anda akan menemukan beberapa peran standar lainnya yang dibuat secara otomatis untuk yang baru. instans DB RDS for PostgreSQL. Peran yang telah ditentukan dan hak aksesnya tidak dapat diubah. Anda tidak dapat menghapus, mengganti nama, atau memodifikasi hak akses untuk peran yang telah ditentukan ini. Mencoba untuk melakukannya akan mengakibatkan kesalahan.
+ **rds\$1password** — Peran yang dapat mengubah kata sandi dan mengatur batasan kata sandi untuk pengguna basis data. `rds_superuser`Peran diberikan dengan peran ini secara default, dan dapat memberikan peran tersebut kepada pengguna database. Untuk informasi selengkapnya, lihat [Mengontrol akses pengguna ke basis data PostgreSQLMengontrol akses pengguna ke PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Untuk RDS untuk PostgreSQL versi yang lebih tua dari 14`rds_password`, peran dapat mengubah kata sandi dan mengatur batasan kata sandi untuk pengguna database dan pengguna dengan peran. `rds_superuser` Dari RDS untuk PostgreSQL versi 14 dan yang lebih baru`rds_password`, peran dapat mengubah kata sandi dan mengatur batasan kata sandi hanya untuk pengguna database. Hanya pengguna dengan `rds_superuser` peran yang dapat melakukan tindakan ini pada pengguna lain yang memiliki `rds_superuser` peran.
+ **rdsadmin** — Peran yang dibuat untuk menangani banyak tugas manajemen yang dilakukan oleh administrator dengan hak akses `superuser` pada basis data PostgreSQL mandiri. Peran ini digunakan secara internal oleh RDS for PostgreSQL untuk banyak tugas manajemen.
+ **rdstopmgr** - Peran yang digunakan secara internal oleh Amazon RDS untuk mendukung deployment multi-AZ.
+ **rds\$1reserved** — Peran yang digunakan secara internal oleh Amazon RDS untuk mencadangkan koneksi database.
# Melihat peran dan hak istimewa mereka
Anda dapat melihat peran yang telah ditentukan dan hak istimewanya di RDS untuk instans PostgreSQL DB menggunakan perintah yang berbeda tergantung pada versi PostgreSQL Anda. Untuk melihat semua peran yang telah ditentukan, Anda dapat terhubung ke RDS untuk instans PostgreSQL DB dan menjalankan perintah berikut menggunakan. `psql`
**Untuk `psql` 15 dan versi sebelumnya**
Connect ke RDS Anda untuk PostgreSQL DB instance dan gunakan perintah di psql: `\du`
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Untuk `psql` 16 dan versi yang lebih baru**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Untuk memeriksa keanggotaan peran tanpa ketergantungan versi, Anda dapat menggunakan kueri SQL berikut:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Dalam output, Anda dapat melihat bahwa `rds_superuser` itu bukan peran pengguna basis data (tidak dapat masuk), tetapi memiliki hak akses dari banyak peran lainnya. Anda juga dapat melihat bahwa pengguna basis data `postgres` adalah anggota peran `rds_superuser`. Seperti disebutkan sebelumnya, `postgres` adalah nilai default di halaman **Buat basis data** konsol Amazon RDS. Jika Anda memilih nama lain, nama itu akan ditampilkan dalam daftar peran.
# Mengontrol akses pengguna ke basis data PostgreSQL
Basis data baru di PostgreSQL selalu dibuat dengan serangkaian hak akses default dalam skema `public` basis data yang memungkinkan semua pengguna dan peran basis data untuk membuat objek. Hak akses ini memungkinkan pengguna basis data untuk terhubung ke basis data, misalnya, dan membuat tabel sementara saat terhubung.
Agar dapat mengontrol dengan lebih baik akses pengguna ke instans basis data yang Anda buat di instans DB RDS for PostgreSQL, sebaiknya Anda mencabut hak akses `public` default. Setelah melakukannya, Anda kemudian memberikan hak akses khusus untuk pengguna basis data secara lebih rinci, seperti yang diperlihatkan dalam prosedur berikut ini.
**Untuk menyiapkan peran dan hak akses untuk instans basis data baru**
Misalnya, Anda sedang menyiapkan basis data pada instans DB RDS for PostgreSQL yang baru dibuat untuk digunakan oleh beberapa peneliti, yang semuanya membutuhkan akses baca-tulis ke basis data.
1. Gunakan `psql` (atau pgAdmin) untuk menghubungkan ke instans DB RDS for PostgreSQL Anda:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Saat diminta, masukkan kata sandi Anda. Klien `psql` menghubungkan dan menampilkan basis data koneksi administratif default, `postgres=>`, sebagai perintah.
1. Untuk mencegah pengguna basis data membuat objek dalam skema `public`, lakukan tindakan berikut:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Selanjutnya, buat instans basis data baru:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Cabut semua hak akses dari skema `PUBLIC` pada basis data baru ini.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Buat peran untuk pengguna basis data.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Berikan pengguna basis data yang memiliki peran ini kemampuan untuk terhubung ke basis data.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Berikan semua hak akses pada basis data ini kepada semua pengguna dengan peran `lab_tech`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Buat pengguna basis data, sebagai berikut:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Beri hak akses terkait peran lab\$1tech kepada dua pengguna ini:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
Pada titik ini, `lab_user1` dan `lab_user2` dapat terhubung ke basis data `lab_db`. Contoh ini tidak mengikuti praktik terbaik untuk penggunaan perusahaan, yang mungkin termasuk membuat beberapa instans basis data, skema yang berbeda, dan pemberian izin terbatas. Untuk informasi yang lebih lengkap dan skenario tambahan lainnya, lihat [Mengelola Pengguna dan Peran PostgreSQL](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Untuk informasi selengkapnya tentang hak akses di PostgreSQL, lihat perintah [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) dalam dokumentasi PostgreSQL.
# Menyerahkan dan mengendalikan manajemen kata sandi pengguna
Sebagai DBA, Anda mungkin perlu menyerahkan manajemen kata sandi pengguna. Atau, Anda juga dapat mencegah pengguna basis data mengubah kata sandi mereka atau mengonfigurasi ulang batasan kata sandi, seperti masa pakai kata sandi. Untuk memastikan bahwa hanya pengguna basis data yang Anda pilih yang dapat mengubah pengaturan kata sandi, Anda dapat mengaktifkan fitur manajemen kata sandi terbatas. Bila mengaktifkan fitur ini, hanya pengguna basis data yang telah diberikan peran `rds_password` yang dapat mengelola kata sandi.
**catatan**
Untuk menggunakan manajemen kata sandi terbatas, instans DB RDS for PostgreSQL harus menjalankan PostgreSQL 10.6 atau versi lebih tinggi.
Secara default, fitur ini dalam keadaan `off`, seperti yang ditunjukkan berikut:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Untuk mengaktifkan fitur ini, Anda harus menggunakan grup parameter kustom dan mengubah pengaturan `rds.restrict_password_commands` ke 1. Pastikan untuk melakukan booting ulang instans DB RDS for PostgreSQL agar pengaturan dapat berlaku.
Dalam keadaan fitur ini aktif, hak akses `rds_password` diperlukan untuk perintah SQL berikut:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Mengganti nama role (`ALTER ROLE myrole RENAME TO newname`) juga dibatasi jika password menggunakan algoritma MD5 hashing.
Jika fitur ini dalam keadaan aktif, mencoba salah satu perintah SQL ini tanpa izin peran `rds_password` akan menghasilkan kesalahan berikut:
```
ERROR: must be a member of rds_password to alter passwords
```
Sebaiknya Anda memberikan `rds_password` hanya untuk beberapa peran yang Anda gunakan semata untuk manajemen kata sandi. Jika memberikan hak akses `rds_password` kepada pengguna basis data yang tidak memiliki hak akses `rds_superuser`, Anda juga harus memberi mereka atribut `CREATEROLE`.
Pastikan Anda memverifikasi persyaratan kata sandi seperti kedaluwarsa dan kompleksitas yang diperlukan di sisi klien. Jika Anda menggunakan utilitas sisi klien Anda sendiri untuk perubahan terkait kata sandi, utilitas tersebut harus menjadi anggota `rds_password` dan memiliki hak akses `CREATE ROLE`.
# Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL
The *Salted Challenge Response Authentication Mechanism (SCRAM)* adalah alternatif dari algoritma message digest (MD5) default PostgreSQL untuk mengenkripsi kata sandi. Mekanisme otentikasi SCRAM dianggap lebih aman daripada. MD5 Untuk mempelajari selengkapnya tentang dua pendekatan berbeda untuk mengamankan kata sandi ini, lihat [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) dalam dokumentasi PostgreSQL.
Kami menyarankan Anda menggunakan SCRAM daripada MD5 sebagai skema enkripsi kata sandi untuk cluster DB Anda. Instans DB RDS for PostgreSQL. Ini adalah mekanisme respons tantangan kriptografi yang menggunakan algoritma scram-sha-256 untuk autentikasi dan enkripsi kata sandi.
Anda mungkin perlu memperbarui pustaka untuk aplikasi klien Anda agar dapat mendukung SCRAM. Misalnya, versi JDBC sebelum 42.2.0 tidak mendukung SCRAM. Untuk informasi selengkapnya, lihat [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) dalam dokumentasi Driver JDBC PostgreSQL. Untuk daftar driver PostgreSQL dan dukungan SCRAM lainnya, lihat [List of drivers](https://wiki.postgresql.org/wiki/List_of_drivers) dalam dokumentasi PostgreSQL.
RDS for PostgreSQL versi 13.1 dan lebih tinggi mendukung scram-sha-256. Versi ini juga memungkinkan Anda mengonfigurasi instans DB agar mengharuskan SCRAM, seperti yang dibahas dalam prosedur berikut.
## Menyiapkan untuk memerlukan SCRAM
Anda dapat meminta instans DB RDS for PostgreSQL untuk hanya menerima kata sandi yang menggunakan algoritma scram-sha-256.
**penting**
Untuk Proksi RDS yang ada dengan basis data PostgreSQL, jika Anda mengubah autentikasi basis data untuk hanya menggunakan `SCRAM`, proksi akan menjadi tidak tersedia selama maksimal 60 detik. Untuk menghindari masalah ini, lakukan salah satu tindakan berikut:
Pastikan basis data mengizinkan autentikasi `SCRAM` dan `MD5`.
Untuk hanya menggunakan autentikasi `SCRAM`, buat proksi baru, migrasikan lalu lintas aplikasi Anda ke proksi baru, lalu hapus proksi yang sebelumnya terkait dengan basis data.
Sebelum melakukan perubahan pada sistem, pastikan Anda telah memahami proses lengkapnya, sebagai berikut:
+ Dapatkan informasi semua peran dan enkripsi kata sandi untuk semua pengguna basis data.
+ Periksa kembali pengaturan parameter instans DB RDS for PostgreSQL untuk parameter yang mengontrol enkripsi kata sandi.
+ Jika instans DB RDS for PostgreSQL menggunakan grup parameter default, maka Anda harus membuat grup parameter DB kustom, lalu menerapkannya ke instans DB RDS for PostgreSQL agar Anda dapat memodifikasi parameter saat diperlukan. Jika instans DB RDS for PostgreSQL menggunakan grup parameter kustom, Anda dapat memodifikasi parameter yang diperlukan nanti selama prosesnya sesuai kebutuhan.
+ Ubah parameter `password_encryption` ke `scram-sha-256`.
+ Beri tahu semua pengguna basis data bahwa mereka perlu memperbarui kata sandi. Lakukan hal yang sama untuk akun `postgres` Anda. Kata sandi baru telah dienkripsi dan disimpan menggunakan algoritma scram-sha-256.
+ Verifikasikan bahwa semua kata sandi telah dienkripsi menggunakan jenis enkripsi tersebut.
+ Jika semua kata sandi menggunakan scram-sha-256, Anda dapat mengubah parameter `rds.accepted_password_auth_method` dari `md5+scram` ke `scram-sha-256`.
**Awas**
Setelah Anda mengubah `rds.accepted_password_auth_method` ke scram-sha-256 saja, setiap pengguna (peran) dengan kata sandi terenkripsi `md5` tidak dapat terhubung.
### Bersiap-siap untuk meminta SCRAM untuk
Sebelum membuat perubahan apa pun pada instans DB RDS for PostgreSQL, periksa semua akun pengguna basis data yang ada. Periksa juga jenis enkripsi yang digunakan untuk kata sandi. Anda dapat melakukan semua tugas ini menggunakan ekstensi `rds_tools`. Untuk melihat versi PostgreSQL yang `rds_tools` didukung, [lihat Versi ekstensi untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) for PostgreSQL.
**Untuk mendapatkan daftar pengguna (peran) basis data dan metode enkripsi kata sandi**
1. Gunakan `psql` untuk terhubung ke instans DB RDS for PostgreSQL Anda, sebagaimana yang ditunjukkan di bawah ini.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Instal ekstensi `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Dapatkan daftar peran dan enkripsi.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Anda akan melihat output yang mirip dengan berikut ini.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Membuat grup parameter DB kustom
**catatan**
Jika instans DB RDS for PostgreSQL sudah menggunakan grup parameter kustom, Anda tidak perlu membuat grup parameter yang baru.
Untuk ringkasan grup parameter Amazon RDS, lihat [Bekerja dengan parameter pada instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Jenis enkripsi kata sandi yang digunakan untuk kata sandi yang diatur dalam satu parameter, `password_encryption`. Enkripsi yang diizinkan oleh instans DB RDS for PostgreSQL diatur dalam parameter lain, `rds.accepted_password_auth_method`. Mengubah salah satu dari nilai default ini mengharuskan Anda membuat grup parameter DB kustom, lalu menerapkannya ke instans.
Anda juga dapat menggunakan Konsol Manajemen AWS atau RDS API untuk membuat DB. Untuk informasi lebih lanjut, lihat
Anda kini dapat mengaitkan grup parameter kustom dengan instans DB.
**Untuk membuat parameter DB**
1. Gunakan perintah CLI `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` untuk membuat grup parameter DB kustom. Contoh ini menggunakan `postgres13` sebagai sumber untuk grup parameter kustom ini.
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Untuk Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Gunakan perintah CLI `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` untuk menerapkan grup parameter kustom ini ke klaster DB RDS for PostgreSQL.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Untuk Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Untuk menyinkronkan ulang instans DB RDS for PostgreSQL dengan grup parameter DB kustom, Anda perlu melakukan boot ulang instans primer dan semua instans lain klaster. Untuk meminimalkan dampak pada pengguna Anda, jadwalkan proses ini agar berlangsung selama masa pemeliharaan rutin.
### Mengonfigurasi enkripsi kata sandi agar menggunakan SCRAM
Mekanisme enkripsi kata sandi yang digunakan oleh instans DB RDS for PostgreSQL diatur dalam grup parameter DB dalam parameter `password_encryption`. Nilai yang diizinkan tidak ditentukan, `md5`, atau `scram-sha-256`. Nilai default bergantung pada versi RDS for PostgreSQL, sebagai berikut:
+ RDS for PostgreSQL 14 dan versi di atasnya – Default adalah `scram-sha-256`
+ RDS for PostgreSQL 13 – Default adalah `md5`
Dengan grup parameter DB kustom yang terhubung ke instans DB RDS for PostgreSQL, Anda dapat memodifikasi nilai untuk parameter enkripsi kata sandi.
![\[Berikutnya, konsol RDS akan menunjukkan nilai default parameter password_encryption untuk RDS for PostgreSQL.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Untuk mengubah pengaturan enkripsi kata sandi menjadi scram-sha-256**
+ Ubah nilai enkripsi kata sandi menjadi scram-sha-256, sebagaimana ditunjukkan berikut ini. Perubahan dapat langsung diterapkan karena parameternya dinamis, jadi mulai ulang tidak diperlukan agar perubahan diterapkan.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Untuk Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Memigrasikan kata sandi untuk peran pengguna ke SCRAM
Anda dapat memigrasikan kata sandi untuk peran pengguna ke SCRAM sebagaimana dijelaskan berikut.
**Untuk memigrasikan kata sandi pengguna (peran) basis data dari MD5 ke SCRAM**
1. Masuk sebagai pengguna administrator (nama pengguna default, `postgres`) sebagaimana ditunjukkan berikut.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Periksa pengaturan parameter `password_encryption` pada instans DB RDS for PostgreSQL menggunakan perintah berikut.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Ubah nilai parameter ini menjadi scram-sha-256. Untuk informasi selengkapnya, lihat [Mengonfigurasi enkripsi kata sandi agar menggunakan SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Periksa kembali nilainya untuk memastikan bahwa sekarang diatur ke`scram-sha-256`, sebagai berikut.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Beri tahu semua pengguna basis data untuk mengubah kata sandi mereka. Pastikan juga untuk mengubah kata sandi Anda sendiri untuk akun `postgres` (pengguna basis data dengan hak akses `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Ulangi proses tersebut untuk semua basis data di Anda. instans DB RDS for PostgreSQL.
### Mengubah parameter untuk mengharuskan SCRAM
Ini adalah langkah terakhir dalam proses. Setelah Anda membuat perubahan dalam prosedur berikut, setiap akun pengguna (peran) yang masih menggunakan enkripsi `md5` untuk kata sandi tidak dapat masuk ke . instans DB RDS for PostgreSQL.
`rds.accepted_password_auth_method` menentukan metode enkripsi yang instans DB RDS for PostgreSQL menerima untuk kata sandi pengguna selama proses masuk. Nilai default-nya adalah `md5+scram`, yang berarti bahwa salah satu metode diterima. Pada gambar berikut, Anda dapat menemukan pengaturan default untuk parameter ini.
![\[Konsol RDS menunjukkan nilai default dan yang diizinkan untuk parameter rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Nilai yang diizinkan untuk parameter ini adalah `md5+scram` atau `scram` saja. Mengubah nilai parameter ini ke `scram` akan menjadikannya sebagai persyaratan.
**Untuk mengubah nilai parameter agar mengharuskan autentikasi SCRAM untuk kata sandi**
1. Verifikasikan bahwa semua kata sandi pengguna basis data untuk semua basis data di instans DB RDS for PostgreSQL menggunakan `scram-sha-256` untuk enkripsi kata sandi. Untuk melakukannya, buat kueri `rds_tools` untuk peran (pengguna) dan jenis enkripsi, sebagai berikut.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Ulangi kueri di semua instans DB dalam Anda. Instans DB RDS for PostgreSQL.
Jika semua kata sandi menggunakan scram-sha-256, Anda dapat melanjutkan.
1. Ubah nilai autentikasi kata sandi yang diterima menjadi scram-sha-256, sebagai berikut.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Untuk Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Penanganan koneksi mati di PostgreSQL
Koneksi mati terjadi ketika sesi database tetap aktif di server meskipun aplikasi klien telah ditinggalkan atau dihentikan secara tidak normal. Situasi ini biasanya muncul ketika proses klien macet atau berhenti secara tak terduga tanpa menutup koneksi database mereka dengan benar atau membatalkan permintaan yang sedang berlangsung.
PostgreSQL secara efisien mengidentifikasi dan membersihkan koneksi mati saat proses server menganggur atau mencoba mengirim data ke klien. Namun, deteksi menantang untuk sesi yang menganggur, menunggu masukan klien, atau menjalankan kueri secara aktif. Untuk menangani skenario ini, PostgreSQL `tcp_keepalives_*` menyediakan,, dan parameter. `tcp_user_timeout` `client_connection_check_interval`
**Topics**
+ [Memahami TCP keepalive](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [Kasus penggunaan untuk pengaturan TCP keepalive](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [Praktik terbaik](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Memahami TCP keepalive
TCP Keepalive adalah mekanisme tingkat protokol yang membantu menjaga dan memverifikasi integritas koneksi. Setiap koneksi TCP mempertahankan pengaturan tingkat kernel yang mengatur perilaku keepalive. Ketika timer keepalive kedaluwarsa, sistem melakukan hal berikut:
+ Mengirim paket probe tanpa data dan set flag ACK.
+ Mengharapkan respons dari titik akhir jarak jauh sesuai dengan spesifikasi. TCP/IP
+ Mengelola status koneksi berdasarkan respons atau kekurangannya.
##
| Parameter | Deskripsi | Nilai default |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Menentukan jumlah detik tidak aktif sebelum mengirim pesan keepalive. | 300 |
| tcp\$1keepalives\$1interval | Menentukan jumlah detik antara transmisi ulang pesan keepalive yang tidak diakui. | 30 |
| tcp\$1keepalives\$1count | Pesan keepalive maksimum yang hilang sebelum menyatakan koneksi mati | 2 |
| tcp\$1user\$1timeout | Menentukan berapa lama (dalam Millidetik) data yang tidak diakui dapat tetap sebelum menutup sambungan secara paksa. | 0 |
| client\$1connection\$1check\$1interval | Mengatur interval (dalam Millidetik) untuk memeriksa status koneksi klien selama kueri yang berjalan lama. Ini memastikan deteksi koneksi tertutup yang lebih cepat. | 0 |
## Kasus penggunaan untuk pengaturan TCP keepalive
### Menjaga sesi idle tetap hidup
Untuk mencegah koneksi idle dihentikan oleh firewall atau router karena tidak aktif:
+ Konfigurasikan `tcp_keepalives_idle` untuk mengirim paket keepalive secara berkala.
### Mendeteksi koneksi mati
Untuk mendeteksi koneksi mati dengan segera:
+ Sesuaikan`tcp_keepalives_idle`,`tcp_keepalives_interval`, dan`tcp_keepalives_count`. Misalnya, dengan default Aurora PostgreSQL, dibutuhkan sekitar satu menit (2 probe × 30 detik) untuk mendeteksi koneksi mati. Menurunkan nilai-nilai ini dapat mempercepat deteksi.
+ Gunakan `tcp_user_timeout` untuk menentukan waktu tunggu maksimum untuk pengakuan.
Pengaturan TCP keepalive membantu kernel mendeteksi koneksi mati, tetapi PostgreSQL mungkin tidak bertindak sampai soket digunakan. Jika sesi menjalankan kueri panjang, koneksi mati mungkin hanya terdeteksi setelah kueri selesai. Di PostgreSQL 14 dan versi yang lebih tinggi`client_connection_check_interval`, dapat mempercepat deteksi koneksi mati dengan melakukan polling soket secara berkala selama eksekusi kueri.
## Praktik terbaik
+ **Tetapkan interval keepalive yang wajar:** Tune`tcp_user_timeout`,`tcp_keepalives_idle`, `tcp_keepalives_count` dan `tcp_keepalives_interval` untuk menyeimbangkan kecepatan deteksi dan penggunaan sumber daya.
+ **Optimalkan untuk lingkungan Anda:** Sejajarkan pengaturan dengan perilaku jaringan, kebijakan firewall, dan kebutuhan sesi.
+ **Memanfaatkan fitur PostgreSQL: Gunakan `client_connection_check_interval` di PostgreSQL** 14 dan versi yang lebih tinggi untuk pemeriksaan koneksi yang efisien.
#
Kami sangat menyarankan Anda menggunakan fitur autovacuum untuk menjaga kondisi instans DB PostgreSQL Anda. Autovacuum akan mengotomatiskan awal perintah VACUUM dan ANALYZE. Kemudian memeriksa tabel yang memuat banyak tuple yang dimasukkan, diperbarui, atau dihapus. Setelah pemeriksaan ini, autovacuum akan mengambil kembali penyimpanan dengan menghapus data usang atau tuple dari basis data PostgreSQL.
Secara default, autovacuum diaktifkan untuk RDS untuk PostgreSQL PostgreSQL DB instance yang Anda buat menggunakan salah satu grup parameter PostgreSQL DB default. Parameter konfigurasi lain yang terkait dengan fitur autovacuum juga diatur secara default. Karena parameter default ini cukup umum, Anda dapat memanfaatkannya dengan menyetel beberapa parameter yang terkait dengan fitur autovacuum untuk beban kerja spesifik Anda.
Untuk informasi tingkat tinggi, lihat[Praktik terbaik untuk menggunakan PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [Mengalokasikan memori untuk autovacuum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [Mengurangi kemungkinan penyelesaian ID transaksi](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [Menentukan apakah tabel di basis data Anda perlu divakum atau tidak](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [Menentukan tabel mana yang saat ini memenuhi syarat untuk autovacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [Menentukan apakah autovacuum saat ini sedang berjalan atau tidak, dan berapa lama durasinya](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [Melakukan pembekuan vakum manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [Mengindeks ulang tabel saat autovacuum berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [Mengelola autovacuum dengan indeks berukuran besar](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [Parameter lain yang memengaruhi autovacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [Mengatur parameter autovacuum tingkat tabel](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [Melakukan log aktivitas autovacuum dan vakum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [Memahami perilaku autovacuum dengan database yang tidak valid](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Mengalokasikan memori untuk autovacuum
Salah satu parameter paling penting yang memengaruhi kinerja autovacuum adalah parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). Dalam RDS untuk PostgreSQL PostgreSQL versi 14 dan `autovacuum_work_mem` sebelumnya, parameter diatur ke -1, menunjukkan bahwa pengaturan digunakan sebagai gantinya. `maintenance_work_mem` Untuk semua versi lainnya, `autovacuum_work_mem` ditentukan oleh GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536).
Operasi vakum manual selalu menggunakan `maintenance_work_mem` pengaturan, dengan pengaturan default GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536), dan juga dapat disesuaikan pada tingkat sesi menggunakan perintah untuk operasi manual yang lebih bertarget. `SET` `VACUUM`
Memori `autovacuum_work_mem` menentukan untuk autovacuum untuk menampung pengidentifikasi tupel mati () untuk indeks penyedot debu. `pg_stat_all_tables.n_dead_tup`
Saat melakukan perhitungan untuk menentukan nilai `autovacuum_work_mem` parameter, perhatikan hal-hal berikut:
+ Jika Anda mengatur parameter terlalu rendah, proses vakum mungkin harus memindai tabel beberapa kali untuk menyelesaikan pekerjaannya. Pemindaian berulang seperti ini dapat berdampak negatif pada performa. Untuk contoh yang lebih besar, pengaturan `maintenance_work_mem` atau `autovacuum_work_mem` setidaknya 1 GB dapat meningkatkan kinerja tabel penyedot debu dengan jumlah tupel mati yang tinggi. Namun, dalam PostgreSQL versi 16 dan sebelumnya, penggunaan memori vakum dibatasi pada 1 GB, yang cukup untuk memproses sekitar 179 juta tupel mati dalam satu lintasan. Jika tabel memiliki lebih banyak tupel mati daripada ini, vakum perlu membuat beberapa lintasan melalui indeks tabel, secara signifikan meningkatkan waktu yang dibutuhkan. Dimulai dengan PostgreSQL versi 17, tidak ada batasan 1 GB, dan autovacuum dapat memproses lebih dari 179 juta tupel dengan menggunakan pohon radix.
Pengenal Tuple berukuran 6 byte. Untuk memperkirakan memori yang diperlukan untuk menyedot indeks tabel, kueri `pg_stat_all_tables.n_dead_tup` untuk menemukan jumlah tupel mati, lalu kalikan angka ini dengan 6 untuk menentukan memori yang diperlukan untuk menyedot debu indeks dalam satu lintasan. Anda dapat menggunakan kueri berikut:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Parameter `autovacuum_work_mem` bekerja secara bersama-sama dengan parameter `autovacuum_max_workers`. Setiap pekerja di antara `autovacuum_max_workers` dapat menggunakan memori yang Anda alokasikan. Jika Anda memiliki banyak tabel kecil, alokasikan lebih banyak parameter `autovacuum_max_workers` dan lebih sedikit parameter `autovacuum_work_mem`. Jika Anda memiliki tabel besar (lebih besar dari 100 GB), alokasikan lebih banyak memori dan lebih sedikit proses pekerja. Anda harus memiliki cukup memori yang dialokasikan agar berhasil di tabel terbesar Anda. Jadi, pastikan bahwa kombinasi proses pekerja dan memori sama dengan total memori yang ingin Anda alokasikan.
## Mengurangi kemungkinan penyelesaian ID transaksi
Dalam beberapa kasus, pengaturan kelompok parameter yang terkait dengan autovacuum mungkin tidak cukup agresif untuk mencegah penyelesaian ID transaksi. Untuk mengatasi hal ini, RDS untuk PostgreSQL yang menyesuaikan nilai parameter autovacuum secara otomatis. *Autovacuum adaptif* Penjelasan terperinci tentang [TransactionID wraparound](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) dapat ditemukan dalam dokumentasi PostgreSQL.
`rds.adaptive_autovacuum` Kami sangat menyarankan Anda untuk tetap mengaktifkan parameter dinamis ini. Namun, untuk menonaktifkan penyesuaian parameter autovacuum adaptif, atur parameter `rds.adaptive_autovacuum` ke 0 atau nonaktifkan.
Sampul ID transaksi masih dimungkinkan bahkan ketika Amazon RDS Aurora RDS menyetel parameter autovacuum. Kami mendorong Anda untuk menerapkan CloudWatch alarm Amazon untuk sampul ID transaksi. Untuk informasi selengkapnya, lihat posting [Menerapkan sistem peringatan dini untuk sampul ID transaksi di RDS untuk PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) di Blog Database. AWS
Dengan penyetelan parameter autovacuum adaptif diaktifkan, Amazon RDS mulai menyesuaikan parameter autovacuum ketika CloudWatch metrik `MaximumUsedTransactionIDs` mencapai nilai parameter atau 500.000.000, mana yang lebih besar. `autovacuum_freeze_max_age`
Amazon RDS terus menyesuaikan parameter untuk autovacuum jika tabel terus menuju ke penyelesaian ID transaksi. Setiap penyesuaian ini secara khusus mengalokasikan lebih banyak sumber daya ke autovacuum untuk menghindari penyelesaian. Amazon RDS memperbarui parameter terkait autovacuum berikut ini:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS akan memodifikasi parameter ini hanya jika nilai yang baru membuat autovacuum lebih agresif. Parameter dimodifikasi dalam memori di instans DB. Nilai di grup parameter tidak diubah. Untuk melihat pengaturan dalam memori saat ini, gunakan perintah PostgreSQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) SQL.
Jika Amazon RDS memodifikasi salah satu parameter autovacuum ini, Amazon RDS akan menghasilkan peristiwa untuk instans DB yang terdampak. Acara ini terlihat di Konsol Manajemen AWS dan melalui Amazon RDS API. Setelah `MaximumUsedTransactionIDs` CloudWatch metrik kembali di bawah ambang batas, Amazon RDS mengatur ulang parameter terkait autovacuum dalam memori kembali ke nilai yang ditentukan dalam grup parameter. Kemudian, Amazon RDS akan menghasilkan peristiwa lain yang sesuai dengan perubahan ini.
# Menentukan apakah tabel di basis data Anda perlu divakum atau tidak
Anda dapat menggunakan kueri berikut untuk menunjukkan jumlah transaksi yang tidak dibekukan dalam database. `datfrozenxid`Kolom `pg_database` baris database adalah batas bawah pada transaksi normal yang IDs muncul di database itu. Kolom ini adalah minimum dari nilai per tabel `relfrozenxid` di dalam basis data.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Sebagai contoh, hasil dari menjalankan kueri sebelumnya adalah sebagai berikut.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Ketika usia database mencapai 2 miliar transaksi IDs, sampul ID transaksi (XID) terjadi dan database menjadi read-only. Anda dapat menggunakan kueri ini untuk menghasilkan metrik dan menjalankannya beberapa kali dalam sehari. Secara default, autovacuum diatur untuk menjaga usia transaksi tidak lebih dari 200.000.000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Contoh strategi pemantauan mungkin terlihat seperti ini:
+ Tetapkan nilai `autovacuum_freeze_max_age` hingga 200 juta transaksi.
+ Jika sebuah tabel mencapai 500 juta transaksi yang tidak dibekukan, itu memicu alarm tingkat keparahan rendah. Tidak ada yang dengan nilai ini, tetapi dapat mengindikasikan bahwa autovacuum tidak dapat diteruskan.
+ Jika tabel berumur 1 miliar, indikasi ini harus diperlakukan sebagai peringatan untuk diambil tindakan. Umumnya, Anda ingin mempertahankan usia tabel mendekati `autovacuum_freeze_max_age` karena alasan performa. Sebaiknya Anda menyelidiki hal ini menggunakan rekomendasi berikut.
+ Jika tabel mencapai 1,5 miliar transaksi yang tidak divakum, ini akan memicu alarm dengan keparahan tingkat tinggi. Bergantung pada seberapa cepat database Anda menggunakan transaksi IDs, alarm ini dapat menunjukkan bahwa sistem kehabisan waktu untuk menjalankan autovacuum. Dalam hal ini, sebaiknya Anda segera menyelesaikan proses ini.
Jika tabel terus-menerus melanggar ambang batas ini, ubah parameter autovacuum Anda. Secara default, menggunakan VACUUM secara manual (yang menonaktifkan penundaan berbasis biaya) bersifat lebih agresif dibandingkan menggunakan autovacuum default, tetapi juga lebih mengganggu sistem secara keseluruhan.
Sebaiknya lakukan hal berikut:
+ Waspada dan aktifkan mekanisme pemantauan agar Anda dapat mengetahui usia transaksi Anda yang paling lama.
Untuk informasi tentang membuat proses yang memperingatkan Anda tentang sampul ID transaksi, lihat posting Blog AWS Database [Menerapkan sistem peringatan dini untuk sampul ID transaksi di Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/).
+ Untuk tabel yang lebih sibuk, lakukan pembekuan vakum manual secara teratur selama pemeliharaan, selain mengandalkan autovacuum. Untuk informasi cara melakukan pembekuan vakum manual, lihat [Melakukan pembekuan vakum manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Menentukan tabel mana yang saat ini memenuhi syarat untuk autovacuum
Sering kali, ada satu atau dua tabel yang harus divakum. Tabel dengan nilai `relfrozenxid` lebih besar dari jumlah transaksi dalam `autovacuum_freeze_max_age` selalu menjadi target autovacuum. Sebaliknya, jika jumlah tuple yang dibuat usang sejak VACUUM terakhir melebihi “ambang batas vakum”, tabel akan divakum.
[Ambang batas autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) didefinisikan sebagai:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
di mana `vacuum base threshold` ada`autovacuum_vacuum_threshold`, `vacuum scale factor` adalah`autovacuum_vacuum_scale_factor`, dan `number of tuples` adalah`pg_class.reltuples`.
Saat Anda terkoneksi ke basis data, jalankan kueri berikut untuk melihat daftar tabel yang dianggap oleh autovacuum telah memenuhi syarat untuk divakum.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Menentukan apakah autovacuum saat ini sedang berjalan atau tidak, dan berapa lama durasinya
Jika harus memvakum tabel secara manual, pastikan Anda bisa menentukan apakah autovacuum saat ini sedang berjalan atau tidak. Jika sudah berjalan, Anda mungkin perlu menyesuaikan parameter agar berjalan lebih efisien, atau mematikan autovacuum sementara sehingga Anda dapat menjalankan VACUUM secara manual.
Gunakan kueri berikut untuk menentukan apakah autovacuum berjalan, berapa lama sudah berjalan, dan apakah sedang menunggu sesi lainnya atau tidak.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Setelah menjalankan kueri, Anda akan melihat hasil yang serupa dengan yang berikut ini.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Beberapa masalah dapat menyebabkan sesi autovacuum yang lama (yaitu beberapa hari). Masalah yang paling umum adalah nilai parameter [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) Anda diatur terlalu rendah untuk ukuran tabel atau laju pembaruan.
Sebaiknya Anda menggunakan rumus berikut untuk menetapkan nilai parameter `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Sesi autovacuum yang singkat juga dapat mengindikasikan adanya masalah:
+ Sesi ini dapat mengindikasikan bahwa `autovacuum_max_workers` tidak cukup untuk beban kerja Anda. Dalam hal ini, Anda perlu menetapkan jumlah pekerja.
+ Itu dapat mengindikasikan adanya kerusakan indeks (kesalahan pada autovacuum dan mulai ulang di hal yang sama, tetapi tidak ada kemajuan). Dalam hal ini, jalankan `vacuum freeze verbose table` manual untuk mengetahui penyebab pastinya.
# Melakukan pembekuan vakum manual
Anda mungkin dapat melakukan vakum manual di tabel yang memiliki proses vakum yang sudah berjalan. Cara ini berguna jika Anda telah mengidentifikasi tabel dengan usia yang mendekati 2 miliar transaksi (atau di atas ambang batas yang Anda pantau).
Langkah-langkah berikut ini merupakan panduan, yang disertai dengan beberapa variasi proses. Misalnya, selama pengujian, anggaplah Anda menemukan bahwa nilai parameter [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) diatur terlalu kecil dan Anda harus segera mengambil tindakan di tabel. Namun, mungkin pada saat ini Anda tidak ingin mengembalikan instans. Dengan menggunakan kueri di bagian sebelumnya, Anda dapat menentukan tabel mana yang menjadi masalah dan melihat sesi autovacuum yang berjalan lama. Anda tahu bahwa Anda perlu mengubah pengaturan parameter `maintenance_work_mem`, tetapi Anda juga harus mengambil tindakan cepat dan memvakum tabel yang dimaksud. Prosedur berikut menunjukkan tindakan apa yang harus dilakukan dalam situasi ini.
**Untuk melakukan pembekuan vakum secara manual**
1. Buka dua sesi ke basis data yang berisi tabel yang ingin divakum. Untuk sesi kedua, gunakan "layar" atau peralatan lain yang dapat mempertahankan sesi jika koneksi terputus.
1. Dalam sesi pertama, dapatkan ID proses (PID) dari sesi autovacuum yang berjalan di tabel.
Jalankan kueri berikut untuk mendapatkan PID dari sesi autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Dalam sesi kedua, hitung jumlah memori yang Anda butuhkan untuk menjalankan operasi ini. Dalam contoh ini, kita akan menentukan bahwa kita mampu menggunakan memori hingga 2 GB untuk operasi ini sehingga kita menetapkan [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) untuk sesi saat ini hingga 2 GB.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Dalam sesi kedua, munculkan perintah `vacuum freeze verbose` untuk tabel. Pengaturan verbose berguna karena Anda tetap dapat melihat aktivitas pembekuan tersebut meskipun tidak ada laporan kemajuannya di PostgreSQL saat ini.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Dalam sesi satu, jika autovacuum memblokir sesi vakum, `pg_stat_activity` menunjukkan bahwa `T` menunggu adalah sesi vakum Anda. Dalam hal ini, akhiri proses autovacuum sebagai berikut.
```
SELECT pg_terminate_backend('the_pid');
```
**catatan**
Beberapa versi Amazon RDS Aurora yang lebih rendah tidak dapat menghentikan proses autovacuum menggunakan perintah sebelumnya dan gagal dengan kesalahan berikut:. `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`
Di titik ini, sesi Anda dimulai. Autovacuum restart segera karena tabel ini mungkin yang tertinggi dalam daftar pekerjaannya.
1. Mulai perintah `vacuum freeze verbose` di sesi kedua, lalu akhiri proses autovacuum di sesi pertama.
# Mengindeks ulang tabel saat autovacuum berjalan
Jika indeks rusak, autovacuum tetap akan terus memproses tabel lalu gagal. Jika mencoba vakum manual dalam situasi ini, Anda akan menerima pesan kesalahan seperti berikut ini.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Saat indeks rusak dan autovacuum mencoba untuk tetap berjalan di tabel, maka Anda bersaing dengan sesi autovacuum yang sudah berjalan. Jika Anda mengeluarkan perintah “[REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html)“, kunci eksklusif akan diambil di tabel. Operasi penulisan, dan juga operasi membaca yang menggunakan indeks spesifik tersebut, akan diblokir.
**Untuk mengindeks ulang tabel saat autovacuum berjalan di tabel**
1. Buka dua sesi ke basis data yang berisi tabel yang ingin divakum. Untuk sesi kedua, gunakan "layar" atau peralatan lain yang dapat mempertahankan sesi jika koneksi terputus.
1. Dalam sesi pertama, dapatkan PID dari sesi autovacuum yang berjalan di tabel.
Jalankan kueri berikut untuk mendapatkan PID dari sesi autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Dalam sesi kedua, munculkan perintah pengindeksan ulang.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Dalam sesi pertama, jika autovacuum memblokir proses, Anda akan melihat di `pg_stat_activity` bahwa proses menunggu untuk sesi vakum diberi tanda "T". Dalam hal ini, Anda mengakhiri proses autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
Di titik ini, sesi Anda dimulai. Perlu diperhatikan bahwa proses autovacuum akan segera dimulai ulang karena tabel ini mungkin merupakan urutan tertinggi di daftar pekerjaan.
1. Mulai perintah Anda di sesi kedua, lalu akhiri proses autovacuum di sesi 1.
# Mengelola autovacuum dengan indeks berukuran besar
Sebagai bagian dari operasinya, *autovacuum* akan melakukan beberapa [fase vakum](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) saat berjalan di tabel. Sebelum tabel dibersihkan, semua indeksnya akan divakum terlebih dahulu. Fase menghapus beberapa indeks berukuran besar akan menghabiskan banyak waktu dan sumber daya. Oleh karena itu, sebagai praktik terbaik, pastikan Anda mengontrol jumlah indeks di tabel dan menyingkirkan indeks yang tidak digunakan.
Untuk proses ini, pertama-tama periksa ukuran indeks keseluruhan. Kemudian, tentukan apakah ada indeks yang berpotensi tidak digunakan dan dapat dihapus seperti yang ditunjukkan dalam contoh berikut.
**Untuk memeriksa ukuran tabel beserta indeksnya**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
Dalam contoh ini, ukuran indeks lebih besar dari tabel. Perbedaan ini dapat menyebabkan masalah performa karena indeks membengkak atau tidak digunakan sehingga berdampak pada operasi autovacuum serta operasi penyisipan.
**Untuk memeriksa indeks yang tidak digunakan**
Dengan menggunakan tampilan [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), Anda dapat memeriksa seberapa sering indeks digunakan dengan kolom `idx_scan`. Dalam contoh berikut, indeks yang tidak digunakan memiliki nilai `idx_scan` dari `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**catatan**
Statistik ini bersifat inkremental sejak statistik diatur ulang. Misalkan Anda memiliki indeks yang hanya digunakan pada akhir kuartal bisnis atau hanya untuk laporan tertentu. Ada kemungkinan bahwa indeks ini belum digunakan sejak statistik diatur ulang. Untuk informasi selengkapnya, lihat [Fungsi Statistik](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS). Indeks yang digunakan untuk menerapkan keunikan tidak akan memiliki pemindaian yang dilakukan dan tidak boleh diidentifikasi sebagai indeks yang tidak digunakan. Untuk mengidentifikasi indeks yang tidak digunakan, Anda harus memiliki pengetahuan mendalam tentang aplikasi dan pertanyaannya.
Untuk memeriksa kapan statistik terakhir basis data disetel ulang, gunakan [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Melakukan vakum di tabel secepat mungkin
**RDS untuk PostgreSQL 12 dan versi lebih tinggi**
Jika Anda memiliki terlalu banyak indeks dalam tabel besar, instans DB Anda mungkin mendekati penyelesaian ID transaksi (XID), yaitu saat penghitung XID mendekati nol. Jika tidak terkendali, situasi ini dapat mengakibatkan kehilangan data. Namun, Anda dapat dengan cepat melakuan vakum di tabel tanpa harus membersihkan indeks. Dalam RDS untuk PostgreSQL 12 dan versi lebih tinggi, Anda dapat menggunakan VACUUM dengan klausa [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Jika sesi autovacuum sudah berjalan, Anda harus menghentikannya agar dapat memulai VACUUM manual. Untuk informasi cara melakukan pembekuan vakum manual, lihat [Melakukan pembekuan vakum manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**catatan**
Melewatkan pembersihan indeks secara teratur menyebabkan indeks kembung, yang menurunkan kinerja pemindaian. Indeks mempertahankan baris mati, dan tabel mempertahankan pointer garis mati. Akibatnya, `pg_stat_all_tables.n_dead_tup` meningkat hingga autovacuum atau VACUUM manual dengan pembersihan indeks berjalan. Sebagai praktik terbaik, gunakan prosedur ini hanya untuk mencegah pembungkus ID transaksi.
**RDS untuk PostgreSQL 11 dan versi lama**
Namun, dalam RDS untuk PostgreSQL 11 dan versi lama, satu-satunya cara agar vakum dapat selesai lebih cepat adalah dengan mengurangi jumlah indeks di tabel. Menghapus sementara indeks dapat memengaruhi rencana kueri. Sebaiknya Anda menghapus sementara indeks yang tidak digunakan terlebih dahulu, lalu menghapus sementara indeks saat penyelesaian XID sangat dekat. Setelah proses vakum selesai, Anda dapat membuat ulang indeks ini.
# Parameter lain yang memengaruhi autovacuum
Kueri berikut menunjukkan nilai dari beberapa parameter yang secara langsung memengaruhi autovacuum dan perilakunya. [Parameter autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) dijelaskan dengan lengkap dalam dokumentasi PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Meskipun semua ini memengaruhi autovacuum, beberapa hal yang paling penting adalah:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Mengatur parameter autovacuum tingkat tabel
Anda dapat mengatur [parameter penyimpanan](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) terkait autovacuum di tingkat tabel, dan biasanya cara ini bisa lebih baik daripada harus mengubah perilaku seluruh basis data. Untuk tabel besar, Anda mungkin perlu mengatur pengaturan yang agresif dan tidak ingin membuat autovacuum berperilaku seperti itu untuk semua tabel.
Kueri berikut menunjukkan tabel mana yang saat ini memiliki opsi tingkat tabel.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Pengaturan ini mungkin berguna pada tabel yang jauh lebih besar daripada tabel lainnya, misalnya. Misalkan Anda memiliki satu tabel berukuran 300 GB dan 30 table lainnya berukuran kurang dari 1 GB. Dalam hal ini, Anda dapat mengatur beberapa parameter khusus untuk tabel besar sehingga tidak perlu mengubah perilaku dari seluruh sistem.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Melakukan tindakan ini akan menonaktifkan penundaan autovacuum berbasis biaya untuk tabel ini dengan mengorbankan lebih banyak penggunaan sumber daya di sistem Anda. Biasanya, jeda autovacuum untuk `autovacuum_vacuum_cost_delay` setiap kali `autovacuum_cost_limit` tercapai. Untuk mengetahui detail selengkapnya, lihat dokumentasi PostgreSQL tentang [pemvakuman berbasis biaya](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Melakukan log aktivitas autovacuum dan vakum
Informasi mengenai aktivitas autovacuum dikirim ke `postgresql.log` berdasarkan level yang ditentukan dalam parameter `rds.force_autovacuum_logging_level`. Berikut ini adalah nilai yang diizinkan untuk parameter ini dan versi PostgreSQL dengan nilai berupa pengaturan default:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 dan versi lebih tinggi)
+ `error`, log `fatal`, `panic`
`rds.force_autovacuum_logging_level` berfungsi dengan parameter `log_autovacuum_min_duration`. Nilai parameter `log_autovacuum_min_duration` adalah ambang batas (dalam milidetik) tempat tindakan autovacuum dicatat. Pengaturan `-1` tidak mencatat apa pun, sedangkan pengaturan 0 mencatat semua tindakan. Seperti halnya`rds.force_autovacuum_logging_level`, nilai default untuk `log_autovacuum_min_duration` bergantung pada versi, sebagai berikut:
+ `10000 ms` – PostgreSQL 14, PostgreSQL 13, PostgreSQL 12, dan PostgreSQL 11
+ `(empty)` – Tidak ada nilai default untuk PostgreSQL 10 dan PostgreSQL 9.6
Sebaiknya Anda mengatur `rds.force_autovacuum_logging_level` ke `WARNING`. Sebaiknya Anda juga mengatur `log_autovacuum_min_duration` ke nilai dari 1000 hingga 5000. Pengaturan aktivitas 5000 log yang membutuhkan waktu lebih dari 5.000 milidetik. Pengaturan apa pun selain -1 juga akan mencatat pesan jika tindakan autovacuum dilewati karena kunci yang bertentangan atau hubungan yang dihapus sementara secara bersamaan. Untuk informasi selengkapnya, lihat [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) dalam dokumentasi PostgreSQL.
Untuk memecahkan masalah, Anda dapat mengubah parameter `rds.force_autovacuum_logging_level` ke salah satu level debug, dari `debug1` hingga `debug5` untuk informasi panjang. Sebaiknya Anda menggunakan pengaturan debug untuk jangka waktu singkat dan hanya untuk tujuan pemecahan masalah. Untuk mempelajari selengkapnya, lihat [When to log](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) dalam dokumentasi PostgreSQL.
**catatan**
PostgreSQL memungkinkan akun `rds_superuser` untuk melihat sesi autovacuum di `pg_stat_activity`. Misalnya, Anda dapat mengidentifikasi dan mengakhiri sesi autovacuum yang memblokintah agar tidak berjalan, atau berjalan lebih lambat daripada perintah vakum yang dikeluarkan secara manual.
# Memahami perilaku autovacuum dengan database yang tidak valid
Nilai `-2` baru diperkenalkan ke `datconnlimit` kolom dalam `pg_database` katalog untuk menunjukkan database yang telah terputus di tengah operasi DROP DATABASE sebagai tidak valid.
Nilai baru ini tersedia dari
+ 15.4 dan semua versi yang lebih tinggi
+ 14.9 dan versi yang lebih tinggi
+ 13.12 dan versi yang lebih tinggi
+ 12.16 dan versi yang lebih tinggi
+ 11.21 dan versi yang lebih tinggi
Database yang tidak valid tidak memengaruhi kemampuan autovacuum untuk membekukan fungsionalitas untuk database yang valid. Autovacuum mengabaikan database yang tidak valid. Akibatnya, operasi vakum reguler akan terus berfungsi dengan baik dan efisien untuk semua database yang valid di lingkungan PostgreSQL Anda.
**Topics**
+ [Memantau ID transaksi](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [Menyesuaikan kueri pemantauan](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [Menyelesaikan masalah database yang tidak valid](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Memantau ID transaksi
`age(datfrozenxid)`Fungsi ini biasa digunakan untuk memantau usia transaksi ID (XID) database untuk mencegah pembungkus ID transaksi.
Karena database yang tidak valid dikecualikan dari autovacuum, penghitung ID transaksi (XID) mereka dapat mencapai nilai maksimum`2 billion`, membungkus, dan melanjutkan siklus ini tanpa batas waktu. `- 2 billion` Kueri khas untuk memantau sampul ID Transaksi mungkin terlihat seperti:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Namun, dengan diperkenalkannya nilai -2 untuk`datconnlimit`, database yang tidak valid dapat memiringkan hasil kueri ini. Karena database ini tidak valid dan tidak boleh menjadi bagian dari pemeriksaan pemeliharaan rutin, mereka dapat menyebabkan positif palsu, membuat Anda percaya bahwa `age(datfrozenxid)` itu lebih tinggi daripada yang sebenarnya.
## Menyesuaikan kueri pemantauan
Untuk memastikan pemantauan yang akurat, Anda harus menyesuaikan kueri pemantauan untuk mengecualikan database yang tidak valid. Ikuti kueri yang disarankan ini:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Kueri ini memastikan bahwa hanya database yang valid yang dipertimbangkan dalam `age(datfrozenxid)` perhitungan, memberikan refleksi sebenarnya dari usia ID transaksi di seluruh lingkungan PostgreSQL Anda.
## Menyelesaikan masalah database yang tidak valid
Saat mencoba menyambung ke database yang tidak valid, Anda mungkin menemukan pesan galat yang mirip dengan berikut ini:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Selain itu, jika `log_min_messages` parameter disetel ke `DEBUG2` atau lebih tinggi, Anda mungkin melihat entri log berikut yang menunjukkan bahwa proses autovacuum melewatkan database yang tidak valid:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Untuk mengatasi masalah ini, ikuti yang `HINT` disediakan selama upaya koneksi. Connect ke database yang valid menggunakan akun master RDS Anda atau akun database dengan `rds_superuser` peran tersebut, dan jatuhkan database yang tidak valid.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
#
[Di PostgreSQL, menyedot debu sangat penting untuk memastikan kesehatan database karena merebut kembali penyimpanan dan mencegah masalah pembungkus ID transaksi.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) Namun, ada kalanya penyedot debu dapat dicegah agar tidak beroperasi seperti yang diinginkan, yang dapat mengakibatkan penurunan kinerja, pembengkakan penyimpanan, dan bahkan memengaruhi ketersediaan instans DB Anda dengan sampul ID transaksi. Oleh karena itu, mengidentifikasi dan menyelesaikan masalah ini sangat penting untuk kinerja dan ketersediaan database yang optimal. Baca [Memahami autovacuum di Amazon RDS untuk lingkungan PostgreSQL untuk](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) mempelajari lebih lanjut tentang autovacuum.
`postgres_get_av_diag()`Fungsi ini membantu mengidentifikasi masalah yang mencegah atau menunda kemajuan vakum yang agresif. Saran disediakan, yang mungkin termasuk perintah untuk menyelesaikan masalah yang dapat diidentifikasi atau panduan untuk diagnostik lebih lanjut di mana masalah tidak dapat diidentifikasi. Penghambat vakum agresif dilaporkan ketika usia melebihi ambang batas [autovacuum adaptif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) RDS sebesar 500 juta transaksi. IDs
**Berapa usia ID transaksi?**
`age()`Fungsi untuk transaksi IDs menghitung jumlah transaksi yang telah terjadi sejak ID transaksi yang tidak dibekukan tertua untuk database (`pg_database.datfrozenxid`) atau tabel (`pg_class.relfrozenxid`). Nilai ini menunjukkan aktivitas database sejak operasi vakum agresif terakhir dan menyoroti kemungkinan beban kerja untuk proses VACUUM yang akan datang.
**Apa itu vakum agresif?**
Operasi VACUUM yang agresif melakukan pemindaian komprehensif semua halaman dalam tabel, termasuk yang biasanya dilewati selama reguler. VACUUMs Pemindaian menyeluruh ini bertujuan untuk “membekukan” transaksi IDs mendekati usia maksimum mereka, secara efektif mencegah situasi yang dikenal sebagai [sampul ID transaksi](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
`postgres_get_av_diag()`Untuk melaporkan pemblokir, pemblokir harus berusia setidaknya 500 juta transaksi.
**Topics**
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
#
`postgres_get_av_diag()`Fungsi ini saat ini tersedia dalam RDS berikut untuk PostgreSQL Aurora PostgreSQL versi :
+ 17.2 dan versi 17 yang lebih tinggi
+ 16.7 dan versi 16 yang lebih tinggi
+ 15.11 dan versi 15 yang lebih tinggi
+ 14.16 dan versi 14 yang lebih tinggi
+ 13.19 dan 13 versi yang lebih tinggi
Untuk menggunakan`postgres_get_av_diag()`, buat `rds_tools` ekstensi.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Verifikasi bahwa ekstensi diinstal.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Verifikasi bahwa fungsi tersebut dibuat.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
#
`postgres_get_av_diag()` Kueri harus dieksekusi dalam database dengan ID transaksi tertua untuk hasil yang akurat. Untuk informasi selengkapnya tentang menggunakan database dengan ID transaksi tertua, lihat [Tidak terhubung ke database dengan usia ID transaksi terlama](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
`postgres_get_av_diag()`Fungsi mengembalikan tabel dengan informasi berikut:
**pemblokir**
Menentukan kategori aktivitas database yang memblokir vakum.
+ [Pernyataan aktif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Idle pada transaksi](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaksi yang disiapkan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot replikasi logis](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Baca replika dengan slot replikasi fisik](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Baca replika dengan replikasi streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabel sementara](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**basis data**
Menentukan nama database jika berlaku dan didukung. Ini adalah database di mana aktivitas sedang berlangsung dan memblokir atau akan memblokir autovacuum. Ini adalah database yang harus Anda sambungkan dan ambil tindakan.
**blocker\$1identifier**
Menentukan pengenal aktivitas yang memblokir atau akan memblokir autovacuum. Pengidentifikasi dapat berupa ID proses bersama dengan pernyataan SQL, transaksi yang disiapkan, alamat IP replika baca, dan nama slot replikasi, baik logis atau fisik.
**wait\$1event**
Menentukan [acara tunggu acara](PostgreSQL.Tuning.md) sesi pemblokiran dan berlaku untuk blocker berikut:
+ Pernyataan aktif
+ Idle pada transaksi
**autovacum\$1lagging\$1by**
Menentukan jumlah transaksi yang autovacuum tertinggal dalam pekerjaan backlog-nya per kategori.
**saran**
Menentukan saran untuk menyelesaikan blocker. Instruksi ini mencakup nama database tempat aktivitas ada jika berlaku, ID Proses (PID) sesi jika berlaku, dan tindakan yang akan diambil.
**suggested\$1action**
Menyarankan tindakan yang perlu diambil untuk menyelesaikan pemblokir.
#
Autovacuum melakukan penyedot debu agresif dan menurunkan usia transaksi IDs hingga di bawah ambang batas yang ditentukan oleh parameter instans RDS Anda. `autovacuum_freeze_max_age` Anda dapat melacak usia ini menggunakan CloudWatch metrik Amazon`MaximumUsedTransactionIDs`.
Untuk menemukan pengaturan `autovacuum_freeze_max_age` (yang memiliki default 200 juta transaksi IDs) untuk instans Amazon RDS Anda, Anda dapat menggunakan kueri berikut:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Perhatikan bahwa `postgres_get_av_diag()` hanya memeriksa penghambat vakum agresif ketika usia melebihi ambang batas [autovacuum adaptif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) Amazon RDS sebesar 500 juta transaksi. IDs `postgres_get_av_diag()`Untuk mendeteksi pemblokir, pemblokir harus berusia setidaknya 500 juta transaksi.
`postgres_get_av_diag()`Fungsi ini mengidentifikasi jenis blocker berikut:
**Topics**
+ [Pernyataan aktif](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Idle pada transaksi](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaksi yang disiapkan](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot replikasi logis](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Replika baca](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabel sementara](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Pernyataan aktif
Dalam PostgreSQL, pernyataan aktif adalah pernyataan SQL yang saat ini sedang dijalankan oleh database. Ini termasuk kueri, transaksi, atau operasi apa pun yang sedang berlangsung. Saat memantau via`pg_stat_activity`, kolom status menunjukkan bahwa proses dengan PID yang sesuai aktif.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi pernyataan yang merupakan pernyataan aktif.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Tindakan yang disarankan**
Mengikuti panduan di `suggestion` kolom, pengguna dapat terhubung ke database di mana pernyataan aktif hadir dan, seperti yang ditentukan dalam `suggested_action` kolom, disarankan untuk hati-hati meninjau opsi untuk mengakhiri sesi. Jika penghentian aman, Anda dapat menggunakan `pg_terminate_backend()` fungsi untuk mengakhiri sesi. Tindakan ini dapat dilakukan oleh administrator (seperti akun master RDS) atau pengguna dengan `pg_terminate_backend()` hak istimewa yang diperlukan.
**Awas**
Sesi yang dihentikan akan membatalkan (`ROLLBACK`) perubahan yang dibuatnya. Tergantung pada kebutuhan Anda, Anda mungkin ingin menjalankan kembali pernyataan tersebut. Namun, disarankan untuk melakukannya hanya setelah proses autovacuum menyelesaikan operasi vakum agresifnya.
## Idle pada transaksi
Pernyataan transaksi yang menganggur mengacu pada setiap sesi yang telah membuka transaksi eksplisit (seperti dengan mengeluarkan `BEGIN` pernyataan), melakukan beberapa pekerjaan, dan sekarang menunggu klien untuk melewati lebih banyak pekerjaan atau memberi sinyal akhir transaksi dengan mengeluarkan`COMMIT`,`ROLLBACK`, atau `END` (yang akan menghasilkan implisit). `COMMIT`
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi `idle in transaction` pernyataan sebagai pemblokir.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Tindakan yang disarankan**
Seperti yang ditunjukkan dalam `suggestion` kolom, Anda dapat terhubung ke database tempat idle dalam sesi transaksi hadir dan mengakhiri sesi menggunakan fungsi. `pg_terminate_backend()` Pengguna dapat menjadi pengguna admin Anda (akun master RDS) atau pengguna dengan `pg_terminate_backend()` hak istimewa.
**Awas**
Sesi yang dihentikan akan membatalkan (`ROLLBACK`) perubahan yang dibuatnya. Tergantung pada kebutuhan Anda, Anda mungkin ingin menjalankan kembali pernyataan tersebut. Namun, disarankan untuk melakukannya hanya setelah proses autovacuum menyelesaikan operasi vakum agresifnya.
## Transaksi yang disiapkan
[PostgreSQL memungkinkan transaksi yang merupakan bagian dari strategi komit dua fase yang disebut transaksi siap.](https://www.postgresql.org/docs/current/sql-prepare-transaction.html) Ini diaktifkan dengan mengatur `max_prepared_transactions` parameter ke nilai bukan nol. Transaksi yang disiapkan dirancang untuk memastikan bahwa transaksi tahan lama dan tetap tersedia bahkan setelah database crash, restart, atau pemutusan klien. Seperti transaksi reguler, mereka diberi ID transaksi dan dapat memengaruhi autovacuum. Jika dibiarkan dalam keadaan siap, autovacuum tidak dapat melakukan freeezing dan dapat menyebabkan penutupan ID transaksi.
Ketika transaksi dibiarkan dipersiapkan tanpa batas waktu tanpa diselesaikan oleh manajer transaksi, mereka menjadi transaksi yang disiapkan yatim piatu. Satu-satunya cara untuk memperbaikinya adalah dengan melakukan atau mengembalikan transaksi menggunakan `ROLLBACK PREPARED` perintah `COMMIT PREPARED` atau, masing-masing.
**catatan**
Ketahuilah bahwa cadangan yang diambil selama transaksi yang disiapkan akan tetap berisi transaksi tersebut setelah restorasi. Lihat informasi berikut tentang cara menemukan dan menutup transaksi tersebut.
`postgres_get_av_diag()`Fungsi ini menampilkan output berikut ketika mengidentifikasi pemblokir yang merupakan transaksi yang disiapkan.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Tindakan yang disarankan**
Seperti disebutkan di kolom saran, sambungkan ke database tempat transaksi yang disiapkan berada. Berdasarkan `suggested_action` kolom, hati-hati meninjau apakah akan melakukan salah satu `COMMIT` atau`ROLLBACK`, dan menyetujui tindakan.
Untuk memantau transaksi yang disiapkan secara umum, PostgreSQL menawarkan tampilan katalog yang disebut. `pg_prepared_xacts` Anda dapat menggunakan kueri berikut untuk menemukan transaksi yang disiapkan.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Slot replikasi logis
Tujuan dari slot replikasi adalah untuk menahan perubahan yang tidak dikonsumsi sampai mereka direplikasi ke server target. [Untuk informasi lebih lanjut, lihat Replikasi Logis PostgreSQL.](https://www.postgresql.org/docs/current/logical-replication.html)
Ada dua jenis slot replikasi logis.
**Slot replikasi logis tidak aktif**
Ketika replikasi dihentikan, log transaksi yang tidak dikonsumsi tidak dapat dihapus, dan slot replikasi menjadi tidak aktif. Meskipun slot replikasi logis yang tidak aktif saat ini tidak digunakan oleh pelanggan, itu tetap di server, yang mengarah ke retensi file WAL dan mencegah penghapusan log transaksi lama. Ini dapat meningkatkan penggunaan disk dan secara khusus memblokir autovacuum dari membersihkan tabel katalog internal, karena sistem harus menjaga informasi LSN agar tidak ditimpa. Jika tidak ditangani, hal ini dapat mengakibatkan kembung katalog, penurunan kinerja, dan peningkatan risiko kekosongan sampul, yang berpotensi menyebabkan downtime transaksi.
**Slot replikasi logis aktif tapi lambat**
Terkadang penghapusan tupel mati katalog tertunda karena penurunan kinerja replikasi logis. Keterlambatan replikasi ini memperlambat pembaruan `catalog_xmin` dan dapat menyebabkan katalog kembung dan vakum sampul.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan slot replikasi logis sebagai pemblokir.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Tindakan yang disarankan**
Untuk mengatasi masalah ini, periksa konfigurasi replikasi untuk masalah dengan skema target atau data yang mungkin menghentikan proses penerapan. Alasan paling umum adalah sebagai berikut:
+ Kolom hilang
+ Tipe data yang tidak kompatibel
+ Ketidakcocokan data
+ Tabel hilang
Jika masalah terkait dengan masalah infrastruktur:
+ Masalah jaringan - [Bagaimana cara mengatasi masalah dengan Amazon RDS DB dalam status jaringan yang tidak kompatibel?](https://repost.aws/knowledge-center/rds-incompatible-network) .
+ Database atau instans DB tidak tersedia karena alasan berikut:
+ Instans replika kehabisan penyimpanan - Tinjau [instans Amazon RDS DB kehabisan penyimpanan](https://repost.aws/knowledge-center/rds-out-of-storage) untuk informasi tentang menambahkan penyimpanan.
+ Parameter Tidak Kompatibel - Tinjau [Bagaimana cara memperbaiki instans Amazon RDS DB yang macet dalam status parameter yang tidak kompatibel?](https://repost.aws/knowledge-center/rds-incompatible-parameters) untuk informasi lebih lanjut tentang bagaimana Anda dapat menyelesaikan masalah.
Jika instans Anda berada di luar AWS jaringan atau aktif AWS EC2, konsultasikan dengan administrator Anda tentang cara mengatasi masalah ketersediaan atau terkait infrastruktur.
**Menjatuhkan slot yang tidak aktif**
**Awas**
Perhatian: Sebelum menjatuhkan slot replikasi, pastikan dengan hati-hati bahwa ia tidak memiliki replikasi yang sedang berlangsung, tidak aktif, dan dalam keadaan tidak dapat dipulihkan. Menjatuhkan slot sebelum waktunya dapat mengganggu replikasi atau menyebabkan kehilangan data.
Setelah memastikan bahwa slot replikasi tidak lagi diperlukan, jatuhkan untuk memungkinkan autovacuum melanjutkan. Kondisi ini `active = 'f'` memastikan bahwa hanya slot yang tidak aktif yang dijatuhkan.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Replika baca
Saat `hot_standby_feedback` pengaturan diaktifkan untuk [replika baca Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), pengaturan ini mencegah autovacuum pada database utama menghapus baris mati yang mungkin masih diperlukan oleh kueri yang berjalan pada replika baca. Ini mempengaruhi semua jenis replika baca fisik termasuk yang dikelola dengan atau tanpa slot replikasi. Perilaku ini diperlukan karena kueri yang berjalan pada replika siaga mengharuskan baris tersebut tetap tersedia di primer yang mencegah [konflik dan pembatalan kueri](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT).
**Baca replika dengan slot replikasi fisik**
Slot ini memastikan database utama menyimpan file Write-Ahead Log penting sampai replika memprosesnya, menjaga konsistensi data bahkan selama gangguan jaringan.
Dimulai dengan RDS untuk PostgreSQL , semua replika menggunakan slot replikasi. Pada versi sebelumnya, hanya replika lintas wilayah yang menggunakan slot replikasi.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan replika baca dengan slot replikasi fisik sebagai pemblokir.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Baca replika dengan replikasi streaming**
Amazon RDS memungkinkan pengaturan replika baca tanpa slot replikasi fisik di versi yang lebih lama, hingga versi 13. Pendekatan ini mengurangi overhead dengan memungkinkan primer untuk mendaur ulang file WAL lebih agresif, yang menguntungkan di lingkungan dengan ruang disk terbatas dan dapat mentolerir sesekali. ReplicaLag Namun, tanpa slot, siaga harus tetap sinkron untuk menghindari file WAL yang hilang. Amazon RDS menggunakan file WAL yang diarsipkan untuk membantu replika catch up jika tertinggal, tetapi proses ini memerlukan pemantauan yang cermat dan bisa lambat.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan replika baca streaming sebagai pemblokir.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Tindakan yang disarankan**
Seperti yang direkomendasikan di `suggested_action` kolom, tinjau opsi ini dengan cermat untuk membuka blokir autovacuum.
+ **Mengakhiri kueri** — Mengikuti panduan di kolom saran, Anda dapat terhubung ke replika baca, seperti yang ditentukan dalam kolom suggested\$1action, disarankan untuk hati-hati meninjau opsi untuk mengakhiri sesi. Jika penghentian dianggap aman, Anda dapat menggunakan `pg_terminate_backend()` fungsi ini untuk mengakhiri sesi. Tindakan ini dapat dilakukan oleh administrator (seperti akun master RDS) atau pengguna dengan hak istimewa pg\$1terminate\$1backend () yang diperlukan.
Anda dapat menjalankan perintah SQL berikut pada replika baca untuk mengakhiri kueri yang mencegah vakum pada primer membersihkan baris lama. Nilai dilaporkan dalam output fungsi: `backend_xmin`
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Nonaktifkan umpan balik siaga panas** - Pertimbangkan untuk menonaktifkan `hot_standby_feedback` parameter jika menyebabkan penundaan vakum yang signifikan.
`hot_standby_feedback`Parameter ini memungkinkan replika baca untuk menginformasikan primer tentang aktivitas kuerinya, mencegah primer menyedot debu tabel atau baris yang digunakan pada siaga. Meskipun ini memastikan stabilitas kueri pada siaga, ini dapat secara signifikan menunda penyedotan debu pada primer. Menonaktifkan fitur ini memungkinkan primer untuk melanjutkan dengan menyedot debu tanpa menunggu siaga untuk mengejar ketinggalan. Namun, ini dapat menyebabkan pembatalan kueri atau kegagalan pada siaga jika mencoba mengakses baris yang telah disedot oleh primer.
+ **Hapus replika baca jika tidak diperlukan** — Jika replika baca tidak lagi diperlukan, Anda dapat menghapusnya. Ini akan menghapus overhead replikasi terkait dan memungkinkan primer untuk mendaur ulang log transaksi tanpa ditahan oleh replika.
## Tabel sementara
[Tabel sementara](https://www.postgresql.org/docs/current/sql-createtable.html), dibuat menggunakan `TEMPORARY` kata kunci, berada dalam skema temp, misalnya pg\$1temp\$1xxx, dan hanya dapat diakses oleh sesi yang membuatnya. Tabel sementara dijatuhkan saat sesi berakhir. Namun, tabel ini tidak terlihat oleh proses autovacuum PostgreSQL, dan harus disedot secara manual oleh sesi yang membuatnya. Mencoba menyedot tabel suhu dari sesi lain tidak berpengaruh.
Dalam keadaan yang tidak biasa, tabel sementara ada tanpa sesi aktif yang memilikinya. Jika sesi kepemilikan berakhir secara tak terduga karena kecelakaan fatal, masalah jaringan, atau peristiwa serupa, tabel sementara mungkin tidak dibersihkan, meninggalkannya sebagai tabel “yatim piatu”. Ketika proses autovacuum PostgreSQL mendeteksi tabel sementara yatim piatu, ia mencatat pesan berikut:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi tabel sementara sebagai pemblokir. Agar fungsi menampilkan output yang terkait dengan tabel sementara dengan benar, itu perlu dieksekusi dalam database yang sama di mana tabel tersebut ada.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Tindakan yang disarankan**
Ikuti instruksi yang diberikan di `suggestion` kolom output untuk mengidentifikasi dan menghapus tabel sementara yang mencegah autovacuum berjalan. Gunakan perintah berikut untuk menjatuhkan tabel sementara yang dilaporkan oleh`postgres_get_av_diag()`. Ganti nama tabel berdasarkan output yang disediakan oleh `postgres_get_av_diag()` fungsi.
```
DROP TABLE my_temp_schema.my_temp_table;
```
Kueri berikut dapat digunakan untuk mengidentifikasi tabel sementara:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
#
Bagian ini mengeksplorasi alasan tambahan yang dapat mencegah penyedot debu membuat kemajuan. Masalah-masalah ini saat ini tidak dapat diidentifikasi secara langsung oleh fungsi. `postgres_get_av_diag()`
**Topics**
+ [Halaman tidak valid](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Inkonsistensi indeks](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Tingkat transaksi yang sangat tinggi](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Halaman tidak valid
Kesalahan halaman yang tidak valid terjadi ketika PostgreSQL mendeteksi ketidakcocokan dalam checksum halaman saat mengakses halaman tersebut. Isinya tidak dapat dibaca, mencegah autovacuum membekukan tupel. Ini secara efektif menghentikan proses pembersihan. Kesalahan berikut ditulis ke dalam log PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Tentukan jenis objek**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
Dari pesan kesalahan, jalur `base/16403/186752608` memberikan informasi berikut:
+ “base” adalah nama direktori di bawah direktori data PostgreSQL.
+ “16403" adalah database OID, yang dapat Anda cari di katalog sistem. `pg_database`
+ “186752608" adalah`relfilenode`, yang dapat Anda gunakan untuk mencari skema dan nama objek dalam katalog sistem. `pg_class`
Dengan memeriksa output dari query berikut dalam database yang terkena dampak, Anda dapat menentukan jenis objek. Query berikut mengambil informasi objek untuk oid: 186752608. Ganti OID dengan yang relevan dengan kesalahan yang Anda temui.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Untuk informasi selengkapnya, lihat [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html)dokumentasi PostgreSQL untuk semua jenis objek yang didukung, yang dicatat oleh kolom di. `relkind` `pg_class`
**Bimbingan**
Solusi paling efektif untuk masalah ini bergantung pada konfigurasi instans Amazon RDS spesifik Anda dan jenis data yang dipengaruhi oleh halaman yang tidak konsisten.
**Jika jenis objek adalah indeks:**
Membangun kembali indeks direkomendasikan.
+ **Menggunakan `CONCURRENTLY` opsi** — Sebelum PostgreSQL versi 12, membangun kembali indeks memerlukan kunci tabel eksklusif, membatasi akses ke tabel. Dengan PostgreSQL versi 12, dan versi yang lebih baru, opsi `CONCURRENTLY` ini memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintah:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Meskipun `CONCURRENTLY` tidak terlalu mengganggu, itu bisa lebih lambat di meja yang sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan.
[Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL REINDEX.](https://www.postgresql.org/docs/current/sql-reindex.html)
+ **Menggunakan `INDEX_CLEANUP FALSE` opsi** — Jika indeksnya besar dan diperkirakan membutuhkan banyak waktu untuk menyelesaikannya, Anda dapat membuka blokir autovacuum dengan menjalankan manual sambil mengecualikan indeks. `VACUUM FREEZE` Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.
Melewati indeks akan memungkinkan Anda untuk melewati proses vakum dari indeks yang tidak konsisten dan mengurangi masalah sampul. Namun, ini tidak akan menyelesaikan masalah halaman tidak valid yang mendasarinya. Untuk sepenuhnya mengatasi dan menyelesaikan masalah halaman yang tidak valid, Anda masih perlu membangun kembali indeks.
**Jika jenis objek adalah tampilan terwujud:**
Jika terjadi kesalahan halaman yang tidak valid pada tampilan yang terwujud, masuk ke database yang terkena dampak dan segarkan untuk menyelesaikan halaman yang tidak valid:
Segarkan tampilan terwujud:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Jika penyegaran gagal, coba buat ulang:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Menyegarkan atau membuat ulang tampilan terwujud akan mengembalikannya tanpa memengaruhi data tabel yang mendasarinya.
**Untuk semua jenis objek lainnya:**
Untuk semua jenis objek lainnya, hubungi AWS dukungan.
## Inkonsistensi indeks
Indeks yang tidak konsisten secara logis dapat mencegah autovacuum membuat kemajuan. Kesalahan berikut atau kesalahan serupa dicatat selama fase vakum indeks atau ketika indeks diakses oleh pernyataan SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Bimbingan**
Bangun kembali indeks atau lewati indeks menggunakan manual`INDEX_CLEANUP`. `VACUUM FREEZE` Untuk informasi tentang cara membangun kembali indeks, lihat [Jika jenis objek adalah indeks](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Menggunakan opsi CONCURRENT** - Sebelum PostgreSQL versi 12, membangun kembali indeks memerlukan kunci tabel eksklusif, membatasi akses ke tabel. Dengan PostgreSQL versi 12, dan versi yang lebih baru, opsi CONCURRENT memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintah:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Sementara CONCURRENT kurang mengganggu, itu bisa lebih lambat pada tabel sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan. Untuk informasi selengkapnya, lihat [REINDEX dalam dokumentasi](https://www.postgresql.org/docs/current/sql-reindex.html) *PostgreSQL*.
+ **Menggunakan opsi INDEX\$1CLEANUP FALSE** — Jika indeksnya besar dan diperkirakan membutuhkan banyak waktu untuk menyelesaikannya, Anda dapat membuka blokir autovacuum dengan menjalankan VACUUM FREEZE manual sambil mengecualikan indeks. Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.
Melewati indeks akan memungkinkan Anda untuk melewati proses vakum dari indeks yang tidak konsisten dan mengurangi masalah sampul. Namun, ini tidak akan menyelesaikan masalah halaman tidak valid yang mendasarinya. Untuk sepenuhnya mengatasi dan menyelesaikan masalah halaman yang tidak valid, Anda masih perlu membangun kembali indeks.
## Tingkat transaksi yang sangat tinggi
Di PostgreSQL, tingkat transaksi yang tinggi dapat secara signifikan memengaruhi kinerja autovacuum, yang mengarah pada pembersihan tupel mati yang lebih lambat dan peningkatan risiko sampul ID transaksi. Anda dapat memantau tingkat transaksi dengan mengukur perbedaan `max(age(datfrozenxid))` antara dua periode waktu, biasanya per detik. Selain itu, Anda dapat menggunakan metrik penghitung berikut dari RDS Performance Insights untuk mengukur tingkat transaksi (jumlah xact\$1commit dan xact\$1rollback) yang merupakan jumlah total transaksi.
| Penghitung | Jenis | Unit | Metrik |
| --- | --- | --- | --- |
| xact\$1commit | Transaksi | Commit per detik | db.Transactions.xact\$1commit |
| xact\$1rollback | Transaksi | Pemulihan per detik | db.Transactions.xact\$1rollback |
Peningkatan yang cepat menunjukkan beban transaksi yang tinggi, yang dapat membanjiri autovacuum, menyebabkan kembung, perselisihan kunci, dan potensi masalah kinerja. Hal ini dapat berdampak negatif pada proses autovacuum dalam beberapa cara:
+ **Aktivitas Tabel:** Tabel spesifik yang disedot dapat mengalami volume transaksi yang tinggi, menyebabkan penundaan.
+ **Sistem Sumber Daya** Sistem secara keseluruhan mungkin kelebihan beban, sehingga sulit bagi autovacuum untuk mengakses sumber daya yang diperlukan agar berfungsi secara efisien.
Pertimbangkan strategi berikut untuk memungkinkan autovacuum beroperasi lebih efektif dan mengikuti tugasnya:
1. Kurangi tingkat transaksi jika memungkinkan. Pertimbangkan untuk mengelompokkan atau mengelompokkan transaksi serupa jika memungkinkan.
1. Targetkan tabel yang sering diperbarui dengan `VACUUM FREEZE` operasi manual setiap malam, mingguan, atau dua mingguan selama jam sibuk.
1. Pertimbangkan untuk meningkatkan kelas instans Anda untuk mengalokasikan lebih banyak sumber daya sistem untuk menangani volume transaksi dan autovacuum yang tinggi.
#
Bagian ini membahas faktor-faktor yang sering berkontribusi pada kinerja vakum yang lebih lambat dan bagaimana mengatasi masalah ini.
**Topics**
+ [Vakum indeks besar](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [Terlalu banyak tabel atau database untuk vakum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [Vakum agresif (untuk mencegah pembungkus) sedang berjalan](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vakum indeks besar
VACUUM beroperasi melalui fase berurutan: inisialisasi, pemindaian tumpukan, penyedot debu indeks dan tumpukan, pembersihan indeks, pemotongan tumpukan, dan pembersihan akhir. Selama pemindaian tumpukan, proses memangkas halaman, mendefragmen, dan membekukannya. Setelah menyelesaikan pemindaian heap, VACUUM membersihkan indeks, mengembalikan halaman kosong ke sistem operasi, dan melakukan tugas pembersihan akhir seperti menyedot debu peta ruang kosong dan memperbarui statistik.
Penyedot debu indeks mungkin memerlukan beberapa lintasan ketika `maintenance_work_mem` (atau`autovacuum_work_mem`) tidak cukup untuk memproses indeks. Di PostgreSQL 16 dan sebelumnya, batas memori 1 GB untuk menyimpan IDs tupel mati sering memaksa beberapa pass pada indeks besar. PostgreSQL 17 `TidStore` memperkenalkan, yang secara dinamis mengalokasikan memori alih-alih menggunakan array alokasi tunggal. Ini menghilangkan batasan 1 GB, menggunakan memori lebih efisien, dan mengurangi kebutuhan untuk beberapa pemindaian indeks per setiap indeks.
Indeks besar mungkin masih memerlukan beberapa pass di PostgreSQL 17 jika memori yang tersedia tidak dapat mengakomodasi seluruh pemrosesan indeks sekaligus. Biasanya, indeks yang lebih besar mengandung lebih banyak tupel mati yang membutuhkan banyak lintasan.
**Mendeteksi operasi vakum yang lambat**
`postgres_get_av_diag()`Fungsi ini dapat mendeteksi ketika operasi vakum berjalan lambat karena memori yang tidak mencukupi. Untuk informasi lebih lanjut tentang fungsi ini, lihat[](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
`postgres_get_av_diag()`Fungsi mengeluarkan pemberitahuan berikut ketika memori yang tersedia tidak cukup untuk menyelesaikan penyedot debu indeks dalam satu lintasan.
**`rds_tools`1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools`1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**catatan**
`postgres_get_av_diag()`Fungsi ini bergantung pada `pg_stat_all_tables.n_dead_tup` untuk memperkirakan jumlah memori yang diperlukan untuk penyedot debu indeks.
Ketika `postgres_get_av_diag()` fungsi mengidentifikasi operasi vakum lambat yang memerlukan beberapa pemindaian indeks karena tidak mencukupi`autovacuum_work_mem`, itu akan menghasilkan pesan berikut:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Bimbingan**
Anda dapat menerapkan solusi berikut menggunakan manual `VACUUM FREEZE` untuk mempercepat pembekuan tabel.
**Tingkatkan memori untuk menyedot debu**
Seperti yang disarankan oleh `postgres_get_av_diag()` fungsi, disarankan untuk meningkatkan `autovacuum_work_mem` parameter untuk mengatasi kendala memori potensial pada tingkat instance. Meskipun `autovacuum_work_mem` merupakan parameter dinamis, penting untuk dicatat bahwa agar pengaturan memori baru diterapkan, daemon autovacuum perlu me-restart pekerjanya. Untuk mencapai ini:
1. Konfirmasikan bahwa pengaturan baru sudah ada.
1. Hentikan proses yang saat ini menjalankan autovacuum.
Pendekatan ini memastikan bahwa alokasi memori yang disesuaikan diterapkan pada operasi autovacuum baru.
Untuk hasil yang lebih cepat, pertimbangkan untuk melakukan `VACUUM FREEZE` operasi secara manual dengan `maintenance_work_mem` pengaturan yang ditingkatkan dalam sesi Anda:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Jika Anda menggunakan Amazon RDS dan menemukan bahwa Anda memerlukan memori tambahan untuk mendukung nilai yang lebih tinggi untuk `maintenance_work_mem` atau`autovacuum_work_mem`, pertimbangkan untuk meningkatkan ke kelas instans dengan lebih banyak memori. Ini dapat menyediakan sumber daya yang diperlukan untuk meningkatkan operasi vakum manual dan otomatis, yang mengarah pada peningkatan kinerja vakum dan basis data secara keseluruhan.
**Nonaktifkan INDEX\$1CLEANUP**
Manual `VACUUM` di PostgreSQL versi 12 dan yang lebih baru memungkinkan melewatkan fase pembersihan indeks, sementara autovacuum darurat di PostgreSQL versi 14 dan yang lebih baru melakukan ini secara otomatis berdasarkan parameter. [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE)
**Awas**
Melewatkan pembersihan indeks dapat menyebabkan indeks kembung dan berdampak negatif pada kinerja kueri. Untuk mengurangi ini, pertimbangkan untuk mengindeks ulang atau menyedot debu indeks yang terpengaruh selama jendela pemeliharaan.
Untuk panduan tambahan tentang penanganan indeks besar, lihat dokumentasi di[Mengelola autovacuum dengan indeks berukuran besar](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Penyedot debu indeks paralel**
Dimulai dengan PostgreSQL 13, indeks dapat disedot dan dibersihkan secara paralel secara default menggunakan `VACUUM` manual, dengan satu proses vacuum worker ditetapkan untuk setiap indeks. Namun, untuk PostgreSQL untuk menentukan apakah operasi vakum memenuhi syarat untuk eksekusi paralel, kriteria khusus harus dipenuhi:
+ Setidaknya harus ada dua indeks.
+ `max_parallel_maintenance_workers`Parameter harus diatur ke setidaknya 2.
+ Ukuran indeks harus melebihi `min_parallel_index_scan_size` batas, yang defaultnya 512KB.
Anda dapat menyesuaikan `max_parallel_maintenance_workers` pengaturan berdasarkan jumlah v yang CPUs tersedia di instans Amazon RDS Anda dan jumlah indeks di atas meja untuk mengoptimalkan waktu penyelesaian vakum.
Untuk informasi selengkapnya, lihat [Penyedot debu paralel di Amazon RDS untuk PostgreSQL dan Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Terlalu banyak tabel atau database untuk vakum
Seperti disebutkan dalam dokumentasi [The Autovacuum Daemon PostgreSQL, daemon autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') beroperasi melalui beberapa proses. Ini termasuk peluncur autovacuum persisten yang bertanggung jawab untuk memulai proses pekerja autovacuum untuk setiap database dalam sistem. Peluncur menjadwalkan pekerja ini untuk memulai kira-kira setiap `autovacuum_naptime` detik per database.
Dengan database 'N', pekerja baru memulai kira-kira setiap [`autovacuum_naptime`/N detik]. Namun, jumlah total pekerja bersamaan dibatasi oleh `autovacuum_max_workers` pengaturan. Jika jumlah database atau tabel yang membutuhkan penyedot debu melebihi batas ini, database atau tabel berikutnya akan diproses segera setelah pekerja tersedia.
Ketika banyak tabel besar atau database memerlukan penyedot debu secara bersamaan, semua pekerja autovacuum yang tersedia dapat menjadi sibuk untuk durasi yang lama, menunda pemeliharaan pada tabel dan database lain. Di lingkungan dengan tingkat transaksi tinggi, kemacetan ini dapat dengan cepat meningkat dan berpotensi menyebabkan masalah vakum sampul dalam instans Amazon RDS Anda.
Ketika `postgres_get_av_diag()` mendeteksi sejumlah besar tabel atau database, ia memberikan rekomendasi berikut:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Bimbingan**
**Tingkatkan autovacuum\$1max\$1workers**
Untuk mempercepat penyedotan debu, kami sarankan untuk menyesuaikan `autovacuum_max_workers` parameter untuk memungkinkan lebih banyak pekerja autovacuum bersamaan. Jika kemacetan kinerja tetap ada, pertimbangkan untuk meningkatkan instans Amazon RDS Anda ke kelas dengan lebih banyak v, yang selanjutnya dapat meningkatkan kemampuan pemrosesan CPUs paralel.
## Vakum agresif (untuk mencegah pembungkus) sedang berjalan
Usia database (MaximumUsedTransactionIDs) di PostgreSQL hanya berkurang ketika vakum agresif (untuk mencegah sampul) berhasil diselesaikan. Sampai kekosongan ini selesai, usia akan terus meningkat tergantung pada tingkat transaksi.
`postgres_get_av_diag()`Fungsi ini menghasilkan yang berikut `NOTICE` ketika mendeteksi vakum yang agresif. Namun, itu hanya memicu output ini setelah vakum telah aktif setidaknya selama dua menit.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Untuk informasi lebih lanjut tentang vakum agresif, lihat [Saat vakum agresif sudah berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Anda dapat memverifikasi apakah vakum agresif sedang berlangsung dengan kueri berikut:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Anda dapat menentukan apakah itu vakum agresif (untuk mencegah sampul) dengan memeriksa kolom kueri di output. Ungkapan “untuk mencegah sampul” menunjukkan bahwa itu adalah kekosongan yang agresif.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Misalnya, Anda memiliki pemblokir pada usia transaksi 1 miliar dan tabel yang membutuhkan vakum agresif untuk mencegah pemblokiran pada usia transaksi yang sama. Selain itu, ada pemblokir lain pada usia transaksi 750 juta. Setelah menyelesaikan pemblokir pada usia transaksi 1 miliar, usia transaksi tidak akan langsung turun menjadi 750 juta. Ini akan tetap tinggi sampai tabel yang membutuhkan vakum agresif atau transaksi apa pun dengan usia di atas 750 juta selesai. Selama periode ini, usia transaksi klaster PostgreSQL Anda akan terus meningkat. Setelah proses vakum selesai, usia transaksi akan turun menjadi 750 juta tetapi akan mulai meningkat lagi hingga penyedotan lebih lanjut selesai. Siklus ini akan berlanjut selama kondisi ini tetap ada, hingga usia transaksi akhirnya turun ke level yang dikonfigurasi untuk instans Amazon RDS Anda, yang ditentukan oleh. `autovacuum_freeze_max_age`
#
`postgres_get_av_diag()`Fungsi ini menyediakan pesan PEMBERITAHUAN berikut:
**Ketika usia belum mencapai ambang pemantauan**
Ambang batas pemantauan `postgres_get_av_diag()` untuk mengidentifikasi pemblokir adalah 500 juta transaksi secara default. Jika `postgres_get_av_diag()` menghasilkan PEMBERITAHUAN berikut, ini menunjukkan bahwa usia transaksi belum mencapai ambang batas ini.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Tidak terhubung ke database dengan usia ID transaksi tertua**
`postgres_get_av_diag()`Fungsi ini memberikan output paling akurat saat terhubung ke database dengan usia ID transaksi tertua. Database dengan usia ID transaksi tertua yang dilaporkan oleh `postgres_get_av_diag()` akan berbeda dari “my\$1database” dalam kasus Anda. Jika Anda tidak terhubung ke database yang benar, PEMBERITAHUAN berikut akan dibuat:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Menghubungkan ke database dengan usia transaksi tertua penting karena alasan berikut:
+ **Mengidentifikasi pemblokir tabel sementara:** Karena metadata untuk tabel sementara khusus untuk setiap database, mereka biasanya ditemukan dalam database tempat mereka dibuat. Namun, jika tabel sementara kebetulan menjadi pemblokir teratas dan berada di database dengan transaksi tertua, ini bisa menyesatkan. Menghubungkan ke database yang benar memastikan identifikasi akurat dari pemblokir tabel sementara.
+ **Mendiagnosis vakum lambat:** Metadata indeks dan informasi jumlah tabel bersifat spesifik basis data dan diperlukan untuk mendiagnosis masalah vakum lambat.
**Database dengan transaksi tertua berdasarkan usia ada pada database rdsadmin atau template0**
Dalam kasus tertentu, `rdsadmin` atau `template0` database dapat diidentifikasi sebagai database dengan usia ID transaksi tertua. Jika ini terjadi, `postgres_get_av_diag()` akan mengeluarkan PEMBERITAHUAN berikut:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Verifikasi bahwa pemblokir yang terdaftar tidak berasal dari salah satu dari dua database ini. Jika pemblokir dilaporkan ada di salah satu `rdsadmin` atau`template0`, hubungi dukungan karena basis data ini tidak dapat diakses pengguna dan memerlukan intervensi.
Sangat tidak mungkin bagi `template0` database `rdsadmin` atau untuk berisi pemblokir teratas.
**Saat vakum agresif sudah berjalan**
`postgres_get_av_diag()`Fungsi ini dirancang untuk melaporkan ketika proses vakum agresif berjalan, tetapi hanya memicu keluaran ini setelah vakum aktif setidaknya selama 1 menit. Penundaan yang disengaja ini membantu mengurangi kemungkinan positif palsu. Dengan menunggu, fungsi memastikan bahwa hanya penyedot debu yang efektif dan signifikan yang dilaporkan, yang mengarah pada pemantauan aktivitas vakum yang lebih akurat dan andal.
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut ketika mendeteksi satu atau lebih vakum agresif yang sedang berlangsung.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Sebagaimana ditunjukkan dalam PEMBERITAHUAN, terus memantau kinerja vakum. Untuk informasi lebih lanjut tentang vakum agresif lihat [Vakum agresif (untuk mencegah pembungkus) sedang berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Saat autovacuum dimatikan**
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut jika autovacuum dinonaktifkan pada instance database Anda:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Autovacuum adalah fitur penting dari RDS Anda untuk PostgreSQL PostgreSQL PostgreSQL DB instance yang memastikan kelancaran operasi database. Ini secara otomatis menghapus versi baris lama, merebut kembali ruang penyimpanan, dan mencegah kembung tabel, membantu menjaga tabel dan indeks tetap efisien untuk kinerja optimal. Selain itu, ini melindungi terhadap sampul ID transaksi, yang dapat menghentikan transaksi di instans Amazon RDS Anda. Menonaktifkan autovacuum dapat menyebabkan penurunan jangka panjang dalam kinerja dan stabilitas database. Kami menyarankan Anda untuk tetap menggunakannya setiap saat.
Mematikan autovacuum tidak menghentikan penyedot debu agresif. Ini masih akan terjadi setelah tabel Anda mencapai `autovacuum_freeze_max_age` ambang batas.
**Jumlah transaksi yang tersisa sangat rendah**
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut ketika vakum sampul sudah dekat. PEMBERITAHUAN ini dikeluarkan ketika instans Amazon RDS Anda berjarak 100 juta transaksi dari kemungkinan menolak transaksi baru.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Tindakan segera Anda diperlukan untuk menghindari downtime database. Anda harus memonitor operasi penyedot debu Anda dan mempertimbangkan secara manual memulai database yang `VACUUM FREEZE` terpengaruh untuk mencegah kegagalan transaksi.
# Mengelola jumlah objek tinggi di Amazon RDS untuk PostgreSQL Amazon Aurora
Sementara keterbatasan PostgreSQL bersifat teoritis, memiliki jumlah objek yang sangat tinggi dalam database akan menyebabkan dampak kinerja yang nyata pada berbagai operasi. Dokumentasi ini mencakup beberapa jenis objek umum yang, ketika memiliki jumlah total yang tinggi dapat menyebabkan beberapa kemungkinan dampak.
Tabel berikut memberikan ringkasan jenis objek dan potensi dampaknya:
**Jenis objek dan dampak potensial**
| Jenis Objek | Autovacuum | Replikasi Logis | Upgrade Versi Utama | pg\$1dump/pg\$1restore | Kinerja Umum | Instans Mulai Ulang |
| --- | --- | --- | --- | --- | --- | --- |
| [Hubungan](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Tabel sementara](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tabel yang tidak tersumbat](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partisi](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [File sementara](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Urutan](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Benda besar](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Hubungan
Tidak ada batasan keras khusus mengenai jumlah tabel dalam database PostgreSQL. Batas teoritis sangat tinggi, tetapi ada batasan praktis lain yang perlu diingat selama desain database.
**Dampak: Autovacuum tertinggal**
Autovacuum dapat berjuang untuk mengikuti pertumbuhan ID transaksi atau kembung meja karena kurangnya pekerja dibandingkan dengan jumlah pekerjaan.
**Tindakan yang disarankan:** Ada beberapa faktor untuk menyetel autovacuum agar sesuai dengan jumlah tabel tertentu dan beban kerja yang diberikan. Lihat [Praktik terbaik untuk bekerja dengan PostgreSQL autovacuum Praktik terbaik untuk bekerja dengan PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) yang sesuai. Gunakan utilitas [postgres\$1get\$1av\$1diag utilitas ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) untuk memantau masalah dengan pertumbuhan ID transaksi.
**Dampak: Peningkatan versi utama/pg\$1dump dan pulihkan**
Amazon RDS menggunakan opsi “--link” selama eksekusi pg\$1upgrade untuk menghindari keharusan membuat salinan file data, metadata skema masih diperlukan untuk dikembalikan ke versi baru database. Bahkan dengan parallel pg\$1restore, jika ada sejumlah besar hubungan ini akan meningkatkan jumlah downtime.
**Dampak: Degradasi kinerja umum**
Degradasi kinerja umum karena ukuran katalog. Setiap tabel dan kolom terkait akan menambah`pg_attribute`, `pg_class` dan `pg_depend` tabel yang sering digunakan dalam operasi database normal. Tidak akan ada acara tunggu tertentu yang terlihat, tetapi efisiensi buffer bersama akan terpengaruh.
**Tindakan yang disarankan:** Periksa tabel kembung secara teratur untuk tabel spesifik ini dan sesekali lakukan a `VACUUM FULL` pada tabel tertentu ini. Ketahuilah bahwa `VACUUM FULL` pada tabel katalog memerlukan `ACCESS EXCLUSIVE` kunci yang berarti tidak ada kueri lain yang dapat mengaksesnya sampai operasi selesai.
**Dampak: Kelelahan deskriptor file**
Kesalahan: “keluar dari deskriptor file: Terlalu banyak file terbuka di sistem; lepaskan dan coba lagi”. `max_files_per_process`Parameter PostgreSQL menentukan berapa banyak file yang dapat dibuka setiap proses. Jika ada sejumlah besar koneksi yang bergabung dengan sejumlah besar tabel, dimungkinkan untuk mencapai batas ini.
**Tindakan yang disarankan:**
+ Menurunkan nilai parameter `max_files_per_process` dapat membantu meringankan kesalahan ini. Setiap proses dan subproses (misalnya, query paralel) dapat membuka jumlah file ini, dan jika kueri bergabung dengan beberapa tabel, batas ini dapat habis.
+ Kurangi jumlah keseluruhan koneksi dan gunakan kumpulan koneksi seperti Amazon RDS [Proxy ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) atau solusi lain seperti. PgBouncer Untuk mempelajari lebih lanjut, lihat situs [PgBouncer web](https://www.pgbouncer.org/).
**Dampak: Kelelahan Inode**
Kesalahan: “Tidak ada ruang tersisa di perangkat”. Jika ini diamati ketika ada banyak ruang kosong penyimpanan, ini disebabkan oleh kehabisan inode. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) memberikan visibilitas untuk inode yang digunakan dan jumlah maksimum yang tersedia untuk host Anda.
**Ambang batas perkiraan:** [Jutaan](#PostgreSQL.HighObjectCount.Note)
## Tabel sementara
Menggunakan tabel sementara berguna untuk data uji atau hasil antara dan merupakan pola umum yang terlihat di banyak mesin database. Implikasi penggunaan berat di PostgreSQL harus dipahami untuk menghindari beberapa jebakan. Setiap tabel sementara yang dibuat dan dijatuhkan akan menambahkan baris ke tabel katalog sistem, yang ketika menjadi kembung, akan menyebabkan masalah kinerja umum.
**Dampak: Autovacuum tertinggal**
Tabel sementara tidak disedot oleh autovacuum tetapi akan mempertahankan transaksi IDs selama keberadaannya dan dapat menyebabkan sampul jika tidak dihapus.
**Tindakan yang disarankan:** Tabel sementara akan hidup selama sesi yang membuatnya atau dapat dijatuhkan secara manual. Praktik terbaik untuk menghindari transaksi jangka panjang dengan tabel sementara akan mencegah tabel ini berkontribusi pada pertumbuhan ID transaksi maksimum yang digunakan.
**Dampak: Degradasi kinerja umum**
Degradasi kinerja umum karena ukuran katalog. Ketika sesi terus membuat dan menjatuhkan tabel sementara, itu akan menambah`pg_attribute`, `pg_class` dan `pg_depend` tabel yang sering digunakan dalam operasi database normal. Tidak akan ada acara tunggu tertentu yang terlihat, tetapi efisiensi buffer bersama akan terpengaruh.
**Tindakan yang disarankan:**
+ Periksa tabel kembung secara teratur untuk tabel khusus ini dan sesekali lakukan `VACUUM FULL` pada tabel tertentu ini. Ketahuilah bahwa `VACUUM FULL` pada tabel katalog memerlukan `ACCESS EXCLUSIVE` kunci yang berarti tidak ada kueri lain yang dapat mengaksesnya sampai operasi selesai.
+ Jika tabel sementara banyak digunakan, sebelum peningkatan versi utama, tabel katalog khusus ini sangat disarankan untuk mengurangi waktu henti. `VACUUM FULL`
**Praktik terbaik umum:**
+ Kurangi penggunaan tabel sementara dengan menggunakan ekspresi tabel umum untuk menghasilkan hasil antara. Ini kadang-kadang dapat mempersulit pertanyaan yang diperlukan, tetapi akan menghilangkan dampak yang tercantum di atas.
+ Gunakan kembali tabel sementara dengan menggunakan `TRUNCATE` perintah untuk menghapus konten alih-alih melakukan drop/create langkah-langkah. Ini juga akan menghilangkan masalah pertumbuhan ID transaksi yang disebabkan oleh tabel sementara.
**Ambang perkiraan:** [Puluhan ribu](#PostgreSQL.HighObjectCount.Note)
## Tabel yang tidak tersumbat
Tabel yang tidak tercatat dapat menawarkan peningkatan kinerja karena tidak akan menghasilkan informasi WAL apa pun. Mereka harus digunakan dengan hati-hati karena mereka tidak menawarkan daya tahan selama pemulihan kerusakan database karena mereka akan terpotong. Ini adalah operasi yang mahal di PostgreSQL karena setiap tabel yang tidak tersumbat dipotong secara serial. Meskipun operasi ini cepat untuk sejumlah kecil tabel yang tidak tercatat, ketika jumlahnya ribuan, itu dapat mulai menambahkan penundaan penting selama startup.
**Dampak: Replikasi logis**
Tabel yang tidak tercatat umumnya tidak termasuk dalam replikasi logis, termasuk Penerapan [Biru/Hijau Penerapan Biru/Hijau](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) .
**Dampak: Waktu henti yang diperpanjang selama pemulihan**
Selama status database apa pun yang melibatkan pemulihan kerusakan basis data seperti reboot Multi-AZ dengan failover, point-in-time pemulihan Amazon RDS, dan peningkatan versi utama Amazon RDS, operasi serial pemotongan tabel yang tidak tercatat akan terjadi. Hal ini dapat menyebabkan pengalaman downtime yang jauh lebih tinggi dari yang diharapkan.
**Tindakan yang disarankan:**
+ Minimalkan penggunaan tabel yang tidak tercatat hanya untuk data yang dapat diterima untuk hilang selama operasi pemulihan kerusakan database.
+ Minimalkan penggunaan tabel yang tidak tercatat karena perilaku pemotongan serial saat ini dapat menyebabkan startup database memakan banyak waktu.
**Praktik terbaik umum:**
+ Tabel yang tidak tersumbat tidak aman untuk crash. Memulai point-in-time pemulihan, yang melibatkan pemulihan crash, membutuhkan waktu yang signifikan di PostgreSQL karena ini adalah proses serial yang memotong setiap tabel.
**Ambang perkiraan:** [Ribuan](#PostgreSQL.HighObjectCount.Note)
## Partisi
Partisi dapat meningkatkan kinerja kueri dan menyediakan organisasi data yang logis. Dalam skenario ideal, partisi diatur sehingga pemangkasan partisi dapat digunakan selama perencanaan dan pelaksanaan kueri. Menggunakan terlalu banyak partisi dapat berdampak negatif pada kinerja kueri dan pemeliharaan basis data. Pilihan cara mempartisi tabel harus dibuat dengan hati-hati, karena kinerja perencanaan dan pelaksanaan kueri dapat dipengaruhi secara negatif oleh desain yang buruk. Lihat dokumentasi [PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) untuk detail tentang partisi.
**Dampak: Degradasi kinerja umum**
Terkadang perencanaan overhead waktu akan meningkat dan menjelaskan rencana untuk pertanyaan Anda akan menjadi lebih rumit, sehingga sulit untuk mengidentifikasi peluang penyetelan. Untuk versi PostgreSQL lebih awal dari 18, banyak partisi dengan beban kerja tinggi dapat menyebabkan menunggu. `LWLock:LockManager`
**Tindakan yang disarankan:** Tentukan jumlah minimum partisi yang akan memungkinkan Anda untuk menyelesaikan kedua organisasi data Anda sementara pada saat yang sama menyediakan eksekusi kueri kinerja.
**Dampak: Kompleksitas pemeliharaan**
Jumlah partisi yang sangat tinggi akan menimbulkan kesulitan pemeliharaan seperti pra-pembuatan dan penghapusan. Autovacuum akan memperlakukan partisi sebagai hubungan normal dan harus melakukan pembersihan rutin, oleh karena itu membutuhkan cukup banyak pekerja untuk menyelesaikan tugas.
**Tindakan yang disarankan:**
+ Pastikan Anda membuat partisi sehingga beban kerja tidak diblokir saat partisi baru diperlukan (misalnya, partisi berbasis bulanan) dan partisi lama diluncurkan.
+ Pastikan Anda memiliki cukup pekerja autovacuum untuk melakukan pemeliharaan pembersihan normal semua partisi.
**Ambang perkiraan:** [Ratusan](#PostgreSQL.HighObjectCount.Note)
## File sementara
Berbeda dari tabel sementara yang disebutkan di atas, file sementara dibuat oleh PostgreSQL ketika kueri kompleks mungkin melakukan beberapa operasi pengurutan atau hash pada saat yang sama, dengan setiap operasi menggunakan memori instance untuk menyimpan hasil hingga nilai yang ditentukan dalam parameter. `work_mem` Jika memori instans tidak cukup, file sementara akan dibuat untuk menyimpan hasil. Lihat [Mengelola file sementara](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) untuk detail selengkapnya tentang file sementara. Jika beban kerja Anda menghasilkan sejumlah besar file-file ini, mungkin ada beberapa dampak.
**Dampak: Kelelahan deskriptor file**
Kesalahan: “keluar dari deskriptor file: Terlalu banyak file terbuka di sistem; lepaskan dan coba lagi”. `max_files_per_process`Parameter PostgreSQL menentukan berapa banyak file yang dapat dibuka setiap proses. Jika ada sejumlah besar koneksi yang bergabung dengan sejumlah besar tabel, dimungkinkan untuk mencapai batas ini.
**Tindakan yang disarankan:**
+ Menurunkan nilai parameter `max_files_per_process` dapat membantu meringankan kesalahan ini. Setiap proses dan subproses (misalnya, query paralel) dapat membuka jumlah file ini, dan jika kueri bergabung dengan beberapa tabel, batas ini dapat habis.
+ Kurangi jumlah keseluruhan koneksi dan gunakan kumpulan koneksi seperti [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) atau solusi lain seperti. PgBouncer Untuk mempelajari lebih lanjut, lihat situs [PgBouncer web](https://www.pgbouncer.org/).
**Dampak: Kelelahan Inode**
Kesalahan: “Tidak ada ruang tersisa di perangkat”. Jika ini diamati ketika ada banyak ruang kosong penyimpanan, ini disebabkan oleh kehabisan inode. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) menyediakan visibilitas untuk inode yang digunakan dan jumlah maksimum yang tersedia untuk host Anda.
**Praktik terbaik umum:**
+ Pantau penggunaan file temp Anda dengan [Performance Insights Performance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) .
+ Sesuaikan kueri yang menghasilkan file sementara yang signifikan untuk melihat apakah mungkin untuk mengurangi jumlah total file temp.
**Ambang perkiraan:** [Ribuan](#PostgreSQL.HighObjectCount.Note)
## Urutan
Urutan adalah objek yang mendasari yang digunakan untuk penambahan kolom otomatis di PostgreSQL dan mereka memberikan keunikan dan kunci untuk data. Ini dapat digunakan pada tabel individu tanpa konsekuensi selama operasi normal dengan satu pengecualian replikasi logis.
Di PostgreSQL, replikasi logis saat ini tidak mereplikasi nilai urutan saat ini ke pelanggan mana pun. Untuk mempelajari selengkapnya, lihat [halaman Pembatasan dalam dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Dampak: Waktu peralihan yang diperpanjang**
Jika Anda berencana untuk menggunakan [Amazon RDS Blue/Green Deployment](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) untuk semua jenis perubahan konfigurasi atau upgrade, penting untuk memahami dampak dari sejumlah besar urutan pada switchover. Salah satu fase terakhir dari peralihan akan menyinkronkan nilai urutan saat ini, dan jika ada beberapa ribu, ini akan meningkatkan waktu peralihan keseluruhan.
**Tindakan yang disarankan:** Jika beban kerja database Anda memungkinkan penggunaan UUID bersama alih-alih sequence-per-table pendekatan, ini akan mengurangi langkah sinkronisasi selama peralihan.
**Ambang perkiraan:** [Ribuan](#PostgreSQL.HighObjectCount.Note)
## Benda besar
Objek besar disimpan dalam tabel sistem tunggal bernama pg\$1largeobject. Setiap objek besar juga memiliki entri dalam tabel sistem pg\$1largeobject\$1metadata. Objek-objek ini dibuat, dimodifikasi dan dibersihkan jauh berbeda dari hubungan standar. Benda besar tidak ditangani oleh autovacuum dan harus dibersihkan secara berkala melalui proses terpisah yang disebut vacuumlo. Lihat mengelola objek besar dengan modul lo untuk contoh mengelola objek besar.
**Dampak: Replikasi logis**
Objek besar saat ini tidak direplikasi di PostgreSQL selama replikasi logis. Untuk mempelajari selengkapnya, lihat [halaman Pembatasan dalam dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). Dalam konfigurasi [Biru/Hijau](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) , ini berarti objek besar di lingkungan biru tidak direplikasi ke lingkungan hijau.
**Dampak: Peningkatan versi utama**
Upgrade dapat kehabisan memori dan gagal jika ada jutaan objek besar dan instance tidak dapat menanganinya selama peningkatan. Proses upgrade versi utama PostgreSQL terdiri dari dua fase luas: membuang skema melalui pg\$1dump dan memulihkannya melalui pg\$1restore. Jika database Anda memiliki jutaan objek besar, Anda perlu memastikan instance Anda memiliki memori yang cukup untuk menangani pg\$1dump dan pg\$1restore selama peningkatan dan menskalakannya ke jenis instance yang lebih besar.
**Praktik terbaik umum:**
+ Gunakan utilitas vacuumlo secara teratur untuk menghapus benda besar yatim piatu yang mungkin Anda miliki.
+ Pertimbangkan untuk menggunakan tipe data BYTEA untuk menyimpan objek besar Anda dalam database.
**Ambang batas perkiraan:** [Jutaan](#PostgreSQL.HighObjectCount.Note)
## Perkiraan ambang batas
Ambang batas perkiraan yang disebutkan dalam topik ini hanya digunakan untuk memberikan perkiraan seberapa jauh skala sumber daya tertentu. Mereka mewakili rentang umum di mana dampak yang dijelaskan menjadi lebih mungkin, tetapi perilaku aktual tergantung pada beban kerja, ukuran instance, dan konfigurasi spesifik Anda. Meskipun dimungkinkan untuk melampaui perkiraan ini, perawatan dan pemeliharaan harus dipatuhi untuk menghindari dampak yang tercantum.
#
TOAST (The Oversized-Attribute Storage Technique) adalah fitur PostgreSQL yang dirancang untuk menangani nilai data besar yang melebihi ukuran blok database 8KB yang khas. PostgreSQL tidak mengizinkan baris fisik menjangkau beberapa blok. Ukuran blok bertindak sebagai batas atas pada ukuran baris. TOAST mengatasi batasan ini dengan membagi nilai bidang besar menjadi potongan yang lebih kecil. Ini menyimpannya secara terpisah dalam tabel TOAST khusus yang terhubung ke tabel utama. Untuk informasi selengkapnya, lihat mekanisme penyimpanan [PostgreSQL TOAST](https://www.postgresql.org/docs/current/storage-toast.html) dan dokumentasi implementasi.
**Topics**
+ [Memahami operasi TOAST](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [Mengidentifikasi tantangan kinerja](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [Rekomendasi](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [Memantau](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Memahami operasi TOAST
TOAST melakukan kompresi dan menyimpan nilai bidang besar di luar jalur. TOAST memberikan OID unik (Object Identifier) untuk setiap potongan data besar yang disimpan dalam tabel TOAST. Tabel utama menyimpan ID nilai TOAST dan ID relasi pada halaman untuk mereferensikan baris yang sesuai dalam tabel TOAST. Hal ini memungkinkan PostgreSQL untuk secara efisien menemukan dan mengelola potongan TOAST ini. Namun, seiring bertambahnya tabel TOAST, sistem berisiko melelahkan tersedia OIDs, yang menyebabkan penurunan kinerja dan potensi waktu henti karena penipisan OID.
### Pengidentifikasi objek di TOAST
Object Identifier (OID) adalah pengidentifikasi unik seluruh sistem yang digunakan oleh PostgreSQL untuk referensi objek database seperti tabel, indeks, dan fungsi. Pengidentifikasi ini memainkan peran penting dalam operasi internal PostgreSQL, memungkinkan database untuk secara efisien menemukan dan mengelola objek.
Untuk tabel dengan kumpulan data yang memenuhi syarat untuk pemanggangan, PostgreSQL OIDs menetapkan untuk mengidentifikasi secara unik setiap potongan data berukuran besar yang disimpan dalam tabel TOAST terkait. Sistem mengaitkan setiap potongan dengan a`chunk_id`, yang membantu PostgreSQL mengatur dan menemukan potongan ini secara efisien dalam tabel TOAST.
## Mengidentifikasi tantangan kinerja
Manajemen OID PostgreSQL bergantung pada penghitung 32-bit global sehingga membungkus setelah menghasilkan 4 miliar nilai unik. Sementara cluster database berbagi penghitung ini, alokasi OID melibatkan dua langkah selama operasi TOAST:
+ **Penghitung global untuk alokasi** - Penghitung global memberikan OID baru di seluruh cluster.
+ **Pencarian lokal untuk konflik** - Tabel TOAST memastikan OID baru tidak bertentangan dengan yang OIDs sudah ada yang sudah digunakan dalam tabel tertentu.
Degradasi kinerja dapat terjadi ketika:
+ Tabel TOAST memiliki fragmentasi tinggi atau penggunaan OID padat, yang menyebabkan keterlambatan dalam menetapkan OID.
+ Sistem sering mengalokasikan dan menggunakan kembali OIDs di lingkungan dengan churn data tinggi atau tabel lebar yang menggunakan TOAST secara ekstensif.
Untuk informasi selengkapnya, lihat batas ukuran [tabel PostgreSQL TOAST](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit) dan dokumentasi alokasi OID:
Penghitung global menghasilkan OIDs dan membungkus sekitar setiap 4 miliar nilai, sehingga dari waktu ke waktu, sistem menghasilkan nilai yang sudah digunakan lagi. PostgreSQL mendeteksi itu dan mencoba lagi dengan OID berikutnya. INSERT yang lambat dapat terjadi jika ada nilai OID bekas yang sangat lama tanpa celah di tabel TOAST. Tantangan ini menjadi lebih terasa saat ruang OID terisi, yang mengarah ke penyisipan dan pembaruan yang lebih lambat.
### Mengidentifikasi masalah
+ `INSERT`Pernyataan sederhana membutuhkan waktu lebih lama dari biasanya dengan cara yang tidak konsisten dan acak.
+ Penundaan hanya terjadi untuk `INSERT` dan `UPDATE` pernyataan yang melibatkan operasi TOAST.
+ Entri log berikut muncul di log PostgreSQL ketika sistem berjuang untuk menemukan tersedia di tabel TOAST: OIDs
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights menunjukkan tingginya jumlah sesi aktif rata-rata (AAS) yang terkait dengan `LWLock:buffer_io` dan acara `LWLock:OidGenLock` tunggu.
Anda dapat menjalankan kueri SQL berikut untuk mengidentifikasi transaksi INSERT yang berjalan lama dengan peristiwa tunggu:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Contoh hasil kueri yang menampilkan operasi INSERT dengan waktu tunggu yang diperpanjang:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Mengisolasi masalah
+ **Uji sisipan kecil** — Masukkan catatan yang lebih kecil dari `toast_tuple_target` ambang batas. Ingat bahwa kompresi diterapkan sebelum penyimpanan TOAST. Jika ini beroperasi tanpa masalah kinerja, masalahnya terkait dengan operasi TOAST.
+ **Uji tabel baru** - Buat tabel baru dengan struktur yang sama dan masukkan catatan yang lebih besar dari`toast_tuple_target`. Jika ini berfungsi tanpa masalah, masalah dilokalkan ke alokasi OID tabel asli.
## Rekomendasi
Pendekatan berikut dapat membantu menyelesaikan masalah pertentangan TOAST OID.
+ **Pembersihan dan arsip data** - Tinjau dan hapus data usang atau tidak perlu untuk dikosongkan untuk penggunaan di OIDs masa mendatang, atau mengarsipkan data. Pertimbangkan batasan berikut:
+ Skalabilitas terbatas, karena pembersihan di masa depan mungkin tidak selalu memungkinkan.
+ Kemungkinan operasi VACUUM yang berjalan lama untuk menghilangkan tupel mati yang dihasilkan.
+ **Menulis ke tabel baru** - Buat tabel baru untuk sisipan future dan gunakan `UNION ALL` tampilan untuk menggabungkan data lama dan baru untuk kueri. Tampilan ini menyajikan data gabungan dari tabel lama dan baru, yang memungkinkan kueri untuk mengaksesnya sebagai satu tabel. Pertimbangkan batasan berikut:
+ Pembaruan pada tabel lama mungkin masih menyebabkan kelelahan OID.
+ **Partisi atau Shard** - Partisi data tabel atau pecahan untuk skalabilitas dan kinerja yang lebih baik. Pertimbangkan batasan berikut:
+ Peningkatan kompleksitas dalam logika kueri dan pemeliharaan, potensi kebutuhan untuk perubahan aplikasi untuk menangani data yang dipartisi dengan benar.
## Memantau
### Menggunakan tabel sistem
Anda dapat menggunakan tabel sistem PostgreSQL untuk memantau pertumbuhan penggunaan OID.
**Awas**
Tergantung pada jumlah OIDs dalam tabel TOAST, mungkin perlu waktu untuk menyelesaikannya. Kami menyarankan Anda menjadwalkan pemantauan selama jam kerja untuk meminimalkan dampak.
Blok anonim berikut menghitung jumlah berbeda yang OIDs digunakan di setiap tabel TOAST dan menampilkan informasi tabel induk:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Contoh output yang menampilkan statistik penggunaan OID dengan tabel TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Blok anonim berikut mengambil OID maksimum yang ditetapkan untuk setiap tabel TOAST yang tidak kosong:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Contoh output menampilkan potongan maksimum IDs untuk tabel TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Menggunakan Performance Insights
Peristiwa tunggu `LWLock:buffer_io` dan `LWLock:OidGenLock` muncul di Performance Insights selama operasi yang memerlukan penetapan Object Identifiers () baru. OIDs Sesi Aktif Rata-Rata Tinggi (AAS) untuk acara ini biasanya menunjukkan pertengkaran selama penugasan OID dan manajemen sumber daya. Ini sangat umum di lingkungan dengan churn data tinggi, penggunaan data besar yang ekstensif, atau pembuatan objek yang sering.
#### LWLock:buffer\$1io
`LWLock:buffer_io`adalah acara tunggu yang terjadi ketika sesi PostgreSQL I/O menunggu operasi pada buffer bersama selesai. Ini biasanya terjadi ketika database membaca data dari disk ke memori atau menulis halaman yang dimodifikasi dari memori ke disk. Peristiwa `BufferIO` tunggu memastikan konsistensi dengan mencegah beberapa proses mengakses atau memodifikasi buffer yang sama saat I/O operasi sedang berlangsung. Kejadian tinggi dari peristiwa tunggu ini dapat mengindikasikan kemacetan disk atau I/O aktivitas berlebihan dalam beban kerja database.
Selama operasi TOAST:
+ PostgreSQL OIDs mengalokasikan untuk objek besar dan memastikan keunikannya dengan memindai indeks tabel TOAST.
+ Indeks TOAST yang besar mungkin memerlukan akses beberapa halaman untuk memverifikasi keunikan OID. Ini menghasilkan peningkatan I/O disk, terutama ketika kumpulan buffer tidak dapat menyimpan semua halaman yang diperlukan.
Ukuran indeks secara langsung mempengaruhi jumlah halaman buffer yang perlu diakses selama operasi ini. Bahkan jika indeks tidak membengkak, ukurannya yang tipis dapat meningkatkan buffer I/O, terutama di lingkungan dengan konkurensi tinggi atau churn tinggi. [Untuk informasi lebih lanjut, lihat:Bufferio LWLock wait event troubleshooting guide.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html)
#### LWLock:OidGenLock
`OidGenLock`adalah peristiwa tunggu yang terjadi ketika sesi PostgreSQL sedang menunggu untuk mengalokasikan pengenal objek baru (OID). Kunci ini memastikan bahwa OIDs dihasilkan secara berurutan dan aman, memungkinkan hanya satu proses untuk menghasilkan OIDs pada satu waktu.
Selama operasi TOAST:
+ **Alokasi OID untuk potongan dalam tabel TOAST -** PostgreSQL menetapkan potongan dalam tabel OIDs TOAST saat mengelola catatan data besar. Setiap OID harus unik untuk mencegah konflik dalam katalog sistem.
+ **Konkurensi tinggi** — Karena akses ke generator OID berurutan, ketika beberapa sesi secara bersamaan membuat objek yang membutuhkan OIDs, pertengkaran dapat terjadi. `OidGenLock` Ini meningkatkan kemungkinan sesi menunggu alokasi OID selesai.
+ **Ketergantungan pada akses katalog sistem** — Mengalokasikan OIDs memerlukan pembaruan ke tabel katalog sistem bersama seperti dan. `pg_class` `pg_type` Jika tabel ini mengalami aktivitas berat (karena operasi DDL yang sering), itu dapat meningkatkan pertentangan kunci untuk. `OidGenLock`
+ **Permintaan alokasi OID yang tinggi** - TOAST beban kerja yang berat dengan catatan data yang besar memerlukan alokasi OID yang konstan, meningkatkan perselisihan.
Faktor tambahan yang meningkatkan pertentangan OID:
+ **Pembuatan objek yang sering** - Beban kerja yang sering membuat dan menjatuhkan objek, seperti tabel sementara, memperkuat pertentangan pada penghitung OID global.
+ **Penguncian penghitung global** - Penghitung OID global diakses secara serial untuk memastikan keunikan, menciptakan satu titik pertikaian di lingkungan konkurensi tinggi.
## Bekerja dengan mekanisme pencatatan log yang didukung oleh RDS for PostgreSQL
Ada beberapa parameter, ekstensi, dan item lain yang dapat dikonfigurasi dan Anda atur untuk mencatat aktivitas yang terjadi di instans DB PostgreSQL. Sumber daya yang dimaksud meliputi:
+ Parameter `log_statement` dapat digunakan untuk mencatat aktivitas pengguna di basis data PostgreSQL. Untuk mempelajari pencatatan log RDS for PostgreSQL dan cara memantau log selengkapnya, lihat [](USER_LogAccess.Concepts.PostgreSQL.md).
+ Parameter `rds.force_admin_logging_level` mencatat tindakan yang dilakukan oleh pengguna internal Amazon RDS (rdsadmin) di basis data instans DB. Parameter ini akan menulis output ke kesalahan log PostgreSQL. Nilai yang diizinkan adalah `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, log, `fatal`, dan `panic`. Nilai default-nya adalah `disabled`.
+ Parameter `rds.force_autovacuum_logging_level` dapat diatur untuk mengambil berbagai operasi autovacuum di log kesalahan PostgreSQL. Untuk informasi selengkapnya, lihat [Melakukan log aktivitas autovacuum dan vakum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ Ekstensi PostgreSQL Audit (pgAaudit) dapat diinstal dan dikonfigurasi untuk mengambil aktivitas di tingkat sesi atau di tingkat objek. Untuk informasi selengkapnya, lihat [Menggunakan pgAudit untuk mencatat aktivitas database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Dengan ekstensi `log_fdw`, Anda dapat mengakses log mesin basis data menggunakan SQL. Untuk informasi selengkapnya, lihat [Menggunakan ekstensi log\$1fdw untuk mengakses log DB dengan SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ Pustaka `pg_stat_statements` ditentukan sebagai default untuk parameter `shared_preload_libraries` dalam RDS for PostgreSQL versi 10 dan yang lebih baru. Pustaka inilah yang dapat Anda gunakan untuk menganalisis kueri yang sedang berjalan. Pastikan `pg_stat_statements` diatur dalam grup parameter DB Anda. Untuk informasi cara memantau instans DB RDS for PostgreSQL menggunakan informasi yang disediakan pustaka ini selengkapnya, lihat [Statistik SQL untuk RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Parameter `log_hostname` mengambil log nama host dari setiap koneksi klien. Untuk RDS for PostgreSQL versi 12 dan versi yang lebih baru, parameter ini diatur ke `off` secara default. Jika diaktifkan, pastikan Anda memantau waktu koneksi sesi. Ketika diaktifkan, layanan menggunakan permintaan pencarian terbalik sistem nama domain (DNS) untuk mendapatkan nama host klien yang membuat koneksi dan menambahkannya ke log PostgreSQL. Hal ini memberikan dampak nyata selama koneksi sesi. Sebaiknya mengaktifkan parameter ini hanya untuk memecahkan masalah.
Secara umum, tujuan pencatatan log adalah agar DBA dapat memantau, menyesuaikan performa, dan memecahkan masalah. Banyak log diunggah secara otomatis ke Amazon CloudWatch atau Performance Insights. Di sini, log diurutkan dan dikelompokkan agar dapat memberikan metrik lengkap untuk instans DB Anda. Untuk mempelajari pemantauan dan metrik Amazon RDS selengkapnya, lihat [Memantau metrik dalam instans Amazon RDS](CHAP_Monitoring.md).
# Mengelola file sementara dengan PostgreSQL
Di PostgreSQL, kueri kompleks mungkin melakukan beberapa operasi pengurutan atau hash pada saat yang sama, dengan setiap operasi menggunakan memori instance untuk menyimpan hasil hingga nilai yang ditentukan dalam parameter. [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) Jika memori instans tidak cukup, file sementara akan dibuat untuk menyimpan hasil. Hasil ini ditulis ke disk untuk menyelesaikan eksekusi kueri. Kemudian, file-file ini secara otomatis dihapus setelah kueri selesai. Dalam RDS for PostgreSQL, file ini disimpan di Amazon EBS pada volume data. Untuk informasi selengkapnya, lihat [Penyimpanan instans DB Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Anda dapat memantau `FreeStorageSpace` metrik yang diterbitkan CloudWatch untuk memastikan bahwa instans DB Anda memiliki ruang penyimpanan gratis yang cukup. Untuk informasi selengkapnya, lihat [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Sebaiknya gunakan Amazon RDS Optimized Read cluster untuk beban kerja yang melibatkan beberapa kueri bersamaan yang meningkatkan penggunaan file sementara. instance ini menggunakan penyimpanan tingkat blok solid state drive (SSDNVMe) berbasis Non-Volatile Memory Express () lokal untuk menempatkan file sementara. Untuk informasi selengkapnya, lihat [Meningkatkan performa kueri untuk RDS for PostgreSQL dengan Amazon RDS Optimized Reads](USER_PostgreSQL.optimizedreads.md).
Anda dapat menggunakan parameter dan fungsi berikut untuk mengelola file sementara dalam instans Anda.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Parameter ini membatalkan kueri apa pun yang melebihi ukuran temp\$1files dalam KB. Batas ini mencegah kueri apa pun berjalan tanpa henti dan menghabiskan ruang disk dengan file sementara. Anda dapat memperkirakan nilai menggunakan hasil dari parameter `log_temp_files`. Sebagai praktik terbaik, periksa perilaku beban kerja dan tetapkan batas sesuai dengan estimasi. Contoh berikut menunjukkan bagaimana kueri dibatalkan saat melampaui batas.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Parameter ini mengirimkan pesan ke postgresql.log ketika file sementara dari sebuah sesi dihapus. Parameter ini menghasilkan log setelah kueri berhasil diselesaikan. Oleh karena itu, ini mungkin tidak membantu dalam memecahkan masalah kueri yang aktif dan berjalan lama.
Contoh berikut menunjukkan bahwa ketika kueri berhasil diselesaikan, entri dicatat dalam file postgresql.log, sedangkan file sementara dibersihkan.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Fungsi yang tersedia dari RDS untuk PostgreSQL 13 dan versi yang lebih baru ini memberikan visibilitas terhadap penggunaan file sementara saat ini. Kueri yang sudah selesai tidak muncul di hasil fungsi. Dalam contoh berikut, Anda dapat melihat hasil dari fungsi ini.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Nama file mencakup ID pemrosesan (PID) dari sesi yang menghasilkan file sementara. Kueri yang lebih maju, seperti pada contoh berikut, melakukan penjumlahan file sementara untuk setiap PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Jika Anda mengaktifkan parameter pg\$1stat\$1statements, Anda dapat melihat rata-rata penggunaan file sementara per panggilan. Anda dapat mengidentifikasi query\$1id dari kueri dan menggunakannya untuk memeriksa penggunaan file sementara seperti yang ditunjukkan pada contoh berikut.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Di dasbor Wawasan Performa, Anda dapat melihat penggunaan file sementara dengan mengaktifkan metrik **temp\$1bytes** dan **temp\$1files**. Kemudian, Anda dapat melihat rata-rata kedua metrik ini dan melihat sejauh mana kesesuaiannya dengan beban kerja kueri. Tampilan dalam Wawasan Performa tidak secara khusus menampilkan kueri yang menghasilkan file sementara. Namun, jika Anda menggabungkan Wawasan Performa dengan kueri yang ditampilkan untuk `pg_ls_tmpdir`, Anda dapat memecahkan masalah, menganalisis, dan menentukan perubahan dalam beban kerja kueri.
Untuk informasi selengkapnya tentang cara menganalisis metrik dan kueri dengan Performance Insights, lihat. [Menganalisis metrik dengan dasbor Wawasan Performa](USER_PerfInsights.UsingDashboard.md)
Untuk contoh melihat penggunaan file sementara dengan Performance Insights, lihat [Melihat penggunaan file sementara dengan Performance Insights](PostgreSQL.ManagingTempFiles.Example.md)
# Melihat penggunaan file sementara dengan Performance Insights
**Anda dapat menggunakan Performance Insights untuk melihat penggunaan file sementara dengan mengaktifkan metrik **temp\$1bytes dan temp\$1files**.** Tampilan di Performance Insights tidak menampilkan kueri spesifik yang menghasilkan file sementara, namun jika Anda menggabungkan Performance Insights dengan kueri yang ditampilkan`pg_ls_tmpdir`, Anda dapat memecahkan masalah, menganalisis, dan menentukan perubahan dalam beban kerja kueri.
1. Di dasbor Wawasan Performa, pilih **Kelola Metrik**.
1. Pilih **Metrik basis data**, lalu pilih metrik **temp\$1bytes** dan **temp\$1files** seperti yang ditunjukkan pada gambar berikut.
![\[Metrik ditampilkan dalam grafik.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Di tab **SQL Teratas**, pilih ikon **Preferensi**.
1. Di jendela **Preferensi**, aktifkan statistik berikut agar muncul di tab **SQL Teratas** dan pilih **Lanjutkan**.
+ Temp writes/detik
+ Temp reads/detik
+ Tmp blk write/panggilan
+ Tmp blk read/panggilan
1. File sementara rusak saat digabungkan kueri yang ditampilkan untuk `pg_ls_tmpdir`, seperti yang ditunjukkan pada contoh berikut.
![\[Kueri yang menampilkan penggunaan file sementara.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Peristiwa `IO:BufFileRead` dan `IO:BufFileWrite` terjadi ketika kueri teratas di beban kerja Anda sering membuat file sementara. Anda dapat menggunakan Wawasan Performa untuk mengidentifikasi kueri teratas yang menunggu pada `IO:BufFileRead` dan `IO:BufFileWrite` dengan meninjau Sesi Aktif Rata-rata (AAS) di bagian Muatan Basis Data dan SQL Teratas.
![\[IO: BufFileRead dan IO: BufFileWrite dalam grafik.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Untuk informasi selengkapnya tentang cara menganalisis kueri teratas dan muatan berdasarkan peristiwa tunggu dengan Wawasan Performa, lihat [Ikhtisar SQL tab Top](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Anda harus mengidentifikasi dan menyetel kueri yang menyebabkan peningkatan penggunaan file sementara dan peristiwa tunggu terkait. Untuk informasi lebih lanjut tentang peristiwa tunggu dan remediasi ini, lihat [IO: BufFileRead dan IO: BufFileWrite IO](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html).
**catatan**
Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) mengontrol ketika operasi pengurutan kehabisan memori dan hasilnya ditulis ke dalam file sementara. Sebaiknya Anda tidak mengubah pengaturan parameter ini lebih tinggi dari nilai default karena akan memungkinkan setiap sesi basis data mengonsumsi lebih banyak memori. Selain itu, satu sesi yang melakukan penggabungan dan pengurutan kompleks dapat melakukan operasi paralel di mana setiap operasi mengonsumsi memori.
Sebagai praktik terbaik, ketika Anda memiliki laporan besar dengan beberapa penggabungan dan pengurutan, atur parameter ini pada tingkat sesi dengan menggunakan perintah `SET work_mem`. Kemudian, perubahan hanya diterapkan pada sesi saat ini dan tidak mengubah nilai secara global.
## Menggunakan pgBadger untuk analisis log dengan PostgreSQL
Anda dapat menggunakan penganalisis log seperti [pgBadger](http://dalibo.github.io/pgbadger/) untuk menganalisis log PostgreSQL. Dokumentasi pgBadger menyatakan bahwa pola %l (baris log untuk sesi atau proses) harus merupakan bagian dari awalan. Namun, jika Anda memberikan RDS `log_line_prefix` saat ini sebagai parameter pgBadger, laporan tetap akan dihasilkan.
Misalnya, perintah berikut memformat file log Amazon RDS for PostgreSQL tertanggal 04-02-2014 dengan benar menggunakan pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Menggunakan PGSnapper untuk memantau PostgreSQL
Anda dapat menggunakannya PGSnapper untuk membantu pengumpulan berkala Amazon RDS for PostgreSQL statistik dan metrik terkait kinerja. Untuk informasi selengkapnya, lihat [Memantau kinerja Amazon RDS for PostgreSQL menggunakan. PGSnapper](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/)
#
**Jenis casting** di PostgreSQL adalah proses mengubah nilai dari satu tipe data ke tipe data lainnya. PostgreSQL menyediakan cast bawaan untuk banyak konversi umum, tetapi Anda juga dapat membuat cast khusus untuk menentukan bagaimana konversi tipe tertentu harus berperilaku.
Pemeran menentukan cara melakukan konversi dari satu tipe data ke tipe data lainnya. Misalnya, mengubah teks `'123'` menjadi bilangan bulat`123`, atau numerik `45.67` menjadi teks. `'45.67'`
[Untuk informasi lengkap tentang konsep dan sintaks casting PostgreSQL, lihat PostgreSQL CREATE CAST Documentation.](https://www.postgresql.org/docs/current/sql-createcast.html)
Dimulai dengan 14.20, 15.15, 16.11, 17.7, dan 18.1, Anda dapat menggunakan ekstensi rds\$1casts untuk menginstal cast tambahan untuk tipe bawaan, sambil tetap dapat membuat gips Anda sendiri untuk jenis kustom.
**Topics**
+ [Menginstal dan menggunakan ekstensi rds\$1casts](#PostgreSQL.CustomCasts.Installing)
+ [Cast yang didukung](#PostgreSQL.CustomCasts.Supported)
+ [Membuat atau menjatuhkan gips](#PostgreSQL.CustomCasts.Creating)
+ [Membuat gips khusus dengan strategi konteks yang tepat](#PostgreSQL.CustomCasts.BestPractices)
## Menginstal dan menggunakan ekstensi rds\$1casts
Untuk membuat `rds_casts` ekstensi, sambungkan ke sebagai dan jalankan perintah berikut: `rds_superuser`
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Cast yang didukung
Buat ekstensi di setiap database tempat Anda ingin menggunakan cast kustom. Setelah membuat ekstensi, gunakan perintah berikut untuk melihat semua gips yang tersedia:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Fungsi ini mencantumkan kombinasi pemeran yang tersedia (tipe sumber, tipe target, konteks paksaan, dan fungsi pemeran). Misalnya, jika Anda ingin membuat `text` untuk `numeric` sebagai `implicit` pemain. Anda dapat menggunakan kueri berikut untuk mengetahui apakah pemeran tersedia untuk dibuat:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
Ekstensi rds\$1casts menyediakan dua jenis fungsi konversi untuk setiap pemeran:
+ *fungsi \$1inout* - Gunakan mekanisme I/O konversi standar PostgreSQL, berperilaku identik dengan cast yang dibuat dengan metode INOUT
+ *\$1fungsi khusus* - Berikan logika konversi yang disempurnakan yang menangani kasus tepi, seperti mengonversi string kosong ke nilai NULL untuk menghindari kesalahan konversi
`inout`Fungsi mereplikasi perilaku casting asli PostgreSQL, sementara `custom` fungsi memperluas fungsionalitas ini dengan menangani skenario yang tidak dapat diakomodasi oleh cast INOUT standar, seperti mengonversi string kosong menjadi bilangan bulat.
## Membuat atau menjatuhkan gips
Anda dapat membuat dan melepaskan gips yang didukung menggunakan dua metode:
### Cast kreasi
**Metode 1: Menggunakan perintah CREATE CAST asli**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Metode 2: Menggunakan fungsi rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
`create_cast`Fungsi mengambil ID dari `list_supported_casts()` output. Metode ini lebih sederhana dan memastikan Anda menggunakan fungsi dan kombinasi konteks yang benar. Id ini dijamin tetap sama di berbagai versi postgres.
Untuk memverifikasi pemeran berhasil dibuat, kueri katalog sistem pg\$1cast:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
`castcontext`Kolom menunjukkan: `e` untuk EXPLISIT, `a` untuk ASSIGNMENT, atau `i` untuk IMPLISIT.
### Menjatuhkan gips
**Metode 1: Menggunakan perintah DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Metode 2: Menggunakan fungsi rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
`drop_cast`Fungsi ini mengambil ID yang sama yang digunakan saat membuat pemeran. Metode ini memastikan Anda menjatuhkan pemeran yang tepat yang dibuat dengan ID yang sesuai.
## Membuat gips khusus dengan strategi konteks yang tepat
Saat membuat beberapa cast untuk tipe integer, kesalahan ambiguitas operator dapat terjadi jika semua cast dibuat sebagai IMPLISIT. Contoh berikut menunjukkan masalah ini dengan membuat dua cast implisit dari teks ke lebar integer yang berbeda:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
Kesalahan terjadi karena PostgreSQL tidak dapat menentukan cast implisit mana yang akan digunakan saat membandingkan kolom integer dengan nilai teks. Baik pemeran implisit int4 dan int8 adalah kandidat yang valid, menciptakan ambiguitas.
Untuk menghindari ambiguitas operator ini, gunakan konteks ASSIGNMENT untuk lebar bilangan bulat yang lebih kecil dan konteks IMPLISIT untuk lebar bilangan bulat yang lebih besar:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Dengan strategi ini, hanya pemeran int8 yang implisit, sehingga PostgreSQL dapat dengan jelas menentukan pemeran mana yang akan digunakan.
# Praktik Terbaik untuk Kueri Paralel di PostgreSQL RDS untuk PostgreSQL
Eksekusi query paralel adalah fitur di PostgreSQL yang memungkinkan query SQL tunggal untuk dipecah menjadi tugas-tugas yang lebih kecil yang diproses secara bersamaan oleh beberapa proses pekerja latar belakang. Alih-alih mengeksekusi kueri sepenuhnya dalam satu proses backend, PostgreSQL dapat mendistribusikan bagian dari kueri, seperti pemindaian, gabungan, agregasi, atau penyortiran, di beberapa inti CPU. *Proses pemimpin* mengoordinasikan eksekusi ini dan mengumpulkan hasil dari pekerja *paralel*.
Namun, untuk sebagian besar beban kerja produksi, terutama sistem OLTP konkurensi tinggi, kami sarankan untuk menonaktifkan eksekusi kueri paralel otomatis. Meskipun paralelisme dapat mempercepat kueri pada kumpulan data besar dalam analitik atau pelaporan beban kerja, paralelisme menimbulkan risiko signifikan yang seringkali lebih besar daripada manfaatnya di lingkungan produksi yang sibuk.
Eksekusi paralel juga memperkenalkan overhead yang signifikan. Setiap pekerja paralel adalah proses backend PostgreSQL lengkap, yang membutuhkan proses forking (menyalin struktur memori dan menginisialisasi status proses) dan otentikasi (memakan slot koneksi dari batas Anda). `max_connections` Setiap pekerja juga mengkonsumsi memorinya sendiri, termasuk `work_mem` untuk operasi penyortiran dan hashing, dengan beberapa pekerja per kueri, penggunaan memori berlipat ganda dengan cepat (misalnya, 4 pekerja × 64MB `work_mem` = 256MB per kueri). Akibatnya, query paralel dapat mengkonsumsi sumber daya sistem yang jauh lebih banyak daripada kueri proses tunggal. Jika tidak disetel dengan benar, mereka dapat menyebabkan saturasi CPU (beberapa pekerja melebihi kapasitas pemrosesan yang tersedia), peningkatan peralihan konteks (sistem operasi sering beralih di antara banyak proses pekerja, menambahkan overhead dan mengurangi throughput), atau kelelahan koneksi (karena setiap pekerja paralel mengkonsumsi slot koneksi, satu kueri dengan 4 pekerja menggunakan total 5 koneksi, 1 pemimpin\$14 pekerja, yang dapat dengan cepat menghabiskan kumpulan koneksi Anda di bawah konkurensi tinggi, mencegah yang baru koneksi klien dan menyebabkan kegagalan aplikasi). Masalah ini sangat parah di bawah beban kerja konkurensi tinggi di mana beberapa kueri dapat mencoba eksekusi paralel secara bersamaan.
PostgreSQL memutuskan apakah akan menggunakan paralelisme berdasarkan perkiraan biaya. Dalam beberapa kasus, perencana dapat secara otomatis beralih ke paket paralel jika tampak lebih murah bahkan ketika itu tidak ideal dalam praktiknya. Ini bisa terjadi jika statistik indeks sudah ketinggalan zaman atau jika bloat membuat pemindaian berurutan tampak lebih menarik daripada pencarian indeks. Karena perilaku ini, rencana paralel otomatis terkadang dapat memperkenalkan regresi dalam kinerja kueri atau stabilitas sistem.
Untuk mendapatkan manfaat maksimal dari query paralel di PostgreSQL RDS untuk PostgreSQL, penting untuk menguji dan menyetelnya berdasarkan beban kerja Anda, memantau dampak sistem, dan menonaktifkan pemilihan paket paralel otomatis demi kontrol tingkat kueri.
## Parameter Konfigurasi
PostgreSQL menggunakan beberapa parameter untuk mengontrol perilaku dan ketersediaan query paralel. Memahami dan menyetel ini sangat penting untuk mencapai kinerja yang dapat diprediksi:
| Parameter | Deskripsi | Default |
| --- | --- | --- |
| max\$1parallel\$1workers | Jumlah maksimum proses pekerja latar belakang yang dapat berjalan secara total | TERBESAR (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Jumlah maksimum pekerja per node rencana kueri (misalnya, perGather) | 2 |
| parallel\$1setup\$1cost | Biaya perencana ditambahkan untuk memulai infrastruktur query paralel | 1000 |
| parallel\$1tuple\$1cost | Biaya per tupel diproses dalam mode paralel (berdampak pada keputusan perencana) | 0.1 |
| force\$1parallel\$1mode | Memaksa perencana untuk menguji rencana paralel (off,on,regress) | off |
### Pertimbangan Utama
+ `max_parallel_workers`mengontrol total kumpulan pekerja paralel. Jika disetel terlalu rendah, beberapa kueri mungkin kembali ke eksekusi serial.
+ `max_parallel_workers_per_gather`mempengaruhi berapa banyak pekerja yang dapat digunakan oleh satu kueri. Nilai yang lebih tinggi meningkatkan konkurensi, tetapi juga penggunaan sumber daya.
+ `parallel_setup_cost`dan `parallel_tuple_cost` mempengaruhi model biaya perencana. Menurunkan ini dapat membuat rencana paralel lebih mungkin untuk dipilih.
+ `force_parallel_mode`berguna untuk pengujian tetapi tidak boleh digunakan dalam produksi kecuali diperlukan.
**catatan**
Nilai default `max_parallel_workers` parameter dihitung secara dinamis berdasarkan ukuran instance menggunakan `GREATEST($DBInstanceVCPU/2, 8)` rumus. Ini berarti bahwa ketika Anda menskalakan Anda ke ukuran komputasi yang lebih besar dengan lebih banyak vCPUs, jumlah maksimum pekerja paralel yang tersedia akan meningkat secara otomatis. Akibatnya, kueri yang sebelumnya dijalankan secara serial atau dengan paralelisme terbatas tiba-tiba dapat memanfaatkan lebih banyak pekerja paralel setelah operasi peningkatan skala, berpotensi menyebabkan peningkatan tak terduga dalam penggunaan koneksi, pemanfaatan CPU, dan konsumsi memori. Penting untuk memantau perilaku query paralel setelah peristiwa penskalaan komputasi dan menyesuaikan `max_parallel_workers_per_gather` jika perlu untuk mempertahankan penggunaan sumber daya yang dapat diprediksi.
## Identifikasi Penggunaan Kueri Paralel
Kueri dapat beralih ke paket paralel berdasarkan distribusi data atau statistik. Contoh:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Kueri ini mungkin menggunakan indeks untuk data terbaru, tetapi beralih ke pemindaian sekuensial paralel untuk data historis.
Anda dapat mencatat rencana eksekusi kueri dengan memuat `auto_explain` modul. Untuk mempelajari lebih lanjut, lihat [Mencatat rencana eksekusi kueri](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) di pusat AWS pengetahuan.
Anda dapat memantau [Wawasan CloudWatch Database](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) untuk peristiwa tunggu terkait Kueri Paralel. Untuk mempelajari lebih lanjut tentang peristiwa tunggu terkait Permintaan Paralel, buka acara tunggu [IPC:Parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html)
Dari PostgreSQL versi 18, Anda dapat memantau aktivitas pekerja paralel menggunakan kolom baru di dan: [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
+ `parallel_workers_to_launch`: Jumlah pekerja paralel yang direncanakan akan diluncurkan
+ `parallel_workers_launched`: Jumlah pekerja paralel yang benar-benar diluncurkan
Metrik ini membantu mengidentifikasi perbedaan antara paralelisme terencana dan aktual, yang dapat menunjukkan kendala sumber daya atau masalah konfigurasi. Gunakan kueri berikut untuk memantau eksekusi paralel:
Untuk metrik pekerja paralel tingkat Database:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Untuk metrik pekerja paralel tingkat kueri
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Cara Mengontrol Paralelisme
Ada beberapa cara untuk mengontrol paralelisme kueri, masing-masing dirancang untuk skenario dan persyaratan yang berbeda.
Untuk menonaktifkan paralelisme otomatis secara global, [parameter Anda](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) untuk disetel:
```
max_parallel_workers_per_gather = 0;
```
Untuk pengaturan persisten dan spesifik pengguna, perintah ALTER ROLE menyediakan cara untuk mengatur parameter yang akan berlaku untuk semua sesi future untuk pengguna tertentu.
Contoh:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`memastikan bahwa setiap kali pengguna ini terhubung ke database, sesi mereka akan menggunakan pengaturan pekerja paralel ini bila diperlukan.
Kontrol tingkat sesi dapat dicapai dengan menggunakan perintah SET, yang memodifikasi parameter selama sesi database saat ini. Ini sangat berguna ketika Anda perlu menyesuaikan pengaturan sementara tanpa memengaruhi pengguna lain atau sesi future. Setelah disetel, parameter ini tetap berlaku hingga diatur ulang secara eksplisit atau sampai sesi berakhir. Perintahnya mudah:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Untuk kontrol yang lebih terperinci, SET LOCAL memungkinkan Anda memodifikasi parameter untuk satu transaksi. Ini sangat ideal ketika Anda perlu menyesuaikan pengaturan untuk serangkaian kueri tertentu dalam transaksi, setelah itu pengaturan secara otomatis kembali ke nilai sebelumnya. Pendekatan ini membantu mencegah efek yang tidak diinginkan pada operasi lain dalam sesi yang sama.
## Mendiagnosis Perilaku Kueri Paralel
Gunakan `EXPLAIN (ANALYZE, VERBOSE)` untuk mengonfirmasi apakah kueri menggunakan eksekusi paralel:
+ Carilah node seperti`Gather`,`Gather Merge`, atau`Parallel Seq Scan`.
+ Bandingkan rencana dengan dan tanpa paralelisme.
Untuk menonaktifkan paralelisme sementara untuk perbandingan:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Bekerja dengan parameter pada instans DB RDS for PostgreSQL
Dalam beberapa kasus, Anda mungkin membuat instans DB RDS for PostgreSQL tanpa menentukan grup parameter kustom. Jika demikian, instans DB Anda dibuat menggunakan grup parameter default untuk versi PostgreSQL yang dipilih. Misalnya, Anda membuat instans DB RDS for PostgreSQL menggunakan PostgreSQL 13.3. Dalam hal ini, instans DB dibuat menggunakan nilai dalam grup parameter untuk rilis PostgreSQL 13, `default.postgres13`.
Anda juga dapat membuat grup parameter DB kustom Anda sendiri. Anda perlu melakukan ini jika ingin memodifikasi pengaturan untuk instans DB RDS for PostgreSQL dari nilai default-nya. Untuk mempelajari caranya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Anda dapat melacak pengaturan pada instans DB RDS for PostgreSQL melalui beberapa cara berbeda. Anda dapat menggunakan Konsol Manajemen AWS, AWS CLI, atau Amazon RDS API. Anda juga dapat membuat kueri pada nilai dari tabel `pg_settings` PostgreSQL instans Anda, seperti yang ditunjukkan berikut.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Untuk mempelajari selengkapnya tentang nilai yang ditampilkan dari kueri ini, lihat [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) dalam dokumentasi PostgreSQL.
Berhati-hatilah saat mengubah pengaturan untuk `max_connections` dan `shared_buffers` pada instans DB RDS for PostgreSQL. Misalnya, Anda memodifikasi pengaturan untuk `max_connections` atau `shared_buffers`, dan Anda menggunakan nilai yang terlalu tinggi untuk beban kerja yang sebenarnya. Dalam hal ini, maka instans DB RDS for PostgreSQL tidak akan dimulai. Jika ini terjadi, Anda akan melihat kesalahan seperti berikut di `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Namun, Anda tidak dapat mengubah nilai pengaturan apa pun yang terdapat dalam grup parameter DB RDS for PostgreSQL. Untuk mengubah pengaturan setiap parameter, buat grup parameter DB kustom. Kemudian, ubah pengaturan di grup kustom tersebut, lalu terapkan grup parameter kustom ke instans DB RDS for PostgreSQL. Untuk mempelajari selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Ada dua jenis parameter dalam RDS untuk PostgreSQL.
+ **Parameter statis** – Parameter statis mengharuskan instans DB RDS for PostgreSQL di-boot ulang setelah perubahan agar nilai baru dapat diterapkan.
+ **Parameter dinamis** – Parameter dinamis tidak memerlukan boot ulang setelah mengubah pengaturannya.
**catatan**
Jika instans DB RDS for PostgreSQL menggunakan grup parameter DB kustom Anda sendiri, Anda dapat mengubah nilai parameter dinamis pada instans DB yang sedang berjalan. Anda dapat melakukan ini dengan menggunakan Konsol Manajemen AWS, AWS CLI, atau Amazon RDS API.
Jika memiliki hak istimewa untuk melakukan tindakan ini, Anda juga dapat mengubah nilai parameter menggunakan perintah `ALTER DATABASE`, `ALTER ROLE`, dan `SET`.
## Daftar parameter instans DB RDS for PostgreSQL
Tabel berikut mencantumkan beberapa (tetapi tidak semua) parameter yang tersedia dalam instans DB RDS for PostgreSQL. Untuk melihat semua parameter yang tersedia, Anda menggunakan [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI perintah. Misalnya, untuk mendapatkan daftar semua parameter yang tersedia di grup parameter default untuk RDS for PostgreSQL versi 13, jalankan perintah berikut ini.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Anda juga dapat menggunakan Konsol. Pilih **Grup parameter** dari menu Amazon RDS, lalu pilih grup parameter yang tersedia di menu Wilayah AWS.
| Nama parameter | Apply\$1Type | Deskripsi |
| --- | --- | --- |
| `application_name` | Dinamis | Mengatur nama aplikasi yang akan dilaporkan dalam statistik dan log. |
| `archive_command` | Dinamis | Menetapkan perintah shell yang akan dipanggil untuk mengarsipkan file WAL. |
| `array_nulls` | Dinamis | Memungkinkan input elemen NULL dalam array. |
| `authentication_timeout` | Dinamis | Mengatur waktu maksimum yang diizinkan untuk menyelesaikan autentikasi klien. |
| `autovacuum` | Dinamis | Memulai subproses autovacuum. |
| `autovacuum_analyze_scale_factor` | Dinamis | Jumlah penyisipan, pembaruan, atau penghapusan tuple sebelum dianalisis sebagai pecahan dari reltuple. |
| `autovacuum_analyze_threshold` | Dinamis | Jumlah minimum penyisipan, pembaruan, atau penghapusan tuple sebelum dianalisis. |
| `autovacuum_freeze_max_age` | Statis | Usia untuk melakukan autovacuum tabel guna mencegah penyelesaian ID transaksi. |
| `autovacuum_naptime` | Dinamis | Waktu tidur selama autovacuum berjalan. |
| `autovacuum_max_workers` | Statis | Mengatur jumlah maksimum proses pekerja autovacuum yang berjalan secara bersamaan. |
| `autovacuum_vacuum_cost_delay` | Dinamis | Penundaan biaya vakum, dalam milidetik, untuk autovacuum. |
| `autovacuum_vacuum_cost_limit` | Dinamis | Jumlah biaya vakum yang tersedia sebelum napping, untuk autovacuum. |
| `autovacuum_vacuum_scale_factor` | Dinamis | Jumlah pembaruan atau penghapusan tuple sebelum divakum sebagai pecahan dari retuple. |
| `autovacuum_vacuum_threshold` | Dinamis | Jumlah minimum pembaruan atau penghapusan tuple sebelum divakum. |
| `backslash_quote` | Dinamis | Mengatur apakah garis miring terbalik (\$1) diizinkan dalam string literal atau tidak. |
| `bgwriter_delay` | Dinamis | Waktu tidur latar belakang penulis di sela-sela putaran. |
| `bgwriter_lru_maxpages` | Dinamis | Jumlah maksimum halaman LRU penulis latar belakang yang akan dibersihkan per putaran. |
| `bgwriter_lru_multiplier` | Dinamis | Kelipatan dari penggunaan buffer rata-rata yang akan dikosongkan per putaran. |
| `bytea_output` | Dinamis | Mengatur format output untuk byte. |
| `check_function_bodies` | Dinamis | Memeriksa konten fungsi selama CREATE FUNCTION. |
| `checkpoint_completion_target` | Dinamis | Waktu yang dihabiskan untuk membersihkan buffer kotor selama operasi titik pemeriksaan, sebagai bagian dari interval titik pemeriksaan. |
| `checkpoint_segments` | Dinamis | Mengatur jarak maksimum dalam segmen log antara titik pemeriksaan write-ahead log (WAL). |
| `checkpoint_timeout` | Dinamis | Mengatur waktu maksimum antara titik pemeriksaan WAL otomatis. |
| `checkpoint_warning` | Dinamis | Mengaktifkan peringatan jika segmen titik pemeriksaan diisi lebih sering daripada ini. |
| `client_connection_check_interval` | Dinamis | Menetapkan interval waktu di antara pemeriksaan pemutusan koneksi saat menjalankan kueri. |
| `client_encoding` | Dinamis | Mengatur pengenkodean set karakter klien. |
| `client_min_messages` | Dinamis | Mengatur tingkatan pesan yang dikirimkan kepada klien. |
| `commit_delay` | Dinamis | Mengatur penundaan dalam mikrodetik antara transaksi commit dan melakukan pembersihan WAL ke disk. |
| `commit_siblings` | Dinamis | Mengatur minimum transaksi terbuka serentak sebelum melakukan commit\$1delay. |
| `constraint_exclusion` | Dinamis | Memungkinkan perencana untuk menggunakan batasan agar dapat mengoptimalkan kueri. |
| `cpu_index_tuple_cost` | Dinamis | Menetapkan perkiraan perencana untuk biaya pemrosesan setiap entri indeks selama pemindaian indeks. |
| `cpu_operator_cost` | Dinamis | Menetapkan perkiraan perencana untuk biaya pemrosesan setiap operator atau panggilan fungsi. |
| `cpu_tuple_cost` | Dinamis | Menetapkan perkiraan perencana untuk biaya pemrosesan setiap tuple (baris). |
| `cursor_tuple_fraction` | Dinamis | Menetapkan perkiraan perencana untuk pecahan dari baris kursor yang akan diambil. |
| `datestyle` | Dinamis | Mengatur format tampilan nilai tanggal dan waktu. |
| `deadlock_timeout` | Dinamis | Mengatur waktu menunggu kunci sebelum memeriksa deadlock. |
| `debug_pretty_print` | Dinamis | Mengindentasi tampilan hierarki penguraian dan rencana. |
| `debug_print_parse` | Dinamis | Membuat log hierarki penguraian setiap kueri. |
| `debug_print_plan` | Dinamis | Membuat log rencana eksekusi setiap kueri. |
| `debug_print_rewritten` | Dinamis | Membuat log hierarki penguraian yang ditulis ulang oleh setiap kueri. |
| `default_statistics_target` | Dinamis | Mengatur target statistik default. |
| `default_tablespace` | Dinamis | Mengatur tablespace default untuk membuat tabel dan indeks. |
| `default_transaction_deferrable` | Dinamis | Mengatur status default yang dapat ditangguhkan dari transaksi baru. |
| `default_transaction_isolation` | Dinamis | Menetapkan tingkat isolasi transaksi dari setiap transaksi baru. |
| `default_transaction_read_only` | Dinamis | Mengatur status hanya-baca default dari transaksi baru. |
| `default_with_oids` | Dinamis | Membuat tabel baru dengan object IDs (OIDs) secara default. |
| `effective_cache_size` | Dinamis | Mengatur asumsi perencana ukuran cache disk. |
| `effective_io_concurrency` | Dinamis | Jumlah permintaan serentak yang dapat ditangani secara efisien oleh subsistem disk. |
| `enable_bitmapscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian bitmap oleh perencana. |
| `enable_hashagg` | Dinamis | Memungkinkan penggunaan rencana agregasi hash oleh perencana. |
| `enable_hashjoin` | Dinamis | Memungkinkan penggunaan rencana hash join oleh perencana. |
| `enable_indexscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian indeks oleh perencana. |
| `enable_material` | Dinamis | Memungkinkan penggunaan materialisasi oleh perencana. |
| `enable_mergejoin` | Dinamis | Memungkinkan penggunaan rencana merge join oleh perencana. |
| `enable_nestloop` | Dinamis | Memungkinkan penggunaan rencana nested-loop join oleh perencana. |
| `enable_seqscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian sekuensial oleh perencana. |
| `enable_sort` | Dinamis | Memungkinkan penggunaan langkah singkat eksplisit oleh perencana. |
| `enable_tidscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian TID oleh perencana. |
| `escape_string_warning` | Dinamis | Memperingatkan tentang escape garis miring terbalik (\$1) dalam string literal biasa. |
| `extra_float_digits` | Dinamis | Mengatur jumlah digit yang ditampilkan untuk nilai floating-point. |
| `from_collapse_limit` | Dinamis | Mengatur ukuran daftar FROM yang tidak menciutkan subkueri. |
| `fsync` | Dinamis | Memaksa sinkronisasi pembaruan ke disk. |
| `full_page_writes` | Dinamis | Menulis halaman penuh ke WAL saat pertama kali dimodifikasi setelah titik pemeriksaan. |
| `geqo` | Dinamis | Memungkinkan pengoptimalan kueri genetik. |
| `geqo_effort` | Dinamis | GEQO: upaya digunakan untuk mengatur default parameter GEQO lainnya. |
| `geqo_generations` | Dinamis | GEQO: jumlah iterasi algoritma. |
| `geqo_pool_size` | Dinamis | GEQO: jumlah individu dalam populasi. |
| `geqo_seed` | Dinamis | GEQO: seed untuk pemilihan jalur acak. |
| `geqo_selection_bias` | Dinamis | GEQO: tekanan selektif di dalam populasi. |
| `geqo_threshold` | Dinamis | Mengatur ambang batas item FROM yang menggunakan GEQO. |
| `gin_fuzzy_search_limit` | Dinamis | Mengatur hasil maksimum yang diperbolehkan untuk pencarian akurat oleh GIN. |
| `hot_standby_feedback` | Dinamis | Menentukan apakah hot standby mengirimkan pesan umpan balik ke standby utama atau standby hulu. |
| `intervalstyle` | Dinamis | Mengatur format tampilan nilai interval. |
| `join_collapse_limit` | Dinamis | Menetapkan ukuran daftar FROM yang tidak meratakan konsep JOIN. |
| `lc_messages` | Dinamis | Mengatur bahasa untuk menampilkan pesan. |
| `lc_monetary` | Dinamis | Menetapkan lokal untuk memformat jumlah uang. |
| `lc_numeric` | Dinamis | Mengatur lokal untuk memformat angka. |
| `lc_time` | Dinamis | Mengatur lokal untuk memformat nilai tanggal dan waktu. |
| `log_autovacuum_min_duration` | Dinamis | Mengatur waktu berjalan minimum yang akan membuat log tindakan autovacuum. |
| `log_checkpoints` | Dinamis | Membuat log setiap titik pemeriksaan. |
| `log_connections` | Dinamis | Membuat log setiap koneksi yang berhasil. |
| `log_disconnections` | Dinamis | Membuat log dari akhir sebuah sesi, termasuk durasinya. |
| `log_duration` | Dinamis | Membuat log durasi setiap pernyataan SQL yang diselesaikan. |
| `log_error_verbosity` | Dinamis | Mengatur panjang pesan yang dicatat. |
| `log_executor_stats` | Dinamis | Menulis statistik performa pelaksana ke log server. |
| `log_filename` | Dinamis | Mengatur pola nama file untuk file log. |
| `log_file_mode` | Dinamis | Mengatur izin file untuk file log. Nilai default-nya adalah 0644. |
| `log_hostname` | Dinamis | Membuat log nama host dalam log koneksi. Pada PostgreSQL 12 dan versi yang lebih baru, parameter ini 'nonaktif' secara default. Saat diaktifkan, koneksi akan menggunakan pencarian balik DNS untuk mendapatkan nama host yang terambil ke log koneksi. Jika mengaktifkan parameter ini, Anda harus memantau dampaknya pada waktu yang diperlukan agar dapat membuat koneksi. |
| `log_line_prefix ` | Dinamis | Mengontrol informasi yang diawali untuk setiap baris log. |
| `log_lock_waits` | Dinamis | Membuat log waktu tunggu kunci yang panjang. |
| `log_min_duration_statement` | Dinamis | Menetapkan waktu berjalan minimum yang akan Membuat log pernyataan. |
| `log_min_error_statement` | Dinamis | Menyebabkan semua pernyataan yang menghasilkan kesalahan pada atau di atas level ini dicatat. |
| `log_min_messages` | Dinamis | Mengatur tingkat pesan yang dicatat. |
| `log_parser_stats` | Dinamis | Menulis statistik performa pengurai ke log server. |
| `log_planner_stats` | Dinamis | Menulis statistik performa perencana ke log server. |
| `log_rotation_age` | Dinamis | Rotasi file log otomatis akan terjadi setelah N menit. |
| `log_rotation_size` | Dinamis | Rotasi file log otomatis akan terjadi setelah N kilobita. |
| `log_statement` | Dinamis | Mengatur jenis pernyataan yang dicatat. |
| `log_statement_stats` | Dinamis | Menulis statistik performa kumulatif ke log server. |
| `log_temp_files` | Dinamis | Membuat log penggunaan file sementara yang lebih besar dari angka kilobyte ini. |
| `log_timezone` | Dinamis | Mengatur zona waktu yang akan digunakan dalam pesan log. |
| `log_truncate_on_rotation` | Dinamis | Memotong file log yang ada dengan nama yang sama selama rotasi log. |
| `logging_collector` | Statis | Mulai subproses untuk menangkap and/or csvlog keluaran stderr ke dalam file log. |
| `maintenance_work_mem` | Dinamis | Mengatur memori maksimum yang akan digunakan untuk operasi pemeliharaan. |
| `max_connections` | Statis | Mengatur jumlah maksimum koneksi serentak. |
| `max_files_per_process` | Statis | Mengatur jumlah maksimum file yang terbuka secara bersamaan untuk setiap proses server. |
| `max_locks_per_transaction` | Statis | Menetapkan jumlah maksimum kunci per transaksi. |
| `max_pred_locks_per_transaction` | Statis | Menetapkan jumlah maksimum kunci predikat per transaksi. |
| `max_prepared_transactions` | Statis | Menetapkan jumlah maksimum transaksi yang disiapkan secara bersamaan. |
| `max_stack_depth` | Dinamis | Mengatur kedalaman tumpukan maksimum, dalam kilobita. |
| `max_standby_archive_delay` | Dinamis | Mengatur penundaan maksimum sebelum membatalkan kueri saat hot standby sedang memproses data WAL yang diarsipkan. |
| `max_standby_streaming_delay` | Dinamis | Mengatur penundaan maksimum sebelum membatalkan kueri saat hot standby sedang memproses data WAL yang dialirkan. |
| max\$1wal\$1size | Dinamis | Menetapkan ukuran WAL (MB) yang memicu titik pemeriksaan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Gunakan perintah berikut pada instans Amazon RDS for PostgreSQL DB untuk melihat nilainya saat ini:
SHOW max_wal_size;
|
| min\$1wal\$1size | Dinamis | Mengatur ukuran minimum untuk menyusutkan WAL. Untuk PostgreSQL versi 9.6 dan yang sebelumnya, pengaturan min\$1wal\$1size berada dalam unit 16 MB. Untuk PostgreSQL versi 10 dan yang lebih baru, pengaturan min\$1wal\$1size berada dalam unit 1 MB. |
| `quote_all_identifiers` | Dinamis | Menambahkan tanda kutip (") ke semua pengidentifikasi ketika membuat fragmen SQL. |
| `random_page_cost` | Dinamis | Mengatur perkiraan perencana untuk biaya dari halaman disk yang diambil secara tidak berurutan. Parameter ini tidak memiliki nilai kecuali manajemen rencana kueri (QPM) diaktifkan. Saat QPM aktif, nilai default-nya adalah 4. |
| rds.adaptive\$1autovacuum | Dinamis | Secara otomatis menyesuaikan parameter autovacuum setiap kali ambang batas ID transaksi terlampaui. |
| rds.force\$1ssl | Dinamis | Membutuhkan penggunaan koneksi SSL. Nilai default diatur ke 1 (aktif) untuk RDS for PostgreSQL versi 15. Semua RDS for PostgreSQL versi utama 14 lainnya dan yang lebih lama memiliki nilai default yang disetel ke 0 (nonaktif). |
| `rds.local_volume_spill_enabled` | Statis | Memungkinkan penulisan file tumpahan logis ke volume lokal. |
| `rds.log_retention_period` | Dinamis | Mengatur retensi log sedemikian rupa sehingga Amazon RDS dapat menghapus log PostgreSQL yang lebih lama dari n menit. |
| rds.rds\$1superuser\$1reserved\$1connections | Statis | Menetapkan jumlah slot koneksi yang disediakan untuk rds\$1superusers. Parameter ini hanya tersedia dalam versi 15 dan sebelumnya. [Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL reserved\$1connections.](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS) |
| `rds.replica_identity_full` | Dinamis | Ketika Anda mengatur parameter ini ke`on`, itu akan mengganti pengaturan identitas replika `FULL` untuk semua tabel database. Ini berarti semua nilai kolom ditulis ke log tulis depan (WAL), terlepas dari `REPLICA IDENTITY FULL` pengaturan Anda. Mengaktifkan parameter ini dapat meningkatkan IOPS instance database Anda karena pencatatan WAL tambahan. |
| rds.restrict\$1password\$1commands | Statis | Membatasi individu yang dapat mengelola kata sandi untuk pengguna yang memiliki peran rds\$1password. Atur parameter ini ke 1 untuk mengaktifkan pembatasan kata sandi. Default-nya adalah 0. |
| `search_path` | Dinamis | Menetapkan urutan pencarian skema untuk nama yang tidak memenuhi syarat skema. |
| `seq_page_cost` | Dinamis | Mengatur perkiraan perencana untuk biaya dari halaman disk yang diambil secara berurutan. |
| `session_replication_role` | Dinamis | Menetapkan perilaku sesi untuk pemicu dan aturan penulisan ulang. |
| `shared_buffers` | Statis | Mengatur jumlah buffer memori bersama yang digunakan oleh server. |
| `shared_preload_libraries ` | Statis | Memigrasi pustaka bersama untuk dimuat ke instans DB RDS for PostgreSQL. Nilai yang didukung meliputi auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler, dan plrust. |
| `ssl` | Dinamis | Mengaktifkan koneksi SSL. |
| `sql_inheritance` | Dinamis | Menyebabkan subtabel disertakan secara default dalam berbagai perintah. |
| `ssl_renegotiation_limit` | Dinamis | Menetapkan jumlah lalu lintas untuk dikirim dan diterima sebelum melakukan negosiasi ulang kunci enkripsi. |
| `standard_conforming_strings` | Dinamis | Menyebabkan string ... memperlakukan garis miring terbalik secara literal. |
| `statement_timeout` | Dinamis | Menetapkan durasi maksimum yang diizinkan untuk setiap pernyataan. |
| `synchronize_seqscans` | Dinamis | Memungkinkan pemindaian berurutan yang disinkronkan. |
| `synchronous_commit` | Dinamis | Mengatur tingkat sinkronisasi transaksi saat ini. |
| `tcp_keepalives_count` | Dinamis | Jumlah maksimum pengiriman ulang keepalive TCP. |
| `tcp_keepalives_idle` | Dinamis | Waktu antara penerbitan keepalive TCP. |
| `tcp_keepalives_interval` | Dinamis | Waktu antara pengiriman ulang keepalive TCP. |
| `temp_buffers` | Dinamis | Mengatur jumlah maksimum buffer sementara yang digunakan oleh setiap sesi. |
| temp\$1file\$1limit | Dinamis | Mengatur ukuran maksimum file sementara dapat berkembang dalam KB. |
| `temp_tablespaces` | Dinamis | Mengatur tablespace yang akan digunakan untuk tabel sementara dan mengurutkan file. |
| `timezone` | Dinamis | Mengatur zona waktu untuk menampilkan dan menginterpretasikan stempel waktu. Internet Assigned Numbers Authority (IANA) menerbitkan zona waktu baru di [https://www.iana.org/time-zones](https://www.iana.org/time-zones) beberapa kali dalam setahun. Setiap kali RDS mengeluarkan rilis pemeliharaan minor PostgreSQL yang baru, rilis tersebut akan dikirimkan beserta data zona waktu terbaru pada saat rilis. Jika menggunakan versi RDS for PostgreSQL terbaru, Anda akan memiliki data zona waktu terbaru dari RDS. Untuk memastikan bahwa instans DB Anda memiliki data zona waktu terbaru, sebaiknya tingkatkan ke versi mesin DB yang lebih baru. Anda tidak dapat mengubah tabel zona waktu dalam instans DB PostgreSQL secara manual. RDS tidak memodifikasi atau mengatur ulang data zona waktu dari instans DB yang berjalan. Data zona waktu baru diinstal hanya ketika Anda melakukan peningkatan versi mesin basis data. |
| `track_activities` | Dinamis | Mengumpulkan informasi cara menjalankan perintah. |
| `track_activity_query_size` | Statis | Mengatur ukuran terpesan untuk pg\$1stat\$1activity.current\$1query, dalam byte. |
| `track_counts` | Dinamis | Mengumpulkan statistik aktivitas basis data. |
| `track_functions` | Dinamis | Mengumpulkan statistik tingkat fungsi aktivitas basis data. |
| `track_io_timing` | Dinamis | Mengumpulkan statistik waktu pada I/O aktivitas database. |
| `transaction_deferrable` | Dinamis | Menunjukkan apakah akan menunda transaksi hanya-baca berseri sampai bisa dimulai tanpa ada kegagalan serialisasi. |
| `transaction_isolation` | Dinamis | Menetapkan tingkat isolasi transaksi saat ini. |
| `transaction_read_only` | Dinamis | Mengatur status hanya-baca transaksi saat ini. |
| `transform_null_equals` | Dinamis | Memperlakukan expr=NULL sebagai expr IS NULL. |
| `update_process_title` | Dinamis | Memperbarui judul proses untuk menampilkan perintah SQL yang aktif. |
| `vacuum_cost_delay` | Dinamis | Penundaan biaya vakum dalam milidetik. |
| `vacuum_cost_limit` | Dinamis | Jumlah biaya vakum yang tersedia sebelum napping. |
| `vacuum_cost_page_dirty` | Dinamis | Biaya vakum untuk halaman yang kotor karena vakum. |
| `vacuum_cost_page_hit` | Dinamis | Biaya vakum untuk halaman yang ditemukan di cache buffer. |
| `vacuum_cost_page_miss` | Dinamis | Biaya vakum untuk halaman yang tidak ditemukan dalam cache buffer. |
| `vacuum_defer_cleanup_age` | Dinamis | Jumlah transaksi yang harus ditangguhkan dengan vakum dan hot cleanup, jika ada. |
| `vacuum_freeze_min_age` | Dinamis | Usia minimum saat vakum harus membekukan baris tabel. |
| `vacuum_freeze_table_age` | Dinamis | Usia saat vakum harus memindai seluruh tabel untuk membekukan tuple. |
| `wal_buffers` | Statis | Mengatur jumlah buffer halaman disk dalam memori bersama untuk WAL. |
| `wal_writer_delay` | Dinamis | Waktu tidur penulis WAL antara beberapa pengosongan WAL. |
| `work_mem` | Dinamis | Mengatur memori maksimum yang akan digunakan untuk ruang kerja kueri. |
| `xmlbinary` | Dinamis | Menetapkan cara pengenkodean nilai biner dalam XML. |
| `xmloption` | Dinamis | Menetapkan apakah data XML dalam operasi penguraian implisit dan serialisasi dianggap sebagai dokumen atau fragmen konten. |
Amazon RDS menggunakan unit PostgreSQL default untuk semua parameter. Tabel berikut menunjukkan unit default PostgreSQL untuk setiap parameter.
| Nama parameter | Unit |
| --- | --- |
| `archive_timeout` | detik |
| `authentication_timeout` | detik |
| `autovacuum_naptime` | detik |
| `autovacuum_vacuum_cost_delay` | milidetik |
| `bgwriter_delay` | milidetik |
| `checkpoint_timeout` | detik |
| `checkpoint_warning` | detik |
| `deadlock_timeout` | milidetik |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | milidetik |
| `log_autovacuum_min_duration` | milidetik |
| `log_min_duration_statement` | milidetik |
| `log_rotation_age` | menit |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | milidetik |
| `max_standby_streaming_delay` | milidetik |
| `post_auth_delay` | detik |
| `pre_auth_delay` | detik |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | milidetik |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | detik |
| `tcp_keepalives_interval` | detik |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | milidetik |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | milidetik |
| `wal_segment_size` | B |
| `wal_sender_timeout` | milidetik |
| `wal_writer_delay` | milidetik |
| `wal_receiver_status_interval` | detik |
# Menyetel dengan peristiwa tunggu di RDS for PostgreSQL
Peristiwa tunggu adalah alat penyetelan penting untuk RDS for PostgreSQL. Ketika Anda dapat mengetahui mengapa sesi menunggu sumber daya dan apa yang sedang dilakukan, Anda lebih mampu mengurangi kemacetan. Anda dapat menggunakan informasi di bagian ini untuk menemukan kemungkinan penyebab dan tindakan korektif. Bagian ini juga membahas konsep penyetelan dasar PostgreSQL.
Peristiwa tunggu di bagian ini spesifik untuk RDS for PostgreSQL.
**Topics**
+ [Konsep penting dalam penyetelan RDS for PostgreSQL](PostgreSQL.Tuning.concepts.md)
+ [Peristiwa tunggu RDS for PostgreSQL](PostgreSQL.Tuning.concepts.summary.md)
+ [Klien: ClientRead](wait-event.clientread.md)
+ [Klien: ClientWrite](wait-event.clientwrite.md)
+ [CPU](wait-event.cpu.md)
+ [IO: BufFileRead dan IO: BufFileWrite](wait-event.iobuffile.md)
+ [IO: DataFileRead](wait-event.iodatafileread.md)
+ [IO: WALWrite](wait-event.iowalwrite.md)
+ [IPC: Acara tunggu paralel](rpg-ipc-parallel.md)
+ [IPC: ProcArrayGroupUpdate](apg-rpg-ipcprocarraygroup.md)
+ [Lock:advisory](wait-event.lockadvisory.md)
+ [Lock:extend](wait-event.lockextend.md)
+ [Lock:Relation](wait-event.lockrelation.md)
+ [Lock:transactionid](wait-event.locktransactionid.md)
+ [Lock:tuple](wait-event.locktuple.md)
+ [LWLock: BufferMapping (:buffer\$1mapping) LWLock](wait-event.lwl-buffer-mapping.md)
+ [LWLock:Bufferio (IPC: Bufferio)](wait-event.lwlockbufferio.md)
+ [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md)
+ [LWLock:lock\$1manager (manajer kunci) LWLock](wait-event.lw-lock-manager.md)
+ [LWLock:pg\$1stat\$1statement](apg-rpg-lwlockpgstat.md)
+ [LWLock:subtransslru (:) LWLock SubtransControlLock](wait-event.lwlocksubtransslru.md)
+ [Timeout:PgSleep](wait-event.timeoutpgsleep.md)
+ [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md)
# Konsep penting dalam penyetelan RDS for PostgreSQL
Sebelum Anda menyetel basis data RDS for PostgreSQL, pastikan untuk mempelajari apa itu peristiwa tunggu dan mengapa peristiwa tersebut terjadi. Baca juga memori dasar dan arsitektur disk RDS for PostgreSQL. Anda dapat melihat diagram arsitektur yang berguna di wikibook [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture).
**Topics**
+ [Peristiwa tunggu RDS for PostgreSQL](PostgreSQL.Tuning.concepts.waits.md)
+ [Memori RDS for PostgreSQL](PostgreSQL.Tuning.concepts.memory.md)
+ [Proses RDS for PostgreSQL](PostgreSQL.Tuning.concepts.processes.md)
# Peristiwa tunggu RDS for PostgreSQL
*Peristiwa tunggu* menunjukkan bahwa sesi sedang menunggu sumber daya. Misalnya, peristiwa tunggu `Client:ClientRead` terjadi ketika RDS for PostgreSQL menunggu untuk menerima data dari klien. Sesi biasanya menunggu sumber daya seperti berikut ini.
+ Akses thread tunggal ke buffer, misalnya, saat sesi mencoba memodifikasi buffer
+ Baris yang saat ini dikunci oleh sesi lain
+ Pembacaan file data
+ Penulisan file log
Misalnya, untuk memenuhi kueri, sesi mungkin melakukan pemindaian tabel lengkap. Jika data belum ada dalam memori, sesi menunggu disk I/O selesai. Ketika buffer dibaca ke dalam memori, sesi mungkin perlu menunggu karena sesi lain mengakses buffer yang sama. Basis data mencatat peristiwa tunggu dengan menggunakan peristiwa tunggu standar. Peristiwa tersebut dikelompokkan ke dalam kategori.
Dengan sendirinya, satu peristiwa tunggu tidak menunjukkan masalah performa. Misalnya, jika data yang diminta tidak ada dalam memori, data perlu dibaca dari disk. Jika satu sesi mengunci baris untuk pembaruan, sesi lain akan menunggu baris tersebut dibuka sehingga dapat memperbaruinya. Komit perlu menunggu penulisan ke file log selesai. Peristiwa tunggu merupakan bagian integral dari fungsi normal basis data.
Di sisi lain, sejumlah besar peristiwa tunggu biasanya menunjukkan masalah performa. Dalam kasus seperti itu, Anda dapat menggunakan data peristiwa tunggu untuk menentukan tempat sesi menghabiskan waktu. Misalnya, jika laporan yang biasanya berjalan dalam hitungan menit sekarang berjalan selama berjam-jam, Anda dapat mengidentifikasi peristiwa tunggu yang berkontribusi paling besar terhadap total waktu tunggu. Jika Anda dapat menentukan penyebab peristiwa tunggu teratas, terkadang Anda dapat membuat perubahan yang meningkatkan performa. Misalnya, jika sesi Anda menunggu pada baris yang telah dikunci oleh sesi lain, Anda dapat mengakhiri sesi penguncian.
# Memori RDS for PostgreSQL
Memori RDS for PostgreSQL dibagi menjadi bersama dan lokal.
**Topics**
+ [Memori bersama dalam RDS for PostgreSQL](#PostgreSQL.Tuning.concepts.shared)
+ [Memori lokal dalam RDS for PostgreSQL](#PostgreSQL.Tuning.concepts.local)
## Memori bersama dalam RDS for PostgreSQL
RDS for PostgreSQL mengalokasikan memori bersama saat instans dimulai. Memori bersama dibagi menjadi beberapa sub-area. Bagian berikut memberikan deskripsi yang paling penting.
**Topics**
+ [Buffer bersama](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [Buffer log write ahead (WAL)](#PostgreSQL.Tuning.concepts.WAL)
### Buffer bersama
*Kumpulan buffer bersama* adalah area memori RDS for PostgreSQL yang menampung semua halaman yang sedang atau telah digunakan oleh koneksi aplikasi. *Halaman* adalah versi memori dari blok disk. Kumpulan buffer bersama menyimpan blok data yang dibaca dari disk. Kumpulan tersebut mengurangi kebutuhan untuk membaca ulang data dari disk, sehingga membuat basis data beroperasi lebih efisien.
Setiap tabel dan indeks disimpan sebagai array halaman dengan ukuran tetap. Setiap blok berisi beberapa tuple, yang sesuai dengan baris. Tuple dapat disimpan di halaman mana pun.
Kumpulan buffer bersama memiliki memori terbatas. Jika permintaan baru memerlukan halaman yang tidak ada dalam memori, dan memori sudah tidak ada lagi, RDS for PostgreSQL mengosongkan halaman yang jarang digunakan untuk mengakomodasi permintaan tersebut. Kebijakan pengosongan diimplementasikan oleh algoritma clock sweep.
Parameter `shared_buffers` menentukan berapa banyak memori server dikhususkan untuk menyimpan data dalam cache. Nilai default diatur ke `{DBInstanceClassMemory/32768}` byte, berdasarkan memori yang tersedia untuk instans DB.
### Buffer log write ahead (WAL)
*Buffer log write-ahead (WAL)* menyimpan data transaksi yang kemudian ditulis RDS for PostgreSQL ke penyimpanan persisten. Menggunakan mekanisme WAL, RDS for PostgreSQL dapat melakukan hal berikut:
+ Memulihkan data setelah kegagalan
+ Kurangi disk I/O dengan menghindari sering menulis ke disk
Ketika klien mengubah data, RDS for PostgreSQL menulis perubahan ke buffer WAL. Ketika klien mengeluarkan `COMMIT`, proses penulis WAL menulis data transaksi ke file WAL.
`wal_level`Parameter menentukan berapa banyak informasi yang ditulis ke WAL, dengan nilai yang mungkin seperti`minimal`,`replica`, dan`logical`.
## Memori lokal dalam RDS for PostgreSQL
Setiap proses backend mengalokasikan memori lokal untuk pemrosesan kueri.
**Topics**
+ [Area memori kerja](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [Area memori kerja pemeliharaan](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [Area buffer sementara](#PostgreSQL.Tuning.concepts.temp)
### Area memori kerja
*Area memori kerja* menyimpan data sementara untuk kueri yang melakukan pengurutan dan hash. Misalnya, kueri dengan klausa `ORDER BY` melakukan pengurutan. Kueri menggunakan tabel hash dalam gabungan dan agregasi hash.
`work_mem`Parameter jumlah memori yang akan digunakan oleh operasi pengurutan internal dan tabel hash sebelum menulis ke file disk sementara, diukur dalam megabyte. Nilai default-nya adalah 4 MB. Beberapa sesi dapat berjalan secara bersamaan, dan setiap sesi dapat menjalankan operasi pemeliharaan secara paralel. Karena alasan ini, total memori kerja yang digunakan dapat menjadi kelipatan dari pengaturan `work_mem`.
### Area memori kerja pemeliharaan
*Area memori kerja pemeliharaan* menyimpan data untuk operasi pemeliharaan. Operasi ini termasuk memvakum, membuat indeks, dan menambahkan kunci asing.
`maintenance_work_mem`Parameter menentukan jumlah maksimum memori yang akan digunakan oleh operasi pemeliharaan, diukur dalam megabyte. Nilai default-nya adalah 64 MB. Sebuah sesi basis data hanya dapat menjalankan satu operasi pemeliharaan dalam satu waktu.
### Area buffer sementara
*Area buffer sementara* menyimpan tabel sementara untuk setiap sesi basis data.
Setiap sesi mengalokasikan buffer sementara sesuai kebutuhan hingga batas yang Anda tentukan. Saat sesi berakhir, server menghapus buffer.
`temp_buffers`Parameter menetapkan jumlah maksimum buffer sementara yang digunakan oleh setiap sesi, diukur dalam megabyte. Nilai defaultnya adalah 8 MB. Sebelum penggunaan pertama tabel sementara dalam sesi, Anda dapat mengubah nilai `temp_buffers`.
# Proses RDS for PostgreSQL
RDS for PostgreSQL menggunakan beberapa proses.
**Topics**
+ [Proses postmaster](#PostgreSQL.Tuning.concepts.postmaster)
+ [Proses backend](#PostgreSQL.Tuning.concepts.backend)
+ [Proses latar belakang](#PostgreSQL.Tuning.concepts.vacuum)
## Proses postmaster
*Proses postmaster* adalah proses pertama yang dimulai ketika Anda memulai RDS for PostgreSQL. Proses postmaster memiliki tanggung jawab utama berikut:
+ Membagi dan memantau proses latar belakang
+ Menerima permintaan autentikasi dari proses klien, dan mengautentikasi permintaan sebelum mengizinkan basis data untuk melayani permintaan
## Proses backend
Jika postmaster mengautentikasi permintaan klien, postmaster akan melakukan proses backend baru, juga disebut proses postgres. Satu proses klien terhubung ke persis satu proses backend. Proses klien dan proses backend berkomunikasi secara langsung tanpa intervensi oleh proses postmaster.
## Proses latar belakang
Proses postmaster membagi beberapa proses yang melakukan tugas backend yang berbeda. Beberapa hal yang lebih penting termasuk berikut ini:
+ Penulis WAL
RDS for PostgreSQL menulis data dalam buffer WAL (log write ahead) ke file log. Prinsip log write ahead adalah bahwa basis data tidak dapat menulis perubahan pada file data sampai setelah basis data menulis catatan log yang menjelaskan perubahan tersebut ke disk. Mekanisme WAL mengurangi disk I/O, dan memungkinkan RDS for PostgreSQL untuk menggunakan log untuk memulihkan basis data setelah kegagalan.
+ Penulis latar belakang
Proses ini secara berkala menulis halaman kotor (diubah) dari buffer memori ke file data. Sebuah halaman menjadi kotor ketika proses backend memodifikasinya dalam memori.
+ Daemon autovacuum
Daemon terdiri dari hal-hal berikut:
+ Peluncur autovacuum
+ Proses pekerja autovacuum
Saat autovacuum diaktifkan, autovacuum tersebut memeriksa tabel yang memiliki banyak tuple yang dimasukkan, diperbarui, atau dihapus. Daemon memiliki tanggung jawab sebagai berikut:
+ Memulihkan atau menggunakan kembali ruang disk yang ditempati oleh baris yang diperbarui atau dihapus
+ Memperbarui statistik yang digunakan oleh perencana
+ Melindungi dari kehilangan data lama karena wraparound ID transaksi
Fitur autovacuum mengotomatiskan eksekusi `VACUUM` dan perintah `ANALYZE`. `VACUUM` memiliki varian berikut: standar dan penuh. Vakum standar berjalan secara paralel dengan operasi basis data lainnya. `VACUUM FULL` membutuhkan kunci eksklusif di tabel yang sedang dikerjakannya. Dengan demikian, tidak dapat berjalan secara paralel dengan operasi yang mengakses tabel yang sama. `VACUUM`menciptakan sejumlah besar I/O lalu lintas, yang dapat menyebabkan kinerja yang buruk untuk sesi aktif lainnya.
# Peristiwa tunggu RDS for PostgreSQL
Tabel berikut mencantumkan peristiwa tunggu untuk RDS for PostgreSQL yang paling sering menunjukkan masalah performa, dan meringkas penyebab paling umum dan tindakan korektifnya.
| Peristiwa tunggu | Definisi |
| --- | --- |
| [Klien: ClientRead](wait-event.clientread.md) | Peristiwa ini terjadi ketika RDS for PostgreSQL menunggu untuk menerima data dari klien. |
| [Klien: ClientWrite](wait-event.clientwrite.md) | Peristiwa ini terjadi ketika RDS for PostgreSQL menunggu untuk menulis data ke klien. |
| [CPU](wait-event.cpu.md) | Peristiwa ini terjadi saat thread aktif di CPU atau sedang menunggu CPU. |
| [IO: BufFileRead dan IO: BufFileWrite](wait-event.iobuffile.md) | Peristiwa ini terjadi ketika RDS for PostgreSQL membuat file sementara. |
| [IO: DataFileRead](wait-event.iodatafileread.md) | Peristiwa ini terjadi ketika koneksi menunggu pada proses backend untuk membaca halaman yang diperlukan dari penyimpanan karena halaman tidak tersedia dalam memori bersama. |
| [IO: WALWrite](wait-event.iowalwrite.md) | Peristiwa ini terjadi ketika RDS for PostgreSQL sedang menunggu buffer write-ahead log (WAL) ditulis ke file WAL. |
| [Lock:advisory](wait-event.lockadvisory.md) | Peristiwa ini terjadi ketika aplikasi PostgreSQL menggunakan kunci untuk mengoordinasikan aktivitas di beberapa sesi. |
| [Lock:extend](wait-event.lockextend.md) | Peristiwa ini terjadi ketika proses backend menunggu untuk mengunci relasi untuk memperpanjangnya selagi proses lain memiliki kunci pada relasi itu untuk tujuan yang sama. |
| [Lock:Relation](wait-event.lockrelation.md) | Peristiwa ini terjadi ketika kueri menunggu untuk memperoleh kunci pada tabel atau tampilan yang saat ini dikunci oleh transaksi lain. |
| [Lock:transactionid](wait-event.locktransactionid.md) | Peristiwa ini terjadi ketika transaksi sedang menunggu kunci tingkat baris. |
| [Lock:tuple](wait-event.locktuple.md) | Peristiwa ini terjadi ketika proses backend menunggu untuk mendapatkan kunci pada tuple. |
| [LWLock: BufferMapping (:buffer\$1mapping) LWLock](wait-event.lwl-buffer-mapping.md) | Peristiwa ini terjadi ketika sesi menunggu untuk mengaitkan blok data dengan buffer di kolam buffer bersama. |
| [LWLock:Bufferio (IPC: Bufferio)](wait-event.lwlockbufferio.md) | Peristiwa ini terjadi ketika RDS untuk PostgreSQL sedang menunggu proses lain untuk menyelesaikan operasi (I/O) input/output mereka ketika secara bersamaan mencoba mengakses halaman. |
| [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md) | Peristiwa ini terjadi ketika suatu sesi menunggu untuk membaca atau menulis halaman data di memori selagi sesi lain mengunci halaman tersebut untuk penulisan. |
| [LWLock:lock\$1manager (manajer kunci) LWLock](wait-event.lw-lock-manager.md) | Peristiwa ini terjadi saat mesin RDS for PostgreSQL mempertahankan area memori kunci bersama untuk mengalokasikan, memeriksa, dan mendealokasikan kunci saat kunci jalur cepat tidak memungkinkan. |
| [LWLock:subtransslru (:) LWLock SubtransControlLock](wait-event.lwlocksubtransslru.md) | Peristiwa ini terjadi ketika proses sedang menunggu untuk mengakses cache sederhana yang paling tidak baru digunakan (SLRU) untuk subtransaksi. |
| [Timeout:PgSleep](wait-event.timeoutpgsleep.md) | Peristiwa ini terjadi ketika proses server telah memanggil fungsi `pg_sleep` dan menunggu batas waktu tidur berakhir. |
| [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md) | Peristiwa ini menunjukkan bahwa proses vakum sedang tidur karena perkiraan batas biaya telah tercapai. |
# Klien: ClientRead
Peristiwa `Client:ClientRead` terjadi ketika RDS for PostgreSQL menunggu untuk menerima data dari klien.
**Topics**
+ [Versi mesin yang didukung](#wait-event.clientread.context.supported)
+ [Konteks](#wait-event.clientread.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.clientread.causes)
+ [Tindakan](#wait-event.clientread.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk RDS for PostgreSQL versi 10 dan yang lebih tinggi.
## Konteks
Instans DB RDS for PostgreSQL menunggu untuk menerima data dari klien. Instans DB RDS for PostgreSQL harus menerima data dari klien sebelum dapat mengirim lebih banyak data ke klien. Waktu instans menunggu sebelum menerima data dari klien adalah sebuah peristiwa `Client:ClientRead`.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Penyebab umum peristiwa `Client:ClientRead` muncul dalam peristiwa tunggu teratas mencakup yang berikut:
**Peningkatan latensi jaringan**
Mungkin terdapat peningkatan latensi jaringan antara instans DB RDS for PostgreSQL dan klien. Latensi jaringan yang lebih tinggi meningkatkan waktu yang dibutuhkan instans DB untuk menerima data dari klien.
**Peningkatan beban pada klien**
Mungkin terdapat tekanan CPU atau saturasi jaringan pada klien. Peningkatan beban pada klien dapat menunda transmisi data dari klien ke instans DB RDS for PostgreSQL.
**Round trip jaringan yang berlebihan**
Sejumlah besar round trip jaringan antara instans DB RDS for PostgreSQL dan klien dapat menunda transmisi data dari klien ke instans DB RDS for PostgreSQL.
**Operasi penyalinan besar**
Selama operasi penyalinan, data ditransfer dari sistem file klien ke instans DB RDS for PostgreSQL. Mengirim sejumlah besar data ke instans DB dapat menunda transmisi data dari klien ke instans DB.
**Koneksi klien idle**
Ketika klien terhubung ke instans DB RDS for PostgreSQL dalam status `idle in transaction`, instans DB ini mungkin menunggu klien mengirim lebih banyak data atau memberikan perintah. Koneksi dalam keadaan ini dapat menyebabkan peningkatan peristiwa `Client:ClientRead`.
**PgBouncer digunakan untuk penyatuan koneksi**
PgBouncer memiliki pengaturan konfigurasi jaringan tingkat rendah yang disebut`pkt_buf`, yang diatur ke 4.096 secara default. Jika beban kerja mengirimkan paket kueri yang lebih besar dari 4.096 byte PgBouncer, kami sarankan untuk meningkatkan pengaturan menjadi 8.192. `pkt_buf` Jika pengaturan baru tidak mengurangi jumlah peristiwa `Client:ClientRead`, sebaiknya tingkatkan pengaturan `pkt_buf` ke nilai yang lebih besar, seperti 16.384 atau 32.768. Jika teks kueri berukuran besar, pengaturan yang lebih besar dapat sangat membantu.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Tempatkan klien di Zona Ketersediaan dan subnet VPC yang sama dengan instans.](#wait-event.clientread.actions.az-vpc-subnet)
+ [Skalakan klien Anda](#wait-event.clientread.actions.scale-client)
+ [Gunakan instans generasi saat ini](#wait-event.clientread.actions.db-instance-class)
+ [Meningkatkan bandwidth jaringan](#wait-event.clientread.actions.increase-network-bandwidth)
+ [Pantau nilai maksimum untuk performa jaringan](#wait-event.clientread.actions.monitor-network-performance)
+ [Pantau transaksi dalam status "idle dalam transaksi"](#wait-event.clientread.actions.check-idle-in-transaction)
### Tempatkan klien di Zona Ketersediaan dan subnet VPC yang sama dengan instans.
Untuk mengurangi latensi jaringan dan meningkatkan throughput jaringan, tempatkan klien di Zona Ketersediaan dan subnet cloud privat virtual (VPC) yang sama dengan instans DB RDS for PostgreSQL. Pastikan bahwa klien secara geografis sedekat mungkin dengan instans DB.
### Skalakan klien Anda
Menggunakan Amazon CloudWatch atau metrik host lainnya, tentukan apakah klien Anda saat ini dibatasi oleh CPU atau bandwidth jaringan, atau keduanya. Jika klien dibatasi, skalakan klien sesuai yang diperlukan.
### Gunakan instans generasi saat ini
Dalam kasus tertentu, Anda mungkin tidak menggunakan kelas instans DB yang mendukung frame jumbo. Jika Anda menjalankan aplikasi di Amazon EC2, pertimbangkan untuk menggunakan instans generasi saat ini untuk klien. Selain itu, konfigurasikan unit transmisi maksimum (MTU) pada sistem operasi klien. Teknik ini dapat mengurangi jumlah round trip jaringan dan meningkatkan throughput jaringan. Untuk informasi selengkapnya, lihat [Jumbo frame (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) di Panduan Pengguna *Amazon EC2*.
Untuk informasi tentang kelas instans DB, lihat [ DB](Concepts.DBInstanceClass.md). Untuk menentukan kelas instans DB yang setara dengan jenis instans Amazon EC2, tempatkan `db.` sebelum nama jenis instans Amazon EC2. Misalnya, instans Amazon EC2 `r5.8xlarge` setara dengan kelas instans DB `db.r5.8xlarge`.
### Meningkatkan bandwidth jaringan
Gunakan `NetworkReceiveThroughput` dan CloudWatch metrik `NetworkTransmitThroughput` Amazon untuk memantau lalu lintas jaringan masuk dan keluar pada instans DB. Metrik ini dapat membantu mengetahui apakah bandwidth jaringan cukup untuk beban kerja Anda.
Jika bandwidth jaringan Anda tidak cukup, tingkatkan. Jika AWS klien atau instans DB Anda mencapai batas bandwidth jaringan, satu-satunya cara untuk meningkatkan bandwidth adalah dengan meningkatkan ukuran instans DB Anda. Untuk informasi selengkapnya, lihat [Jenis kelas instans DB](Concepts.DBInstanceClass.Types.md).
Untuk informasi selengkapnya tentang CloudWatch metrik, lihat[CloudWatch Metrik Amazon untuk Amazon RDS](rds-metrics.md).
### Pantau nilai maksimum untuk performa jaringan
Jika Anda menggunakan klien Amazon EC2, Amazon EC2 menyediakan nilai maksimum untuk metrik performa jaringan, termasuk bandwidth jaringan masuk dan keluar agregat. Amazon EC2 juga menyediakan pelacakan koneksi untuk memastikan paket dikembalikan sebagaimana diharapkan dan akses layanan tautan-lokal untuk layanan seperti Sistem Nama Domain (DNS). Untuk memantau nilai maksimum ini, gunakan driver jaringan yang ditingkatkan saat ini dan pantau performa jaringan untuk klien Anda.
*Untuk informasi selengkapnya, lihat [Memantau kinerja jaringan untuk instans Amazon EC2 Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) di Panduan *Pengguna Amazon EC2* [dan Memantau kinerja jaringan untuk instans Amazon EC2 Anda di Panduan Pengguna Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html).*
### Pantau transaksi dalam status "idle dalam transaksi"
Periksa apakah Anda memiliki peningkatan jumlah koneksi `idle in transaction`. Untuk melakukannya, pantau kolom `state` dalam tabel `pg_stat_activity`. Anda mungkin dapat mengidentifikasi sumber koneksi dengan menjalankan kueri seperti yang berikut ini.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```
# Klien: ClientWrite
Peristiwa `Client:ClientWrite` terjadi ketika RDS for PostgreSQL menunggu untuk menulis data ke klien.
**Topics**
+ [Versi mesin yang didukung](#wait-event.clientwrite.context.supported)
+ [Konteks](#wait-event.clientwrite.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.clientwrite.causes)
+ [Tindakan](#wait-event.clientwrite.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk RDS for PostgreSQL versi 10 dan yang lebih tinggi.
## Konteks
Proses klien harus membaca semua data yang diterima dari klaster DB RDS for PostgreSQL sebelum klaster dapat mengirim lebih banyak data. Waktu klaster menunggu sebelum mengirim lebih banyak data ke klien adalah sebuah peristiwa `Client:ClientWrite`.
Throughput jaringan yang berkurang untuk instans DB RDS for PostgreSQL dan klien dapat menyebabkan peristiwa ini. Tekanan CPU dan saturasi jaringan pada klien juga dapat menyebabkan peristiwa ini. *Tekanan CPU* adalah ketika CPU sepenuhnya digunakan dan ada tugas yang menunggu waktu CPU. *Saturasi jaringan* adalah saat jaringan antara basis data dan klien membawa lebih banyak data dari yang dapat ditanganinya.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Penyebab umum peristiwa `Client:ClientWrite` muncul dalam peristiwa tunggu teratas mencakup yang berikut:
**Peningkatan latensi jaringan**
Mungkin terdapat peningkatan latensi jaringan antara instans DB RDS for PostgreSQL dan klien. Latensi jaringan yang lebih tinggi meningkatkan waktu yang dibutuhkan klien untuk menerima data.
**Peningkatan beban pada klien**
Mungkin terdapat tekanan CPU atau saturasi jaringan pada klien. Peningkatan beban pada klien menunda penerimaan data dari instans DB RDS for PostgreSQL.
**Data dalam volume besar yang dikirim ke klien**
Instans DB RDS for PostgreSQL mungkin mengirimkan sejumlah besar data ke klien. Klien mungkin tidak dapat menerima data secepat klaster mengirimkannya. Aktivitas seperti penyalinan tabel besar dapat mengakibatkan peningkatan peristiwa `Client:ClientWrite`.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Tempatkan klien di Zona Ketersediaan dan subnet VPC yang sama dengan klaster](#wait-event.clientwrite.actions.az-vpc-subnet)
+ [Gunakan instans generasi saat ini](#wait-event.clientwrite.actions.db-instance-class)
+ [Kurangi jumlah data yang dikirim ke klien Anda](#wait-event.clientwrite.actions.reduce-data)
+ [Skalakan klien Anda](#wait-event.clientwrite.actions.scale-client)
### Tempatkan klien di Zona Ketersediaan dan subnet VPC yang sama dengan klaster
Untuk mengurangi latensi jaringan dan meningkatkan throughput jaringan, tempatkan klien di Zona Ketersediaan dan subnet cloud privat virtual (VPC) yang sama dengan instans DB RDS for PostgreSQL.
### Gunakan instans generasi saat ini
Dalam kasus tertentu, Anda mungkin tidak menggunakan kelas instans DB yang mendukung frame jumbo. Jika Anda menjalankan aplikasi di Amazon EC2, pertimbangkan untuk menggunakan instans generasi saat ini untuk klien. Selain itu, konfigurasikan unit transmisi maksimum (MTU) pada sistem operasi klien. Teknik ini dapat mengurangi jumlah round trip jaringan dan meningkatkan throughput jaringan. Untuk informasi selengkapnya, lihat [Jumbo frame (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) di Panduan Pengguna *Amazon EC2*.
Untuk informasi tentang kelas instans DB, lihat [ DB](Concepts.DBInstanceClass.md). Untuk menentukan kelas instans DB yang setara dengan jenis instans Amazon EC2, tempatkan `db.` sebelum nama jenis instans Amazon EC2. Misalnya, instans Amazon EC2 `r5.8xlarge` setara dengan kelas instans DB `db.r5.8xlarge`.
### Kurangi jumlah data yang dikirim ke klien Anda
Jika memungkinkan, sesuaikan aplikasi Anda untuk mengurangi jumlah data yang dikirim instans DB RDS for PostgreSQL ke klien. Penyesuaian ini akan mengurangi pertentangan CPU dan jaringan pada klien.
### Skalakan klien Anda
Menggunakan Amazon CloudWatch atau metrik host lainnya, tentukan apakah klien Anda saat ini dibatasi oleh CPU atau bandwidth jaringan, atau keduanya. Jika klien dibatasi, skalakan klien sesuai yang diperlukan.
# CPU
Peristiwa ini terjadi saat thread aktif di CPU atau sedang menunggu CPU.
**Topics**
+ [Versi mesin yang didukung](#wait-event.cpu.context.supported)
+ [Konteks](#wait-event.cpu.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.cpu.causes)
+ [Tindakan](#wait-event.cpu.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini relevan untuk semua versi RDS for PostgreSQL.
## Konteks
*Central Processing Unit (CPU)* adalah komponen komputer yang menjalankan petunjuk. Misalnya, petunjuk CPU melakukan operasi aritmetika dan bertukar data dalam memori. Jika kueri meningkatkan jumlah petunjuk yang dilakukannya melalui mesin basis data, waktu yang dihabiskan untuk menjalankan kueri akan meningkat. *Penjadwalan CPU* memberikan waktu CPU untuk suatu proses. Penjadwalan diatur oleh kernel sistem operasi.
**Topics**
+ [Bagaimana cara mengetahui kapan peristiwa tunggu ini terjadi?](#wait-event.cpu.when-it-occurs)
+ [DBLoadMetrik CPU](#wait-event.cpu.context.dbloadcpu)
+ [Metrik os.cpuUtilization](#wait-event.cpu.context.osmetrics)
+ [Kemungkinan penyebab penjadwalan CPU](#wait-event.cpu.context.scheduling)
### Bagaimana cara mengetahui kapan peristiwa tunggu ini terjadi?
Peristiwa tunggu `CPU` ini menunjukkan bahwa proses backend aktif di CPU atau sedang menunggu CPU. Anda mengetahuinya terjadi saat kueri menunjukkan informasi berikut:
+ Kolom `pg_stat_activity.state` memiliki nilai `active`.
+ Kolom `wait_event_type` dan `wait_event` di `pg_stat_activity` adalah `null`.
Untuk melihat proses backend yang menggunakan atau menunggu CPU, jalankan kueri berikut.
```
SELECT *
FROM pg_stat_activity
WHERE state = 'active'
AND wait_event_type IS NULL
AND wait_event IS NULL;
```
### DBLoadMetrik CPU
Metrik Wawasan Performa untuk CPU adalah `DBLoadCPU`. Nilai untuk `DBLoadCPU` dapat berbeda dari nilai untuk CloudWatch metrik Amazon`CPUUtilization`. Metrik terakhir dikumpulkan dari HyperVisor untuk instance database.
### Metrik os.cpuUtilization
Metrik sistem operasi Wawasan Performa memberikan informasi terperinci tentang pemanfaatan CPU. Misalnya, Anda dapat menampilkan metrik berikut:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Wawasan Performa melaporkan penggunaan CPU oleh mesin basis data sebagai `os.cpuUtilization.nice.avg`.
### Kemungkinan penyebab penjadwalan CPU
Kernel sistem operasi (OS) menangani penjadwalan untuk CPU. Ketika CPU *aktif*, sebuah proses mungkin perlu menunggu untuk dijadwalkan. CPU aktif saat melakukan penghitungan. Ini juga aktif saat memiliki utas idle yang tidak berjalan, yaitu, utas idle yang menunggu memori I/O. This type of I/O mendominasi beban kerja database yang khas.
Proses cenderung menunggu untuk dijadwalkan pada CPU saat kondisi berikut terpenuhi:
+ CloudWatch `CPUUtilization`Metriknya mendekati 100 persen.
+ Beban rata-rata lebih besar dari jumlah vCPUs, menunjukkan beban berat. Anda dapat menemukan metrik `loadAverageMinute` di bagian metrik OS dalam Wawasan Performa.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa tunggu CPU terjadi lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Topics**
+ [Kemungkinan penyebab lonjakan mendadak](#wait-event.cpu.causes.spikes)
+ [Kemungkinan penyebab frekuensi tinggi jangka panjang](#wait-event.cpu.causes.long-term)
+ [Corner cases](#wait-event.cpu.causes.corner-cases)
### Kemungkinan penyebab lonjakan mendadak
Penyebab lonjakan mendadak yang paling memungkinkan adalah sebagai berikut:
+ Aplikasi Anda membuka terlalu banyak koneksi bersamaan ke basis data. Skenario ini dikenal sebagai "connection storm".
+ Beban kerja aplikasi Anda berubah dengan salah satu cara berikut:
+ Kueri baru
+ Peningkatan ukuran set data
+ Pemeliharaan atau pembuatan indeks
+ Fungsi baru
+ Operator baru
+ Peningkatan eksekusi kueri paralel
+ Rencana eksekusi kueri Anda telah berubah. Dalam beberapa kasus, perubahan dapat menyebabkan peningkatan buffer. Misalnya, kueri sekarang menggunakan pemindaian berurutan saat sebelumnya menggunakan indeks. Dalam hal ini, kueri membutuhkan lebih banyak CPU untuk mencapai tujuan yang sama.
### Kemungkinan penyebab frekuensi tinggi jangka panjang
Berikut adalah penyebab paling memungkinkan dari peristiwa yang berulang dalam jangka waktu lama:
+ Terlalu banyak proses backend yang berjalan secara konkuren pada CPU. Proses-proses ini dapat berupa pekerja paralel.
+ Kueri beperforma suboptimal karena membutuhkan buffer dalam jumlah besar.
### Corner cases
Jika tidak ada kemungkinan penyebab yang merupakan penyebab sebenarnya, situasi berikut mungkin terjadi:
+ CPU menukar proses masuk dan keluar.
+ CPU mungkin mengelola entri tabel halaman jika fitur *huge page* telah dinonaktifkan. Fitur manajemen memori ini diaktifkan secara default untuk semua kelas instans DB selain kelas instans DB mikro, kecil, dan menengah. Untuk informasi selengkapnya, lihat [Halaman besar untuk RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md).
## Tindakan
Jika peristiwa tunggu `CPU` mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Tanggapi peristiwa ini hanya saat performa menurun.
**Topics**
+ [Selidiki apakah basis data menyebabkan peningkatan CPU](#wait-event.cpu.actions.db-CPU)
+ [Tentukan apakah jumlah koneksi meningkat](#wait-event.cpu.actions.connections)
+ [Tanggapi perubahan beban kerja](#wait-event.cpu.actions.workload)
### Selidiki apakah basis data menyebabkan peningkatan CPU
Periksa metrik `os.cpuUtilization.nice.avg` dalam Wawasan Performa. Jika nilai ini jauh lebih kecil daripada penggunaan CPU, proses non-basis data adalah kontributor utama ke CPU.
### Tentukan apakah jumlah koneksi meningkat
Periksa `DatabaseConnections` metrik di Amazon CloudWatch. Tindakan Anda bergantung pada apakah jumlahnya meningkat atau menurun selama periode peningkatan peristiwa tunggu CPU.
#### Koneksi meningkat
Jika jumlah koneksi naik, bandingkan jumlah proses backend yang mengkonsumsi CPU dengan jumlah v. CPUs Skenario berikut dimungkinkan:
+ Jumlah proses backend yang mengkonsumsi CPU kurang dari jumlah v. CPUs
Dalam hal ini, jumlah koneksi tidak menjadi masalah. Namun, Anda masih dapat mencoba mengurangi pemanfaatan CPU.
+ Jumlah proses backend yang mengkonsumsi CPU lebih besar dari jumlah v. CPUs
Jika demikian, pertimbangkan opsi berikut:
+ Kurangi jumlah proses backend yang terhubung ke basis data Anda. Misalnya, terapkan solusi pooling koneksi seperti Proksi RDS. Untuk mempelajari selengkapnya, lihat [Proksi Amazon RDS Aurora](rds-proxy.md).
+ Tingkatkan ukuran instans Anda untuk mendapatkan jumlah v yang lebih tinggiCPUs.
+ Jika berlaku, arahkan ulang beberapa beban kerja hanya-baca ke simpul pembaca.
#### Koneksi tidak meningkat
Periksa metrik `blks_hit` dalam Wawasan Performa. Cari korelasi antara peningkatan `blks_hit` dan penggunaan CPU. Skenario berikut mungkin terjadi:
+ Penggunaan CPU dan `blks_hit` berkorelasi.
Dalam hal ini, temukan pernyataan SQL teratas yang terkait dengan penggunaan CPU, lalu cari perubahan rencana. Anda dapat menggunakan salah satu teknik berikut:
+ Jelaskan rencana secara manual, lalu bandingkan dengan rencana eksekusi yang diperkirakan.
+ Cari peningkatan hit blok per detik dan hit blok lokal per detik. Di bagian **SQL Teratas** pada dasbor Wawasan Performa, pilih **Preferensi**.
+ Penggunaan CPU dan `blks_hit` tidak berkorelasi.
Jika demikian, ketahui apakah salah satu hal berikut terjadi:
+ Aplikasi dengan cepat terhubung ke dan terputus dari basis data.
Jalankan diagnosis perilaku ini dengan mengaktifkan `log_connections` dan `log_disconnections`, lalu menganalisis log PostgreSQL. Pertimbangkan untuk menggunakan penganalisis log `pgbadger`. Untuk informasi selengkapnya, lihat [https://github.com/darold/pgbadger](https://github.com/darold/pgbadger).
+ OS kelebihan beban.
Dalam hal ini, Wawasan Performa menunjukkan bahwa proses backend menggunakan CPU untuk waktu yang lebih lama dari biasanya. Cari bukti di metrik Performance Insights atau `os.cpuUtilization` metrik. CloudWatch `CPUUtilization` Jika sistem operasi kelebihan beban, lihat metrik Pemantauan yang Ditingkatkan untuk mendiagnosis lebih lanjut. Secara khusus, lihat daftar proses dan persentase CPU yang dikonsumsi oleh setiap proses.
+ Pernyataan SQL teratas mengonsumsi terlalu banyak CPU.
Periksa pernyataan yang terkait dengan penggunaan CPU untuk melihat apakah pernyataan tersebut dapat menggunakan lebih sedikit CPU. Jalankan perintah `EXPLAIN`, lalu fokus pada simpul rencana yang memiliki dampak terbesar. Pertimbangkan untuk menggunakan pemvisualisasi rencana eksekusi PostgreSQL. Untuk mencoba alat ini, lihat [http://explain.dalibo.com/](http://explain.dalibo.com/).
### Tanggapi perubahan beban kerja
Jika beban kerja Anda telah berubah, cari jenis perubahan berikut:
Kueri baru
Periksa apakah kueri baru memang diharapkan. Jika demikian, pastikan bahwa rencana eksekusinya dan jumlah eksekusi per detik memang diharapkan.
Peningkatan ukuran set data
Ketahui apakah pemartisian, jika belum diterapkan, dapat membantu. Strategi ini dapat mengurangi jumlah halaman yang perlu diambil kueri.
Pemeliharaan atau pembuatan indeks
Periksa apakah jadwal pemeliharaan memang diharapkan. Praktik terbaiknya adalah menjadwalkan aktivitas pemeliharaan di luar aktivitas puncak.
Fungsi baru
Periksa apakah fungsi-fungsi ini berfungsi seperti yang diharapkan selama pengujian. Secara khusus, periksa apakah jumlah eksekusi per detik memang diharapkan.
Operator baru
Periksa apakah operator baru berfungsi seperti yang diharapkan selama pengujian.
Peningkatan dalam menjalankan kueri paralel
Ketahui apakah salah satu situasi berikut telah terjadi:
+ Relasi atau indeks yang terkait tiba-tiba bertambah ukurannya sehingga sangat berbeda dari `min_parallel_table_scan_size` atau `min_parallel_index_scan_size`.
+ Perubahan terkini telah dilakukan pada `parallel_setup_cost` atau `parallel_tuple_cost`.
+ Perubahan terkini telah dilakukan pada `max_parallel_workers` atau `max_parallel_workers_per_gather`.
# IO: BufFileRead dan IO: BufFileWrite
Peristiwa `IO:BufFileRead` dan `IO:BufFileWrite` terjadi ketika RDS for PostgreSQL membuat file sementara. Saat operasi membutuhkan lebih banyak memori daripada yang saat ini ditentukan oleh parameter memori kerja, operasi ini akan menulis data sementara ke penyimpanan persisten. Operasi ini kadang-kadang disebut *tumpah ke disk*. Untuk informasi selengkapnya tentang file sementara dan penggunaannya, lihat[Mengelola file sementara dengan PostgreSQL](PostgreSQL.ManagingTempFiles.md).
**Topics**
+ [Versi mesin yang didukung](#wait-event.iobuffile.context.supported)
+ [Konteks](#wait-event.iobuffile.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.iobuffile.causes)
+ [Tindakan](#wait-event.iobuffile.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
`IO:BufFileRead` dan `IO:BufFileWrite` berkaitan dengan area memori kerja dan area memori kerja pemeliharaan. Untuk informasi selengkapnya tentang penyetelan memori, lihat [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) dalam dokumentasi PostgreSQL.
Nilai default untuk `work_mem` adalah 4 MB. Jika satu sesi melakukan operasi secara paralel, setiap pekerja yang menangani paralelisme ini akan menggunakan memori 4 MB. Untuk alasan ini, atur `work_mem` dengan hati-hati. Jika Anda meningkatkan nilai ini terlalu banyak, basis data yang menjalankan banyak sesi mungkin akan mengonsumsi terlalu banyak memori. Jika Anda menetapkan nilai terlalu rendah, Aurora PostgreSQL akan membuat file sementara di penyimpanan lokal. Disk I/O untuk file-file sementara ini dapat mengurangi kinerja.
Jika Anda mengamati urutan peristiwa berikut, basis data mungkin menghasilkan file sementara:
1. Penurunan ketersediaan secara tiba-tiba dan drastis
1. Pemulihan cepat untuk ruang kosong
Anda mungkin juga melihat pola "gergaji". Pola ini dapat menunjukkan bahwa basis data Anda membuat file kecil terus-menerus.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Secara umum, peristiwa tunggu ini disebabkan oleh operasi yang mengonsumsi lebih banyak memori daripada yang dialokasikan oleh parameter `work_mem` atau `maintenance_work_mem`. Untuk mengompensasi, operasi menulis ke file sementara. Penyebab umum peristiwa `IO:BufFileRead` dan `IO:BufFileWrite` mencakup hal berikut:
**Kueri yang membutuhkan lebih banyak memori daripada yang ada di area memori kerja**
Kueri dengan karakteristik berikut menggunakan area memori kerja:
+ Hash join
+ Klausa `ORDER BY`
+ Klausa `GROUP BY`
+ `DISTINCT`
+ Fungsi jendela
+ `CREATE TABLE AS SELECT`
+ Penyegaran tampilan terwujud
**Pernyataan yang membutuhkan lebih banyak memori daripada yang ada di area memori kerja pemeliharaan**
Pernyataan berikut menggunakan area memori kerja pemeliharaan:
+ `CREATE INDEX`
+ `CLUSTER`
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Identifikasi masalah](#wait-event.iobuffile.actions.problem)
+ [Periksa kueri join](#wait-event.iobuffile.actions.joins)
+ [Periksa kueri ORDER BY dan GROUP BY](#wait-event.iobuffile.actions.order-by)
+ [Hindari menggunakan operasi DISTINCT](#wait-event.iobuffile.actions.distinct)
+ [Mempertimbangkan untuk menggunakan fungsi jendela alih-alih fungsi GROUP BY](#wait-event.iobuffile.actions.window)
+ [Selidiki tampilan terwujud dan pernyataan CTAS](#wait-event.iobuffile.actions.mv-refresh)
+ [Gunakan pg\$1repack saat Anda membuat kembali indeks](#wait-event.iobuffile.actions.pg_repack)
+ [Tingkatkan maintenance\$1work\$1mem saat Anda membuat klaster tabel](#wait-event.iobuffile.actions.cluster)
+ [Tune memori untuk mencegah IO: BufFileRead dan IO: BufFileWrite](#wait-event.iobuffile.actions.tuning-memory)
### Identifikasi masalah
Anda dapat melihat penggunaan file sementara secara langsung di Performance Insights. Untuk informasi selengkapnya, lihat [Melihat penggunaan file sementara dengan Performance Insights](PostgreSQL.ManagingTempFiles.Example.md). Jika Performance Insights dinonaktifkan, Anda mungkin melihat peningkatan `IO:BufFileRead` dan `IO:BufFileWrite` operasi.
Untuk mengidentifikasi sumber masalahnya, Anda dapat mengatur parameter `log_temp_files` untuk mencatat log semua kueri yang menghasilkan file sementara lebih dari ambang batas KB yang Anda tentukan. Secara default, `log_temp_files` diatur ke `-1`, yang menonaktifkan fitur pencatatan log ini. Jika Anda mengatur parameter ini ke `0`, RDS for PostgreSQL mencatat log semua file sementara. Jika nilainya `1024`, Aurora PostgreSQL mencatat semua kueri yang menghasilkan file sementara yang berukuran lebih besar dari 1 MB. Untuk informasi selengkapnya tentang `log_temp_files`, lihat [Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html) dalam dokumentasi PostgreSQL.
### Periksa kueri join
Kemungkinan kueri Anda menggunakan join. Misalnya, kueri berikut menggabungkan empat tabel.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = order.customer_id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Kemungkinan penyebab lonjakan penggunaan file sementara adalah masalah dalam kueri itu sendiri. Misalnya, klausa yang rusak mungkin tidak memfilter join dengan benar. Pertimbangkan inner join kedua dalam contoh berikut.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = customer.id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Kueri sebelumnya secara keliru menggabungkan `customer.id` ke `customer.id`, sehingga memberikan hasil perkalian Cartesian antara setiap pelanggan dan setiap pesanan. Jenis join yang tak terduga ini menghasilkan file sementara yang besar. Tergantung pada ukuran tabel, kueri Cartesian bahkan dapat memenuhi penyimpanan. Aplikasi Anda dapat memiliki join Cartesian jika kondisi berikut terpenuhi:
+ Anda melihat penurunan besar dan drastis dalam ketersediaan penyimpanan, yang diikuti oleh pemulihan cepat.
+ Tidak ada indeks yang dibuat.
+ Tidak ada pernyataan `CREATE TABLE FROM SELECT` yang dikeluarkan.
+ Tidak ada tampilan terwujud yang disegarkan.
Untuk melihat apakah tabel sedang digabungkan menggunakan kunci yang tepat, periksa kueri dan petunjuk pemetaan relasional objek Anda. Perlu diperhatikan bahwa kueri tertentu dari aplikasi Anda tidak dipanggil sepanjang waktu, dan beberapa kueri dihasilkan secara dinamis.
### Periksa kueri ORDER BY dan GROUP BY
Dalam beberapa kasus, klausa `ORDER BY` dapat menghasilkan file sementara yang berlebihan. Pertimbangkan panduan berikut ini:
+ Hanya sertakan kolom dalam klausa `ORDER BY` saat kolom tersebut perlu diurutkan. Pedoman ini sangat penting untuk kueri yang menampilkan ribuan baris dan menentukan banyak kolom dalam klausa `ORDER BY`.
+ Pertimbangkan untuk membuat indeks guna mempercepat klausa `ORDER BY` saat klausa cocok dengan kolom yang memiliki urutan naik atau turun yang sama. Indeks sebagian lebih direkomendasikan karena lebih kecil. Indeks yang lebih kecil lebih cepat untuk dibaca dan di-traverse.
+ Jika Anda membuat indeks untuk kolom yang dapat menerima nilai kosong, pertimbangkan apakah Anda ingin nilai kosong disimpan di akhir atau di awal indeks.
Jika memungkinkan, kurangi jumlah baris yang perlu diurutkan dengan memfilter set hasil. Jika Anda menggunakan pernyataan klausa atau subkueri `WITH`, perlu diperhatikan bahwa kueri dalam menghasilkan set hasil, lalu meneruskannya ke kueri luar. Semakin banyak baris yang dapat difilter kueri, semakin sedikit pengurutan yang perlu dilakukan kueri.
+ Jika Anda tidak perlu mendapatkan set hasil lengkap, gunakan klausa `LIMIT`. Misalnya, jika Anda hanya menginginkan lima baris teratas, kueri yang menggunakan klausa `LIMIT` tidak akan terus memberikan hasil. Dengan cara ini, kueri membutuhkan lebih sedikit memori dan file sementara.
Kueri yang menggunakan klausa `GROUP BY` juga dapat memerlukan file sementara. Kueri `GROUP BY` meringkas nilai dengan menggunakan fungsi seperti berikut:
+ `COUNT`
+ `AVG`
+ `MIN`
+ `MAX`
+ `SUM`
+ `STDDEV`
Untuk menyetel kueri `GROUP BY`, ikuti rekomendasi untuk kueri `ORDER BY`.
### Hindari menggunakan operasi DISTINCT
Jika memungkinkan, jangan gunakan operasi `DISTINCT` untuk menghapus baris duplikat. Semakin banyak baris duplikat yang tidak perlu, yang ditampilkan oleh kueri Anda, operasi `DISTINCT` menjadi semakin mahal. Jika memungkinkan, tambahkan filter dalam klausa `WHERE` meskipun Anda menggunakan filter yang sama untuk tabel yang berbeda. Memfilter kueri dan melakukan join dengan benar akan meningkatkan performa Anda serta mengurangi penggunaan sumber daya. Hal tersebut juga mencegah laporan dan hasil yang salah.
Jika Anda perlu menggunakan `DISTINCT` untuk beberapa baris dari tabel yang sama, pertimbangkan untuk membuat indeks komposit. Mengelompokkan beberapa kolom dalam indeks dapat meningkatkan waktu untuk mengevaluasi baris yang berbeda. Selain itu, jika Anda menggunakan RDS for PostgreSQL versi 10 atau lebih tinggi, Anda dapat mengorelasikan statistik di antara beberapa kolom dengan menggunakan perintah `CREATE STATISTICS`.
### Mempertimbangkan untuk menggunakan fungsi jendela alih-alih fungsi GROUP BY
Dengan menggunakan `GROUP BY`, Anda mengubah set hasil, lalu mengambil hasil agregat. Dengan menggunakan fungsi jendela, Anda mengumpulkan data tanpa mengubah set hasil. Fungsi jendela menggunakan klausa `OVER` untuk melakukan penghitungan di seluruh set yang ditentukan oleh kueri, dengan mengorelasikan satu baris dengan yang lain. Anda dapat menggunakan semua fungsi `GROUP BY` dalam fungsi jendela, tetapi juga menggunakan fungsi seperti berikut:
+ `RANK`
+ `ARRAY_AGG`
+ `ROW_NUMBER`
+ `LAG`
+ `LEAD`
Untuk meminimalkan jumlah file sementara yang dihasilkan oleh fungsi jendela, hapus duplikasi untuk set hasil yang sama saat Anda membutuhkan dua agregasi yang berbeda. Pertimbangkan kueri berikut.
```
SELECT sum(salary) OVER (PARTITION BY dept ORDER BY salary DESC) as sum_salary
, avg(salary) OVER (PARTITION BY dept ORDER BY salary ASC) as avg_salary
FROM empsalary;
```
Anda dapat menulis ulang kueri dengan klausa `WINDOW` sebagai berikut:
```
SELECT sum(salary) OVER w as sum_salary
, avg(salary) OVER w as_avg_salary
FROM empsalary
WINDOW w AS (PARTITION BY dept ORDER BY salary DESC);
```
Secara default, perencana eksekusi Aurora PostgreSQL menggabungkan simpul yang serupa, sehingga tidak menggandakan operasi. Namun, dengan menggunakan deklarasi eksplisit untuk blok jendela, Anda dapat mengelola kueri dengan lebih mudah. Anda juga dapat meningkatkan performa dengan mencegah duplikasi.
### Selidiki tampilan terwujud dan pernyataan CTAS
Saat tampilan terwujud disegarkan, kueri akan dijalankan. Kueri ini dapat berisi operasi seperti `GROUP BY`, `ORDER BY`, atau `DISTINCT`. Selama penyegaran, Anda mungkin mengamati sejumlah besar file sementara serta peristiwa tunggu `IO:BufFileWrite` dan `IO:BufFileRead`. Demikian pula, saat Anda membuat tabel berdasarkan pernyataan `SELECT`, pernyataan `CREATE TABLE` tersebut menjalankan kueri. Untuk mengurangi file sementara yang dibutuhkan, optimalkan kueri.
### Gunakan pg\$1repack saat Anda membuat kembali indeks
Saat Anda membuat indeks, mesin mengurutkan set hasil. Seiring tabel bertambah besar, dan seiring nilai di kolom yang diindeks menjadi lebih beragam, file sementara membutuhkan lebih banyak ruang. Dalam kebanyakan kasus, Anda tidak dapat mencegah pembuatan file sementara untuk tabel besar tanpa memodifikasi area memori kerja pemeliharaan. Untuk informasi selengkapnya tentang `maintenance_work_mem`, lihat [https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html) dalam dokumentasi PostgreSQL.
Solusi yang mungkin saat membuat ulang indeks besar adalah dengan menggunakan ekstensi pg\$1repack. Untuk informasi selengkapnya, lihat [Reorganize tables in PostgreSQL databases with minimal locks](https://reorg.github.io/pg_repack/) dalam dokumentasi pg\$1repack. Untuk informasi tentang menyiapkan ekstensi di instans DB RDS for PostgreSQL Anda, lihat [Mengurangi bloat dalam tabel dan indeks dengan ekstensi pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md).
### Tingkatkan maintenance\$1work\$1mem saat Anda membuat klaster tabel
Perintah `CLUSTER` membuat klaster tabel yang ditentukan menurut *table\$1name* berdasarkan indeks yang ada yang ditentukan menurut *index\$1name*. RDS for PostgreSQL secara fisik membuat ulang tabel agar sesuai dengan urutan indeks yang diberikan.
Saat penyimpanan magnetik lazim digunakan, pembuatan klaster menjadi umum dilakukan karena throughput penyimpanan terbatas. Sekarang penyimpanan berbasis SSD sudah umum, sehingga pembuatan klaster menjadi kurang populer. Namun, jika Anda membuat klaster tabel, Anda masih dapat sedikit meningkatkan performa tergantung pada ukuran tabel, indeks, kueri, dan banyak lagi.
Jika Anda menjalankan perintah `CLUSTER` dan mengamati peristiwa tunggu `IO:BufFileWrite` dan `IO:BufFileRead`, setel `maintenance_work_mem`. Tingkatkan ukuran memori ke jumlah yang cukup besar. Nilai tinggi berarti mesin dapat menggunakan lebih banyak memori untuk operasi klaster.
### Tune memori untuk mencegah IO: BufFileRead dan IO: BufFileWrite
Dalam beberapa situasi, Anda perlu menyetel memori. Tujuan Anda adalah menyeimbangkan memori di seluruh area konsumsi berikut menggunakan parameter yang sesuai, sebagai berikut.
+ Nilai `work_mem`
+ Memori yang tersisa setelah mengecualikan nilai `shared_buffers`
+ Koneksi maksimum yang dibuka dan digunakan, yang dibatasi oleh `max_connections`
Untuk informasi selengkapnya tentang penyetelan memori, lihat [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) dalam dokumentasi PostgreSQL.
#### Tingkatkan ukuran area memori kerja
Dalam beberapa situasi, satu-satunya pilihan adalah menambah memori yang digunakan oleh sesi Anda. Jika kueri Anda ditulis dengan benar dan menggunakan kunci yang benar untuk join, pertimbangkan untuk meningkatkan nilai `work_mem`.
Untuk mengetahui jumlah file sementara yang dihasilkan kueri, atur `log_temp_files` ke `0`. Jika meningkatkan nilai `work_mem` ke nilai maksimum yang diidentifikasi dalam log, Anda mencegah kueri menghasilkan file sementara. Namun, `work_mem` menetapkan nilai maksimum per simpul rencana untuk setiap koneksi atau pekerja paralel. Jika basis data memiliki 5.000 koneksi, dan jika masing-masing menggunakan memori 256 MiB, mesin akan membutuhkan RAM 1,2 TiB. Oleh karena itu, instans Anda dapat kehabisan memori.
#### Cadangkan memori yang cukup untuk pool buffer bersama
Basis data Anda menggunakan area memori seperti pool buffer bersama, bukan hanya area memori kerja. Pertimbangkan persyaratan area memori tambahan ini sebelum Anda meningkatkan `work_mem`.
Misalnya, anggaplah kelas instans Aurora PostgreSQL Anda adalah db.r5.2xlarge. Kelas ini memiliki memori 64 GiB. Secara default, 25 persen memori dicadangkan untuk pool buffer bersama. Setelah Anda mengurangi jumlah yang dialokasikan ke area memori bersama, 16.384 MB tetap ada. Jangan mengalokasikan memori yang tersisa hanya ke area memori kerja karena sistem operasi dan mesin juga memerlukan memori.
Memori yang dapat Anda alokasikan ke `work_mem` tergantung pada kelas instans. Jika Anda menggunakan kelas instans yang lebih besar, memori yang tersedia akan lebih banyak. Namun, dalam contoh sebelumnya, Anda tidak dapat menggunakan lebih dari 16 GiB. Jika melakukannya, instans Anda menjadi tidak tersedia saat kehabisan memori. Untuk memulihkan instans dari status tidak tersedia, layanan otomatisasi PostgreSQL Aurora secara otomatis dimulai ulang.
#### Kelola jumlah koneksi
Misalnya, instans basis data Anda memiliki 5.000 koneksi simultan. Setiap koneksi menggunakan setidaknya 4 MiB `work_mem`. Konsumsi memori yang tinggi dari koneksi cenderung menurunkan performa. Untuk mengatasinya, Anda memiliki opsi berikut:
+ Tingkatkan ke kelas instans yang lebih besar.
+ Kurangi jumlah koneksi basis data simultan dengan menggunakan proksi atau pooler koneksi.
Untuk proksi, pertimbangkan Proksi Amazon RDS, pgBouncer, atau pooler koneksi berdasarkan aplikasi Anda. Solusi ini mengurangi beban CPU. Solusi ini juga mengurangi risiko saat semua koneksi memerlukan area memori kerja. Saat koneksi basis data lebih sedikit, Anda dapat meningkatkan nilai `work_mem`. Dengan cara ini, Anda mengurangi munculnya peristiwa tunggu `IO:BufFileRead` dan `IO:BufFileWrite`. Selain itu, kueri yang menunggu area memori kerja akan dipercepat secara signifikan.
# IO: DataFileRead
Peristiwa `IO:DataFileRead` terjadi saat koneksi menunggu proses backend untuk membaca halaman yang diperlukan dari penyimpanan karena halaman tidak tersedia dalam memori bersama.
**Topics**
+ [Versi mesin yang didukung](#wait-event.iodatafileread.context.supported)
+ [Konteks](#wait-event.iodatafileread.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.iodatafileread.causes)
+ [Tindakan](#wait-event.iodatafileread.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
Semua kueri dan operasi manipulasi data (DML) mengakses halaman di pool buffer. Pernyataan yang dapat menimbulkan pembacaan mencakup `SELECT`, `UPDATE`, dan `DELETE`. Misalnya, `UPDATE` dapat membaca halaman dari tabel atau indeks. Jika halaman yang diminta atau diperbarui tidak berada dalam pool buffer bersama, pembacaan ini dapat mengarah ke peristiwa `IO:DataFileRead`.
Karena bersifat terbatas, pool buffer bersama dapat diisi. Dalam hal ini, permintaan untuk halaman yang tidak berada dalam memori memaksa basis data untuk membaca blok dari disk. Jika peristiwa `IO:DataFileRead` sering terjadi, pool buffer bersama mungkin terlalu kecil untuk mengakomodasi beban kerja Anda. Masalah ini bersifat akut untuk kueri `SELECT` yang membaca sejumlah besar baris yang tidak dapat ditampung pool buffer. Untuk informasi selengkapnya tentang pool buffer, lihat [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) dalam dokumentasi PostgreSQL.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Penyebab umum peristiwa `IO:DataFileRead` tersebut mencakup:
**Lonjakan koneksi**
Anda mungkin menemukan beberapa koneksi yang menghasilkan jumlah acara IO: DataFileRead wait yang sama. Dalam hal ini, lonjakan (peningkatan tiba-tiba dan besar) dalam peristiwa `IO:DataFileRead` dapat terjadi.
**Pernyataan SELECT dan DML yang melakukan pemindaian berurutan**
Aplikasi Anda mungkin melakukan operasi baru. Operasi yang ada mungkin juga berubah karena rencana eksekusi baru. Dalam kasus ini, cari tabel (terutama tabel besar) yang memiliki nilai `seq_scan` yang lebih besar. Temukan tabel dengan membuat kueri `pg_stat_user_tables`. Untuk melacak kueri yang menghasilkan lebih banyak operasi baca, gunakan ekstensi `pg_stat_statements`.
**CTAS dan CREATE INDEX untuk set data besar**
*CTAS* adalah sebuah pernyataan `CREATE TABLE AS SELECT`. Jika Anda menjalankan CTAS menggunakan set data besar sebagai sumber, atau membuat indeks pada tabel besar, maka peristiwa `IO:DataFileRead` dapat terjadi. Saat Anda membuat indeks, basis data mungkin perlu membaca seluruh objek menggunakan pemindaian berurutan. CTAS menghasilkan pembacaan `IO:DataFile` saat halaman tidak ada dalam memori.
**Beberapa pekerja vakum berjalan pada waktu yang sama**
Pekerja vakum dapat dipicu secara manual atau otomatis. Sebaiknya adopsi strategi vakum yang agresif. Namun, saat tabel memiliki banyak baris yang diperbarui atau dihapus, peristiwa tunggu `IO:DataFileRead` bertambah. Setelah ruang direklamasi, waktu vakum yang dihabiskan untuk `IO:DataFileRead` akan berkurang.
**Menyerap data dalam jumlah besar**
Saat aplikasi Anda menyerap data dalam jumlah besar, operasi `ANALYZE` mungkin terjadi lebih sering. Proses `ANALYZE` dapat dipicu oleh peluncur autovacuum atau diinvokasi secara manual.
Operasi `ANALYZE` membaca subset dari tabel. Jumlah halaman yang harus dipindai dihitung menggunakan perkalian 30 dengan nilai `default_statistics_target`. Untuk informasi selengkapnya, lihat [Dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET). Parameter `default_statistics_target` menerima nilai antara 1 hingga 10.000, dengan nilai default adalah 100.
**Kekurangan sumber daya**
Jika bandwidth jaringan instans atau CPU dikonsumsi, peristiwa `IO:DataFileRead` mungkin terjadi lebih sering.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Memeriksa filter predikat untuk kueri yang menghasilkan peristiwa tunggu](#wait-event.iodatafileread.actions.filters)
+ [Meminimalkan efek operasi pemeliharaan](#wait-event.iodatafileread.actions.maintenance)
+ [Merespons jumlah koneksi yang tinggi](#wait-event.iodatafileread.actions.connections)
### Memeriksa filter predikat untuk kueri yang menghasilkan peristiwa tunggu
Asumsikan bahwa Anda mengidentifikasi kueri spesifik yang menghasilkan peristiwa tunggu `IO:DataFileRead`. Anda dapat mengidentifikasinya menggunakan teknik berikut:
+ Wawasan Performa
+ Tampilan katalog seperti yang disediakan oleh ekstensi `pg_stat_statements`
+ Tampilan katalog `pg_stat_all_tables`, jika secara berkala menunjukkan peningkatan jumlah pembacaan fisik
+ Tampilan `pg_statio_all_tables`, jika menunjukkan bahwa penghitung `_read` meningkat
Sebaiknya Anda menentukan filter yang akan digunakan dalam predikat (klausa `WHERE`) kueri ini. Ikuti pedoman berikut:
+ Jalankan perintah `EXPLAIN`. Pada output, identifikasi jenis pemindaian yang digunakan. Pemindaian berurutan tidak selalu menunjukkan adanya masalah. Kueri yang menggunakan pemindaian berurutan secara alami menghasilkan lebih banyak peristiwa `IO:DataFileRead` jika dibandingkan dengan kueri yang menggunakan filter.
Cari tahu apakah kolom yang tercantum dalam klausa `WHERE` telah diindeks. Jika tidak, coba buat indeks untuk kolom ini. Pendekatan ini mencegah pemindaian berurutan dan mengurangi peristiwa `IO:DataFileRead`. Jika kueri memiliki filter yang ketat dan masih menghasilkan pemindaian berurutan, evaluasi apakah indeks yang tepat sedang digunakan.
+ Cari tahu apakah kueri mengakses tabel yang sangat besar. Dalam beberapa kasus, partisi tabel dapat meningkatkan performa, dengan memungkinkan kueri hanya membaca partisi yang diperlukan.
+ Periksa kardinalitas (jumlah total baris) dari operasi gabungan Anda. Perhatikan seberapa ketat nilai yang Anda teruskan di filter untuk klausa `WHERE` Anda. Jika memungkinkan, setel kueri Anda untuk mengurangi jumlah baris yang diteruskan di setiap langkah rencana.
### Meminimalkan efek operasi pemeliharaan
Operasi pemeliharaan seperti `VACUUM` dan `ANALYZE` bersifat penting. Sebaiknya jangan dinonaktifkan karena peristiwa tunggu `IO:DataFileRead` berkaitan dengan operasi pemeliharaan ini. Pendekatan berikut dapat meminimalkan efek operasi ini:
+ Jalankan operasi pemeliharaan secara manual selama di luar jam sibuk. Teknik ini mencegah basis data mencapai ambang batas untuk operasi otomatis.
+ Untuk tabel yang sangat besar, pertimbangkan untuk mempartisi tabel. Teknik ini mengurangi overhead operasi pemeliharaan. Basis data hanya mengakses partisi yang membutuhkan pemeliharaan.
+ Saat Anda menyerap data dalam jumlah besar, coba nonaktifkan fitur analisis otomatis.
Fitur autovacuum secara otomatis dipicu untuk tabel saat rumus berikut benar.
```
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
```
Tampilan `pg_stat_user_tables` dan katalog `pg_class` berisi beberapa baris. Satu baris dapat sesuai dengan satu baris di tabel Anda. Rumus ini mengasumsikan bahwa `reltuples` adalah untuk tabel tertentu. Parameter `autovacuum_vacuum_scale_factor` (0,20 secara default) dan `autovacuum_vacuum_threshold` (50 tuple secara default) biasanya diatur secara global untuk seluruh instans. Namun, Anda dapat mengatur nilai yang berbeda untuk tabel tertentu.
**Topics**
+ [Temukan tabel yang mengonsumsi ruang secara tidak perlu](#wait-event.iodatafileread.actions.maintenance.tables)
+ [Temukan tabel yang mengonsumsi ruang secara tidak perlu](#wait-event.iodatafileread.actions.maintenance.indexes)
+ [Temukan tabel yang memenuhi syarat untuk di-autovacuum](#wait-event.iodatafileread.actions.maintenance.autovacuumed)
#### Temukan tabel yang mengonsumsi ruang secara tidak perlu
Untuk menemukan tabel yang menghabiskan ruang secara tidak perlu, Anda dapat menggunakan fungsi dari ekstensi `pgstattuple` PostgreSQL. Ekstensi (modul) ini tersedia secara default di semua instans DB RDS for PostgreSQL dan dapat diinstansiasi pada instans dengan perintah berikut.
```
CREATE EXTENSION pgstattuple;
```
Untuk informasi selengkapnya tentang ekstensi ini, lihat [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html) dalam dokumentasi PostgreSQL.
Anda dapat memeriksa bloat tabel dan indeks di aplikasi Anda. Untuk informasi selengkapnya, lihat [Mendiagnosis bloat tabel dan indeks](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html).
#### Temukan tabel yang mengonsumsi ruang secara tidak perlu
Untuk menemukan indeks yang mengalami bloat dan memperkirakan jumlah ruang yang dikonsumsi secara tidak perlu pada tabel yang hak akses bacanya Anda miliki, Anda dapat menjalankan kueri berikut.
```
-- WARNING: rows with is_na = 't' are known to have bad statistics ("name" type is not supported).
-- This query is compatible with PostgreSQL 8.2 and later.
SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size,
100 * (relpages-est_pages)::float / relpages AS extra_ratio,
fillfactor, bs*(relpages-est_pages_ff) AS bloat_size,
100 * (relpages-est_pages_ff)::float / relpages AS bloat_ratio,
is_na
-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,
-- maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages
-- (DEBUG INFO)
FROM (
SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0
-- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff,
bs, nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- , stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst,
-- index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples
-- (DEBUG INFO)
FROM (
SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +
maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
END
+ nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
WHEN nulldatawidth = 0 THEN 0
WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
ELSE nulldatawidth::integer%maxalign
END
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
-- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
FROM (
SELECT
i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,
current_setting('block_size')::numeric AS bs, fillfactor,
CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign,
/* per page header, fixed size: 20 for 7.X, 24 for others */
24 AS pagehdr,
/* per page btree opaque data */
16 AS pageopqdata,
/* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
CASE WHEN max(coalesce(s.null_frac,0)) = 0
THEN 2 -- IndexTupleData size
ELSE 2 + (( 32 + 8 - 1 ) / 8)
-- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
END AS index_tuple_hdr_bm,
/* data len: we remove null values save space using it fractionnal part from stats */
sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a
JOIN (
SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples, idx.relpages, idx.relam,
indrelid, indexrelid, indkey::smallint[] AS attnum,
coalesce(substring(
array_to_string(idx.reloptions, ' ')
from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
FROM pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid
JOIN pg_class tbl ON tbl.oid=pg_index.indrelid
JOIN pg_namespace ON pg_namespace.oid = idx.relnamespace
WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND idx.relpages > 0
) AS i ON a.attrelid = i.indexrelid
JOIN pg_stats AS s ON s.schemaname = i.nspname
AND ((s.tablename = i.tblname AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE))
-- stats from tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))
-- stats from functional cols
JOIN pg_type AS t ON a.atttypid = t.oid
WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9
) AS s1
) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE am.amname = 'btree'
) AS sub
-- WHERE NOT is_na
ORDER BY 2,3,4;
```
#### Temukan tabel yang memenuhi syarat untuk di-autovacuum
Untuk menemukan tabel yang memenuhi syarat untuk autovacuum, jalankan kueri berikut.
```
--This query shows tables that need vacuuming and are eligible candidates.
--The following query lists all tables that are due to be processed by autovacuum.
-- During normal operation, this query should return very little.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold
FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold')
, vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor
FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor')
, fma AS (SELECT setting AS autovacuum_freeze_max_age
FROM pg_settings WHERE name = 'autovacuum_freeze_max_age')
, sto AS (SELECT opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value
FROM (SELECT oid opt_oid, unnest(reloptions) setting FROM pg_class) opt)
SELECT
'"'||ns.nspname||'"."'||c.relname||'"' as relation
, pg_size_pretty(pg_table_size(c.oid)) as table_size
, age(relfrozenxid) as xid_age
, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age
, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
as autovacuum_vacuum_tuples
, n_dead_tup as dead_tuples
FROM pg_class c
JOIN pg_namespace ns ON ns.oid = c.relnamespace
JOIN pg_stat_all_tables stat ON stat.relid = c.oid
JOIN vbt on (1=1)
JOIN vsf ON (1=1)
JOIN fma on (1=1)
LEFT JOIN sto cvbt ON cvbt.param = 'autovacuum_vacuum_threshold' AND c.oid = cvbt.opt_oid
LEFT JOIN sto cvsf ON cvsf.param = 'autovacuum_vacuum_scale_factor' AND c.oid = cvsf.opt_oid
LEFT JOIN sto cfma ON cfma.param = 'autovacuum_freeze_max_age' AND c.oid = cfma.opt_oid
WHERE c.relkind = 'r'
AND nspname <> 'pg_catalog'
AND (
age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
or
coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup
-- or 1 = 1
)
ORDER BY age(relfrozenxid) DESC;
```
### Merespons jumlah koneksi yang tinggi
Saat Anda memantau Amazon CloudWatch, Anda mungkin menemukan bahwa `DatabaseConnections` metrik melonjak. Peningkatan ini menunjukkan bertambahnya jumlah koneksi ke basis data Anda. Sebaiknya lakukan pendekatan berikut:
+ Membatasi jumlah koneksi yang dapat dibuka aplikasi dengan setiap instans. Jika aplikasi Anda memiliki fitur kumpulan koneksi tertanam, tetapkan jumlah koneksi yang wajar. Dasarkan angka pada apa yang dapat diparalelkan oleh v CPUs dalam instance Anda secara efektif.
Jika aplikasi Anda tidak menggunakan fitur kumpulan koneksi, coba gunakan Proksi Amazon RDS atau alternatifnya. Pendekatan ini memungkinkan aplikasi Anda membuka beberapa koneksi dengan penyeimbang beban. Penyeimbang selanjutnya dapat membuka sejumlah koneksi terbatas dengan basis data. Karena lebih sedikit koneksi yang berjalan secara paralel, instans DB Anda melakukan lebih sedikit peralihan konteks di kernel. Kueri harus berkembang lebih cepat, yang mengarah ke lebih sedikit peristiwa tunggu. Untuk informasi selengkapnya, lihat [Proksi Amazon RDS Aurora](rds-proxy.md).
+ Jika memungkinkan, manfaatkan replika baca RDS for PostgreSQL. Saat aplikasi Anda menjalankan operasi hanya-baca, kirim permintaan ini ke replika pembaca. Teknik ini mengurangi I/O tekanan pada simpul primer (penulis).
+ Coba naikkan skala instans DB Anda. Kelas instans berkapasitas lebih tinggi memberikan memori lebih banyak, yang memberi RDS for PostgreSQL pool buffer bersama yang lebih besar untuk menampung halaman. Ukuran yang lebih besar juga memberi instans DB lebih banyak v CPUs untuk menangani koneksi. Lebih CPUs banyak v sangat membantu ketika operasi yang menghasilkan peristiwa `IO:DataFileRead` tunggu ditulis.
# IO: WALWrite
**Topics**
+ [Versi mesin yang didukung](#wait-event.iowalwrite.context.supported)
+ [Konteks](#wait-event.iowalwrite.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.iowalwrite.causes)
+ [Tindakan](#wait-event.iowalwrite.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua RDS for PostgreSQL versi 10 dan yang lebih tinggi.
## Konteks
Aktivitas dalam basis data yang menghasilkan data log write-ahead mengisi akan buffer WAL terlebih dahulu lalu menulis ke disk, secara asinkron. Peristiwa tunggu `IO:WALWrite` dihasilkan ketika sesi SQL menunggu data WAL selesai ditulis ke disk sehingga dapat melepaskan panggilan COMMIT transaksi.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Jika peristiwa tunggu ini sering terjadi, Anda harus meninjau beban kerja Anda dan jenis pembaruan yang dilakukan beban kerja Anda serta frekuensinya. Secara khusus, cari jenis aktivitas berikut.
**Aktivitas DML yang berat**
Perubahan data pada tabel basis data tidak terjadi secara instan. Penyisipan ke satu tabel mungkin perlu menunggu penyisipan atau pembaruan ke tabel yang sama dari klien lain. Pernyataan bahasa manipulasi data (DML) untuk mengubah nilai data (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) dapat mengakibatkan pertentangan sehingga file log write-ahead yang menunggu buffer di-flushing. Situasi ini dicatat dalam metrik Wawasan Performa Amazon RDS berikut yang menunjukkan aktivitas DML yang berat.
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
Untuk informasi selengkapnya tentang metrik ini, lihat [Penghitung Wawasan Performa untuk Amazon RDS for PostgreSQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL).
**Aktivitas checkpoint yang sering**
Pos pemeriksaan yang sering berkontribusi pada jumlah file WAL yang lebih tinggi. Di RDS for PostgreSQL, penulisan halaman lengkap selalu "aktif". Penulisan halaman penuh membantu melindungi dari kehilangan data. Namun, jika pembuatan checkpoint terjadi terlalu sering, sistem dapat mengalami masalah performa secara keseluruhan. Hal ini terutama berlaku pada sistem dengan aktivitas DML yang berat. Dalam beberapa kasus, Anda mungkin menemukan pesan kesalahan di `postgresql.log` Anda yang menyatakan bahwa “checkpoint terjadi terlalu sering".
Saat menyetel checkpoint, sebaiknya Anda menyeimbangkan performa dengan hati-hati berdasarkan perkiraan waktu pemulihan jika terjadi penonaktifan yang tidak normal.
## Tindakan
Kami merekomendasikan tindakan berikut untuk mengurangi jumlah peristiwa tunggu ini.
**Topics**
+ [Kurangi jumlah commit](#wait-event.iowalwrite.actions.problem)
+ [Pantau checkpoint Anda](#wait-event.iowalwrite.actions.monitor)
+ [Naikkan skala IO](#wait-event.iowalwrite.actions.scale-io)
+ [Volume log khusus (DLV)](#wait-event.iowalwrite.actions.dlv)
### Kurangi jumlah commit
Untuk mengurangi jumlah commit, gabungkan pernyataan ke dalam blok transaksi. Gunakan Wawasan Performa Amazon RDS untuk memeriksa jenis kueri yang dijalankan. Anda juga dapat memindahkan operasi pemeliharaan besar ke waktu di luar jam sibuk. Misalnya, buat indeks atau gunakan operasi `pg_repack` selama jam non-produksi.
### Pantau checkpoint Anda
Ada dua parameter yang dapat Anda pantau untuk melihat seberapa sering instans DB RDS for PostgreSQL Anda menulis ke file WAL untuk checkpoint.
+ `log_checkpoints` – Parameter ini diatur ke "aktif" secara default. Hal ini menyebabkan pesan dikirim ke log PostgreSQL untuk setiap checkpoint. Pesan log ini mencakup jumlah buffer yang ditulis, waktu yang dihabiskan untuk menulisnya, dan jumlah file WAL yang ditambahkan, dihapus, atau didaur ulang untuk checkpoint tertentu.
Untuk informasi selengkapnya tentang parameter ini, lihat [Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS) dalam dokumentasi PostgreSQL.
+ `checkpoint_warning` – Parameter ini menetapkan nilai ambang batas (dalam detik) untuk frekuensi checkpoint yang jika terlampaui, akan menghasilkan peringatan. Secara default, parameter ini tidak diatur di RDS for PostgreSQL. Anda dapat mengatur nilai parameter ini untuk mendapatkan peringatan ketika perubahan basis data di instans DB RDS for PostgreSQL Anda ditulis pada laju yang tidak dapat ditangani oleh ukuran file WAL. Misalnya, Anda mengatur parameter ini ke 30. Jika instans RDS for PostgreSQL Anda perlu menulis perubahan lebih sering daripada setiap 30 detik, peringatan bahwa "checkpoint terjadi terlalu sering" akan dikirim ke log PostgreSQL. Hal ini dapat menunjukkan bahwa nilai `max_wal_size` Anda harus ditingkatkan.
Untuk informasi selengkapnya, lihat [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS) dalam dokumentasi PostgreSQL.
### Naikkan skala IO
Jenis input/output (IO) wait event can remediated by scaling the input/output operasi per detik (IOPs) untuk menyediakan IO lebih cepat. Penskalaan IO lebih direkomendasikan daripada penskalaan CPU karena penskalaan CPU dapat menghasilkan lebih banyak pertentangan IO. Hal ini terjadi karena CPU yang ditingkatkan dapat menangani lebih banyak pekerjaan dan dengan demikian membuat bottleneck IO semakin buruk. Secara umum, kami menyarankan Anda mempertimbangkan untuk menyetel beban kerja Anda sebelum melakukan operasi penskalaan.
### Volume log khusus (DLV)
Anda dapat menggunakan volume log khusus (DLV) untuk instans DB yang menggunakan penyimpanan IOPS yang Tersedia (PIOPS) dengan menggunakan konsol Amazon RDS, AWS CLI, atau API Amazon RDS. DLV memindahkan log transaksi database PostgreSQL ke volume penyimpanan yang terpisah dari volume yang berisi tabel database. Untuk informasi selengkapnya, lihat [Volume log khusus (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).
# IPC: Acara tunggu paralel
Berikut ini `IPC:parallel wait events` menunjukkan bahwa sesi sedang menunggu komunikasi antar-proses yang terkait dengan operasi eksekusi query paralel.
+ `IPC:BgWorkerStartup`- Sebuah proses sedang menunggu proses parallel worker untuk menyelesaikan urutan startupnya. Ini terjadi ketika menginisialisasi pekerja untuk eksekusi kueri paralel.
+ `IPC:BgWorkerShutdown`- Sebuah proses sedang menunggu proses parallel worker untuk menyelesaikan urutan shutdown-nya. Ini terjadi selama fase pembersihan eksekusi query paralel.
+ `IPC:ExecuteGather`- Sebuah proses menunggu untuk menerima data dari proses pekerja paralel selama eksekusi kueri. Ini terjadi ketika proses pemimpin perlu mengumpulkan hasil dari pekerjanya.
+ `IPC:ParallelFinish`- Sebuah proses sedang menunggu pekerja paralel untuk menyelesaikan eksekusi mereka dan melaporkan hasil akhir mereka. Ini terjadi selama fase penyelesaian eksekusi query paralel.
**Topics**
+ [Versi mesin yang didukung](#rpg-ipc-parallel-context-supported)
+ [Konteks](#rpg-ipc-parallel-context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#rpg-ipc-parallel-causes)
+ [Tindakan](#rpg-ipc-parallel-actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
Eksekusi query paralel di PostgreSQL melibatkan beberapa proses yang bekerja sama untuk memproses satu query. Ketika kueri ditentukan cocok untuk paralelisasi, proses pemimpin berkoordinasi dengan satu atau lebih proses pekerja paralel berdasarkan pengaturan parameter. `max_parallel_workers_per_gather` Proses pemimpin membagi pekerjaan di antara pekerja, setiap pekerja memproses porsi datanya secara independen, dan hasilnya dikumpulkan kembali ke proses pemimpin.
**catatan**
Setiap pekerja paralel beroperasi sebagai proses terpisah dengan persyaratan sumber daya yang mirip dengan sesi pengguna penuh. Ini berarti query paralel dengan 4 pekerja dapat mengkonsumsi hingga 5 kali sumber daya (CPU, memori, I/O bandwidth) dibandingkan dengan kueri non-paralel, karena proses pemimpin dan setiap proses pekerja mempertahankan alokasi sumber daya mereka sendiri. Misalnya, pengaturan seperti diterapkan `work_mem` secara individual ke setiap pekerja, berpotensi mengalikan total penggunaan memori di semua proses.
Arsitektur query paralel terdiri dari tiga komponen utama:
+ Proses pemimpin: Proses utama yang memulai operasi paralel, membagi beban kerja, dan berkoordinasi dengan proses pekerja.
+ Proses pekerja: Proses latar belakang yang mengeksekusi bagian kueri secara paralel.
+ Gather/Gathering merge: Operasi yang menggabungkan hasil dari beberapa proses pekerja kembali ke pemimpin
Selama eksekusi paralel, proses perlu berkomunikasi satu sama lain melalui mekanisme Inter-Process Communication (IPC). Peristiwa tunggu IPC ini terjadi selama fase yang berbeda:
+ Startup pekerja: Saat pekerja paralel diinisialisasi
+ Pertukaran data: Ketika pekerja memproses data dan mengirimkan hasil kepada pemimpin
+ Worker shutdown: Ketika eksekusi paralel selesai dan pekerja dihentikan
+ Titik sinkronisasi: Ketika proses perlu mengoordinasikan atau menunggu proses lain untuk menyelesaikan tugasnya
Memahami peristiwa tunggu ini sangat penting untuk mendiagnosis masalah kinerja yang terkait dengan eksekusi kueri paralel, terutama di lingkungan konkurensi tinggi di mana beberapa kueri paralel dapat dijalankan secara bersamaan.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Beberapa faktor dapat berkontribusi pada peningkatan acara tunggu IPC terkait paralel:
**Konkurensi tinggi dari query paralel**
Ketika banyak query paralel berjalan secara bersamaan, hal itu dapat menyebabkan pertentangan sumber daya dan peningkatan waktu tunggu untuk operasi IPC. Ini sangat umum dalam sistem dengan volume transaksi tinggi atau beban kerja analitis.
**Rencana kueri paralel suboptimal**
Jika perencana kueri memilih rencana paralel yang tidak efisien, hal itu dapat mengakibatkan paralelisasi yang tidak perlu atau distribusi kerja yang buruk di antara pekerja. Hal ini dapat menyebabkan peningkatan penantian IPC, terutama untuk `IPC:ExecuteGather` dan `IPC:ParallelFinish` acara. Masalah perencanaan ini sering berasal dari statistik yang sudah ketinggalan zaman dan table/index kembung.
**Sering startup dan shutdown pekerja paralel**
Pertanyaan berumur pendek yang sering memulai dan menghentikan pekerja paralel dapat menyebabkan peningkatan dan peristiwa. `IPC:BgWorkerStartup` `IPC:BgWorkerShutdown` Ini sering terlihat pada beban kerja OLTP dengan banyak kueri kecil yang dapat diparalelkan.
**Kendala sumber daya**
CPU, memori, atau I/O kapasitas yang terbatas dapat menyebabkan kemacetan dalam eksekusi paralel, yang menyebabkan peningkatan waktu tunggu di semua peristiwa IPC. Misalnya, jika CPU jenuh, proses pekerja mungkin membutuhkan waktu lebih lama untuk memulai atau memproses bagian pekerjaan mereka.
**Struktur kueri yang kompleks**
Kueri dengan beberapa tingkat paralelisme (misalnya, gabungan paralel diikuti oleh agregasi paralel) dapat menyebabkan pola IPC yang lebih kompleks dan berpotensi meningkatkan waktu tunggu, terutama untuk acara. `IPC:ExecuteGather`
**Set hasil besar**
Kueri yang menghasilkan kumpulan hasil yang besar dapat menyebabkan peningkatan waktu `IPC:ExecuteGather` tunggu karena proses pemimpin menghabiskan lebih banyak waktu untuk mengumpulkan dan memproses hasil dari proses pekerja.
Memahami faktor-faktor ini dapat membantu dalam mendiagnosis dan mengatasi masalah kinerja yang terkait dengan eksekusi kueri paralel di Aurora PostgreSQL.
## Tindakan
Ketika Anda melihat waits terkait dengan query paralel, biasanya berarti bahwa proses backend sedang mengkoordinasikan atau menunggu proses parallel worker. Penantian ini biasa terjadi selama pelaksanaan rencana paralel. Anda dapat menyelidiki dan mengurangi dampak menunggu ini dengan memantau penggunaan pekerja paralel, meninjau pengaturan parameter, dan menyetel eksekusi kueri dan alokasi sumber daya.
**Topics**
+ [Menganalisis rencana kueri untuk paralelisme yang tidak efisien](#rpg-ipc-parallel-analyze-plans)
+ [Pantau penggunaan query parallel](#rpg-ipc-parallel-monitor)
+ [Tinjau dan sesuaikan pengaturan query parallel](#rpg-ipc-parallel-adjust-settings)
+ [Optimalkan alokasi sumber daya](#rpg-ipc-parallel-optimize-resources)
+ [Selidiki manajemen koneksi](#rpg-ipc-parallel-connection-management)
+ [Meninjau dan mengoptimalkan operasi pemeliharaan](#rpg-ipc-parallel-maintenance)
### Menganalisis rencana kueri untuk paralelisme yang tidak efisien
Eksekusi kueri paralel seringkali dapat menyebabkan ketidakstabilan sistem, lonjakan CPU, dan varians kinerja kueri yang tidak dapat diprediksi. Sangat penting untuk menganalisis secara menyeluruh apakah paralelisme benar-benar meningkatkan beban kerja spesifik Anda. Gunakan EXPLORE ANALYZE untuk meninjau rencana eksekusi query paralel.
Nonaktifkan paralelisme sementara di tingkat sesi untuk membandingkan efisiensi rencana:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
```
Aktifkan kembali paralelisme dan bandingkan:
```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE ;
```
Jika menonaktifkan paralelisme menghasilkan hasil yang lebih baik atau lebih konsisten, pertimbangkan untuk menonaktifkannya untuk kueri tertentu di tingkat sesi menggunakan perintah SET. Untuk dampak yang lebih luas, Anda mungkin ingin menonaktifkan paralelisme pada tingkat instans dengan menyesuaikan parameter yang relevan dalam grup parameter DB Anda. Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Modifying.md).
### Pantau penggunaan query parallel
Gunakan kueri berikut untuk mendapatkan visibilitas ke aktivitas dan kapasitas query paralel:
Periksa proses pekerja paralel aktif:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Kueri ini menunjukkan jumlah proses pekerja paralel aktif. Nilai tinggi mungkin menunjukkan bahwa `max\$1parallel\$1workers` Anda dikonfigurasi dengan nilai tinggi dan Anda mungkin ingin mempertimbangkan untuk menguranginya.
Periksa query paralel bersamaan:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Kueri ini mengembalikan jumlah proses pemimpin berbeda yang telah meluncurkan query paralel. Angka yang tinggi di sini menunjukkan bahwa beberapa sesi menjalankan query paralel secara bersamaan, yang dapat meningkatkan permintaan pada CPU dan memori.
### Tinjau dan sesuaikan pengaturan query parallel
Tinjau parameter berikut untuk memastikan parameter tersebut selaras dengan beban kerja Anda:
+ `max_parallel_workers`: Jumlah total pekerja paralel di semua sesi.
+ `max_parallel_workers_per_gather`: Pekerja maks per kueri.
Untuk beban kerja OLAP, meningkatkan nilai-nilai ini dapat meningkatkan kinerja. Untuk beban kerja OLTP, nilai yang lebih rendah umumnya lebih disukai.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimalkan alokasi sumber daya
Pantau pemanfaatan CPU dan pertimbangkan untuk menyesuaikan jumlah v CPUs jika secara konsisten tinggi dan jika aplikasi Anda mendapat manfaat dari query paralel. Pastikan memori yang memadai tersedia untuk operasi paralel.
+ Gunakan metrik Performance Insights untuk menentukan apakah sistem terikat CPU.
+ Setiap pekerja paralel menggunakan miliknya sendiri`work_mem`. Pastikan penggunaan memori total berada dalam batas instans.
Query paralel dapat mengkonsumsi sumber daya yang jauh lebih banyak daripada query non-paralel, karena setiap proses pekerja adalah proses yang benar-benar terpisah yang memiliki dampak yang kira-kira sama pada sistem sebagai sesi pengguna tambahan. Ini harus diperhitungkan saat memilih nilai untuk pengaturan ini, serta saat mengonfigurasi pengaturan lain yang mengontrol pemanfaatan sumber daya, seperti. `work_mem` Untuk informasi selengkapnya, lihat [Dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Batas sumber daya seperti `work_mem` diterapkan secara individual untuk setiap pekerja, yang berarti total pemanfaatan mungkin jauh lebih tinggi di semua proses daripada biasanya untuk setiap proses tunggal.
Pertimbangkan untuk meningkatkan v CPUs atau menyetel parameter memori jika beban kerja Anda sangat paralel.
### Selidiki manajemen koneksi
Jika mengalami kelelahan koneksi, tinjau strategi penyatuan koneksi aplikasi. Pertimbangkan untuk menerapkan penyatuan koneksi di tingkat aplikasi jika belum digunakan.
### Meninjau dan mengoptimalkan operasi pemeliharaan
Mengkoordinasikan pembuatan indeks dan tugas pemeliharaan lainnya untuk mencegah pertentangan sumber daya. Pertimbangkan untuk menjadwalkan operasi ini selama jam-jam di luar sibuk. Hindari penjadwalan pemeliharaan berat (misalnya, pembuatan indeks paralel) selama periode beban kueri pengguna yang tinggi. Operasi ini dapat mengkonsumsi pekerja paralel dan memengaruhi kinerja untuk kueri reguler.
# IPC: ProcArrayGroupUpdate
`IPC:ProcArrayGroupUpdate`Peristiwa terjadi ketika sesi menunggu pemimpin grup untuk memperbarui status transaksi di akhir operasi itu. Sementara PostgreSQL umumnya mengaitkan peristiwa tunggu tipe IPC dengan operasi query paralel, acara tunggu khusus ini tidak spesifik untuk query paralel.
**Topics**
+ [Versi mesin yang didukung](#apg-rpg-ipcprocarraygroup.supported)
+ [Konteks](#apg-rpg-ipcprocarraygroup.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-rpg-ipcprocarraygroup.causes)
+ [Tindakan](#apg-rpg-ipcprocarraygroup.actions)
## Versi mesin yang didukung
## Konteks
**Memahami array proses - Array** process (proc) adalah struktur memori bersama di PostgreSQL. Ini menyimpan informasi tentang semua proses yang berjalan, termasuk rincian transaksi. Selama penyelesaian transaksi (`COMMIT`atau`ROLLBACK`), ProcArray perlu diperbarui untuk mencerminkan perubahan dan menghapus TransactionId dari array. Sesi yang mencoba menyelesaikan transaksinya harus memperoleh kunci eksklusif pada. ProcArray Ini mencegah proses lain mendapatkan kunci bersama atau eksklusif di atasnya.
**Mekanisme pembaruan grup** — Saat melakukan COMMIT atau ROLLBACK, jika proses backend tidak dapat memperoleh mode eksklusif, ia memperbarui ProcArrayLock bidang khusus yang disebut. ProcArrayGroupMember Ini menambahkan transaksi ke daftar sesi yang berniat untuk berakhir. Proses backend ini kemudian tidur dan waktu tidurnya diinstrumentasi sebagai acara tunggu. ProcArrayGroupUpdate Proses pertama dalam ProcArray dengan procArrayGroup Anggota, yang disebut sebagai proses pemimpin, memperoleh ProcArrayLock mode eksklusif. Kemudian membersihkan daftar proses yang menunggu kliring TransactionId grup. Setelah ini selesai, pemimpin melepaskan ProcArrayLock dan kemudian membangunkan semua proses dalam daftar ini, memberi tahu mereka bahwa transaksi mereka selesai.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Semakin banyak proses yang berjalan, semakin lama seorang pemimpin akan berpegang pada mode eksklusif. procArrayLock Akibatnya, semakin banyak transaksi tulis berakhir dalam skenario pembaruan grup yang menyebabkan potensi tumpukan proses menunggu acara `ProcArrayGroupUpdate` tunggu. Dalam tampilan SQL Top Database Insights, Anda akan melihat bahwa COMMIT adalah pernyataan dengan sebagian besar acara tunggu ini. Ini diharapkan tetapi akan membutuhkan penyelidikan lebih dalam ke SQL tulis spesifik yang dijalankan untuk menentukan tindakan apa yang tepat untuk diambil.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Identifikasi `IPC:ProcArrayGroupUpdate` peristiwa menggunakan Amazon RDS Performance Insights atau dengan menanyakan tampilan sistem PostgreSQL. `pg_stat_activity`
**Topics**
+ [Memantau transaksi komit dan operasi rollback](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Mengurangi konkurensi](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Menerapkan penyatuan koneksi](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [Menggunakan penyimpanan yang lebih cepat](#apg-rpg-ipcprocarraygroup.actions.storage)
### Memantau transaksi komit dan operasi rollback
**Monitor commit dan rollback** — Peningkatan jumlah commit dan rollback dapat menyebabkan peningkatan tekanan pada. ProcArray Misalnya, jika pernyataan SQL mulai gagal karena meningkatnya pelanggaran kunci duplikat, Anda mungkin melihat peningkatan rollback yang dapat meningkatkan ProcArray pertengkaran dan kembung tabel.
Amazon RDS Database Insights menyediakan metrik PostgreSQL dan melaporkan jumlah commit `xact_commit` dan rollback `xact_rollback` per detik.
### Mengurangi konkurensi
**Transaksi batching** — Jika memungkinkan, operasi batch dalam transaksi tunggal untuk mengurangi commit/rollback operasi.
**Batasi konkurensi** — Kurangi jumlah transaksi yang aktif secara bersamaan untuk mengurangi perselisihan kunci pada. ProcArray Meskipun akan memerlukan beberapa pengujian, mengurangi jumlah total koneksi bersamaan dapat mengurangi pertengkaran dan mempertahankan throughput.
### Menerapkan penyatuan koneksi
**Solusi pengumpulan koneksi** - Gunakan penyatuan koneksi untuk mengelola koneksi database secara efisien, mengurangi jumlah total backend dan karenanya beban kerja pada file. ProcArray Meskipun akan memerlukan beberapa pengujian, mengurangi jumlah total koneksi bersamaan dapat mengurangi pertengkaran dan mempertahankan throughput.
**Mengurangi badai koneksi** — Demikian pula, pola sering membuat dan mengakhiri koneksi menyebabkan tekanan tambahan pada koneksi. ProcArray Dengan mengurangi pola ini, perselisihan keseluruhan berkurang.
### Menggunakan penyimpanan yang lebih cepat
**Volume log khusus** - Jika acara `IPC:ProcArrayGroupUpdate` tunggu disertai dengan peristiwa `IO:WALWrite` tunggu yang tinggi, menyiapkan volume log khusus dapat mengurangi penulisan bottleneck ke WAL. Pada gilirannya, ini meningkatkan kinerja komitmen.
Untuk informasi selengkapnya, lihat [Volume log khusus](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html).
# Lock:advisory
Peristiwa `Lock:advisory` terjadi saat aplikasi PostgreSQL menggunakan kunci untuk mengoordinasi aktivitas di beberapa sesi.
**Topics**
+ [Versi mesin yang relevan](#wait-event.lockadvisory.context.supported)
+ [Konteks](#wait-event.lockadvisory.context)
+ [Penyebab](#wait-event.lockadvisory.causes)
+ [Tindakan](#wait-event.lockadvisory.actions)
## Versi mesin yang relevan
Informasi peristiwa tunggu ini relevan untuk RDS for PostgreSQL versi 9.6 dan lebih tinggi.
## Konteks
Kunci advisory PostgreSQL adalah kunci kooperatif tingkat aplikasi yang secara eksplisit dikunci dan dibuka oleh kode aplikasi pengguna. Aplikasi dapat menggunakan kunci advisory PostgreSQL untuk mengoordinasi aktivitas di beberapa sesi. Tidak seperti kunci biasa tingkat objek atau baris, aplikasi memiliki kontrol penuh atas masa pakai kunci. Untuk informasi selengkapnya, lihat [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) dalam dokumentasi PostgreSQL.
Kunci advisory dapat dilepaskan sebelum transaksi berakhir atau disimpan oleh sesi di seluruh transaksi. Hal ini tidak berlaku untuk kunci implisit yang diberlakukan sistem, seperti kunci eksklusif akses pada tabel yang diperoleh oleh pernyataan `CREATE INDEX`.
Untuk deskripsi fungsi yang digunakan untuk memperoleh (mengunci) dan melepaskan (membuka kunci) kunci advisory, lihat [Advisory Lock Functions](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) dalam dokumentasi PostgreSQL.
Kunci advisory diimplementasikan di atas sistem penguncian PostgreSQL biasa dan terlihat dalam tampilan sistem `pg_locks`.
## Penyebab
Jenis kunci ini secara khusus dikendalikan oleh aplikasi yang secara eksplisit menggunakannya. Kunci advisory yang diperoleh untuk setiap baris sebagai bagian dari kueri dapat menyebabkan lonjakan kunci atau penumpukan jangka panjang.
Efek ini terjadi saat kueri dijalankan dengan cara yang memperoleh kunci pada lebih banyak baris daripada yang ditampilkan oleh kueri. Aplikasi pada akhirnya harus melepaskan setiap kunci, tetapi jika kunci diperoleh pada baris yang tidak ditampilkan, maka aplikasi tidak dapat menemukan semua kunci.
Contoh berikut berasal dari [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) dalam dokumentasi PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
Dalam contoh ini, klausa `LIMIT` hanya dapat menghentikan output kueri setelah baris dipilih secara internal dan nilai ID-nya dikunci. Hal ini dapat terjadi secara tiba-tiba saat volume data yang bertambah menyebabkan perencana memilih rencana eksekusi lain yang tidak diuji selama pengembangan. Penumpukan dalam kasus ini terjadi karena aplikasi secara eksplisit memanggil `pg_advisory_unlock` untuk setiap nilai ID yang terkunci. Namun, dalam kasus ini, aplikasi tidak dapat menemukan set kunci yang diperoleh pada baris yang tidak ditampilkan. Karena diperoleh pada tingkat sesi, kunci tidak dilepaskan secara otomatis pada akhir transaksi.
Kemungkinan penyebab lain untuk lonjakan upaya kunci yang diblokir adalah konflik yang tidak diinginkan. Dalam konflik ini, bagian aplikasi yang tidak terkait berbagi ruang ID kunci yang sama secara tidak sengaja.
## Tindakan
Tinjau penggunaan kunci advisory oleh aplikasi dan cari tahu secara mendetail di mana dan kapan dalam alur aplikasi setiap jenis kunci advisory diperoleh dan dilepaskan.
Ketahui apakah sesi memperoleh terlalu banyak kunci atau sesi yang berjalan lama tidak melepaskan kunci cukup awal, sehingga mengakibatkan penumpukan kunci yang lambat. Anda dapat memperbaiki penumpukan kunci tingkat sesi yang lambat dengan mengakhiri sesi menggunakan `pg_terminate_backend(pid)`.
Klien yang menunggu kunci advisory muncul dalam `pg_stat_activity` dengan `wait_event_type=Lock` dan `wait_event=advisory`. Anda dapat memperoleh nilai kunci tertentu dengan mengkueri tampilan sistem `pg_locks` untuk `pid` yang sama, dengan mencari `locktype=advisory` dan `granted=f`.
Anda kemudian dapat mengidentifikasi sesi yang memblokir dengan mengkueri `pg_locks` untuk kunci advisory serupa yang memiliki `granted=t`, seperti ditunjukkan dalam contoh berikut.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Semua fungsi API kunci advisory memiliki dua set argumen, baik satu argumen `bigint` maupun dua argumen `integer`:
+ Untuk fungsi API dengan satu argumen `bigint`, 32 bit atas berada dalam `pg_locks.classid` dan 32 bit bawah berada dalam `pg_locks.objid`.
+ Untuk fungsi API dengan dua argumen `integer`, argumen pertama adalah `pg_locks.classid` dan argumen kedua adalah `pg_locks.objid`.
Nilai `pg_locks.objsubid` menunjukkan form API yang digunakan: `1` berarti satu argumen `bigint`; `2` berarti dua argumen `integer`.
# Lock:extend
Peristiwa `Lock:extend` terjadi saat sebuah proses backend menunggu untuk mengunci relasi agar dapat diperluas, sementara proses lain mengunci relasi tersebut untuk tujuan yang sama.
**Topics**
+ [Versi mesin yang didukung](#wait-event.lockextend.context.supported)
+ [Konteks](#wait-event.lockextend.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.lockextend.causes)
+ [Tindakan](#wait-event.lockextend.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
Peristiwa `Lock:extend` menunjukkan bahwa proses backend menunggu untuk memperluas relasi yang dikunci oleh proses backend lain saat proses backend lain ini memperluas relasi tersebut. Karena hanya satu proses pada satu waktu yang dapat memperluas relasi, sistem membuat peristiwa tunggu `Lock:extend`. Operasi `INSERT`, `COPY`, dan `UPDATE` dapat menghasilkan peristiwa ini.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `Lock:extend` muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Lonjakan penyisipan atau pembaruan konkuren ke tabel yang sama **
Mungkin terdapat peningkatan jumlah sesi konkuren dengan kueri yang melakukan penyisipan atau pembaruan pada tabel yang sama.
**Bandwidth jaringan tidak cukup**
Bandwidth jaringan pada instans DB mungkin tidak cukup untuk kebutuhan komunikasi penyimpanan dari beban kerja saat ini. Hal ini dapat berkontribusi pada latensi penyimpanan yang menyebabkan peningkatan peristiwa `Lock:extend`.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Kurangi penyisipan dan pembaruan konkuren ke relasi yang sama](#wait-event.lockextend.actions.action1)
+ [Tingkatkan bandwidth jaringan](#wait-event.lockextend.actions.increase-network-bandwidth)
### Kurangi penyisipan dan pembaruan konkuren ke relasi yang sama
Pertama, ketahui apakah terdapat peningkatan pada metrik `tup_inserted` dan `tup_updated` dengan disertai peningkatan pada peristiwa tunggu ini. Jika demikian, periksa relasi yang memiliki pertentangan tinggi untuk operasi penyisipan dan pembaruan. Untuk menentukan hal ini, jalankan kueri tampilan `pg_stat_all_tables` untuk nilai pada bidang `n_tup_ins` dan `n_tup_upd`. Untuk informasi tentang tampilan `pg_stat_all_tables`, lihat [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) dalam dokumentasi PostgreSQL.
Untuk mendapatkan informasi selengkapnya tentang pemblokiran dan kueri yang diblokir, jalankan kueri `pg_stat_activity` seperti contoh berikut:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Setelah Anda mengidentifikasi relasi yang berkontribusi pada peningkatan peristiwa `Lock:extend`, gunakan teknik berikut untuk mengurangi pertentangan:
+ Cari tahu apakah Anda dapat menggunakan pemartisian untuk mengurangi pertentangan pada tabel yang sama. Memisahkan tuple yang disisipkan atau diperbarui ke dalam partisi yang berbeda dapat mengurangi pertentangan. Untuk informasi tentang partisi, lihat [Mengelola partisi PostgreSQL dengan ekstensi pg\$1partman](PostgreSQL_Partitions.md).
+ Jika peristiwa tunggu terutama disebabkan oleh aktivitas pembaruan, pertimbangkan untuk mengurangi nilai faktor pengisian relasi. Hal ini dapat mengurangi permintaan untuk blok baru selama pembaruan. Faktor pengisian adalah parameter penyimpanan untuk tabel yang menentukan jumlah maksimum ruang untuk melakukan packing halaman tabel. Hal ini dinyatakan sebagai persentase dari total ruang untuk sebuah halaman. Untuk informasi selengkapnya tentang parameter fillfactor, lihat [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) dalam dokumentasi PostgreSQL.
**penting**
Kami sangat merekomendasikan untuk menguji sistem jika Anda mengubah faktor pengisian karena mengubah nilai ini dapat berdampak negatif pada performa, tergantung pada beban kerja Anda.
### Tingkatkan bandwidth jaringan
Untuk melihat apakah terdapat peningkatan latensi tulis, periksa metrik `WriteLatency` di CloudWatch. Jika ada, gunakan metrik `WriteThroughput` dan `ReadThroughput` Amazon CloudWatch untuk memantau lalu lintas terkait penyimpanan pada klaster DB. Metrik ini dapat membantu Anda menentukan apakah bandwidth jaringan cukup untuk aktivitas penyimpanan beban kerja Anda.
Jika bandwidth jaringan Anda tidak cukup, tingkatkan. Jika instans DB Anda mencapai batas bandwidth jaringan, satu-satunya cara untuk meningkatkan bandwidth adalah meningkatkan ukuran instans DB Anda.
Untuk informasi selengkapnya tentang metrik CloudWatch, lihat [Metrik CloudWatch tingkat instans Amazon untuk Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). Untuk informasi tentang performa jaringan untuk setiap kelas instans DB, lihat [Metrik CloudWatch tingkat instans Amazon untuk Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
# Lock:Relation
Peristiwa `Lock:Relation` terjadi saat kueri menunggu untuk memperoleh kunci pada tabel atau tampilan (relasi) yang saat ini dikunci oleh transaksi lain.
**Topics**
+ [Versi mesin yang didukung](#wait-event.lockrelation.context.supported)
+ [Konteks](#wait-event.lockrelation.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.lockrelation.causes)
+ [Tindakan](#wait-event.lockrelation.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
Sebagian besar perintah PostgreSQL secara implisit menggunakan kunci untuk mengontrol akses konkuren ke data dalam tabel. Anda juga dapat menggunakan kunci ini secara eksplisit dalam kode aplikasi Anda dengan perintah `LOCK`. Banyak mode kunci yang tidak kompatibel satu sama lain, dan mode ini dapat memblokir transaksi saat mencoba mengakses objek yang sama. Ketika ini terjadi, RDS for PostgreSQL akan menghasilkan peristiwa `Lock:Relation`. Berikut adalah beberapa contoh umum:
+ Kunci eksklusif seperti `ACCESS EXCLUSIVE` dapat memblokir semua akses konkuren. Operasi bahasa definisi data (DDL) seperti `DROP TABLE`, `TRUNCATE`, `VACUUM FULL`, dan `CLUSTER` memperoleh kunci `ACCESS EXCLUSIVE` secara implisit. `ACCESS EXCLUSIVE` juga merupakan mode kunci default untuk pernyataan `LOCK TABLE` yang tidak menentukan mode secara eksplisit.
+ Menggunakan `CREATE INDEX (without CONCURRENT)` pada tabel akan bertentangan dengan pernyataan bahasa manipulasi data (DML) `UPDATE`, `DELETE`, dan `INSERT`, yang memperoleh kunci `ROW EXCLUSIVE`.
Untuk informasi selengkapnya tentang kunci tingkat tabel dan mode kunci yang bertentangan, lihat [Explicit Locking](https://www.postgresql.org/docs/13/explicit-locking.html) dalam dokumentasi PostgreSQL.
Kueri dan transaksi yang memblokir biasanya dapat dibuka blokirnya dengan salah satu cara berikut:
+ Kueri yang memblokir – Aplikasi dapat membatalkan kueri atau pengguna dapat mengakhiri proses. Mesin juga dapat memaksa kueri untuk berakhir karena batas waktu pernyataan sesi atau mekanisme deteksi deadlock.
+ Transaksi yang memblokir – Transaksi berhenti memblokir saat menjalankan pernyataan `ROLLBACK` atau `COMMIT`. Rollback juga terjadi secara otomatis saat sesi diputus oleh klien atau masalah jaringan, atau diakhiri. Sesi dapat berakhir saat mesin basis data dimatikan, sistem kehabisan memori, dan sebagainya.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `Lock:Relation` terjadi lebih sering dari biasanya, hal tersebut dapat menunjukkan masalah performa. Penyebab umumnya meliputi yang berikut:
**Peningkatan sesi konkuren dengan kunci tabel yang bertentangan**
Mungkin ada peningkatan jumlah sesi konkuren dengan kueri yang mengunci tabel yang sama dengan mode kunci yang bertentangan.
**Operasi pemeliharaan**
Operasi pemeliharaan kondisi seperti `VACUUM` dan `ANALYZE` dapat secara signifikan meningkatkan jumlah kunci yang bertentangan. `VACUUM FULL` memperoleh kunci `ACCESS EXCLUSIVE`, dan `ANALYSE` memperoleh kunci `SHARE UPDATE EXCLUSIVE`. Kedua jenis kunci tersebut dapat menyebabkan peristiwa tunggu `Lock:Relation`. Operasi pemeliharaan data aplikasi seperti menyegarkan tampilan terwujud juga dapat meningkatkan kueri dan transaksi yang diblokir.
**Kunci pada instans pembaca**
Mungkin ada pertentangan antara kunci relasi yang dipegang oleh penulis dan pembaca. Saat ini, hanya kunci relasi `ACCESS EXCLUSIVE` yang direplikasi ke instans pembaca. Namun, kunci relasi `ACCESS EXCLUSIVE` akan bertentangan dengan kunci relasi `ACCESS SHARE` yang dipegang oleh pembaca. Hal ini dapat menyebabkan peningkatan peristiwa tunggu relasi kunci pada pembaca.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Kurangi dampak pemblokiran pernyataan SQL](#wait-event.lockrelation.actions.reduce-blocks)
+ [Minimalkan efek operasi pemeliharaan](#wait-event.lockrelation.actions.maintenance)
### Kurangi dampak pemblokiran pernyataan SQL
Untuk mengurangi dampak pemblokiran pernyataan SQL, ubah kode aplikasi Anda jika memungkinkan. Berikut adalah dua teknik umum untuk mengurangi pemblokiran:
+ Gunakan opsi `NOWAIT` – Beberapa perintah SQL, seperti pernyataan `SELECT` dan `LOCK`, mendukung opsi ini. Arahan `NOWAIT` membatalkan kueri permintaan kunci jika kunci tidak dapat segera diperoleh. Teknik ini dapat membantu mencegah sesi yang memblokir menyebabkan penumpukan sesi yang diblokir di belakangnya.
Misalnya: Transaksi A sedang menunggu kunci yang dipegang oleh transaksi B. Jika B meminta kunci pada tabel yang dikunci oleh transaksi C, transaksi A mungkin diblokir hingga transaksi C selesai. Namun, jika transaksi B menggunakan `NOWAIT` saat meminta kunci pada C, transaksi ini dapat gagal cepat (fail fast) dan memastikan bahwa transaksi A tidak harus menunggu tanpa batas waktu.
+ Gunakan `SET lock_timeout` – Tetapkan nilai `lock_timeout` untuk membatasi waktu tunggu pernyataan SQL dalam memperoleh kunci pada relasi. Jika kunci tidak diperoleh dalam batas waktu yang ditentukan, transaksi yang meminta kunci akan dibatalkan. Tetapkan nilai ini pada tingkat sesi.
### Minimalkan efek operasi pemeliharaan
Operasi pemeliharaan seperti `VACUUM` dan `ANALYZE` bersifat penting. Sebaiknya jangan dinonaktifkan karena peristiwa tunggu `Lock:Relation` berkaitan dengan operasi pemeliharaan ini. Pendekatan berikut dapat meminimalkan efek operasi ini:
+ Jalankan operasi pemeliharaan secara manual di luar jam sibuk.
+ Untuk mengurangi peristiwa tunggu `Lock:Relation` yang disebabkan oleh tugas autovacuum, lakukan penyetelan autovacuum yang diperlukan. Untuk informasi tentang menyetel autovacuum, lihat [Menggunakan autovacuum PostgreSQL di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) dalam *Panduan Pengguna Amazon RDS*.
# Lock:transactionid
Peristiwa `Lock:transactionid` terjadi saat transaksi sedang menunggu kunci tingkat baris.
**Topics**
+ [Versi mesin yang didukung](#wait-event.locktransactionid.context.supported)
+ [Konteks](#wait-event.locktransactionid.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.locktransactionid.causes)
+ [Tindakan](#wait-event.locktransactionid.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
Peristiwa `Lock:transactionid` terjadi saat transaksi mencoba memperoleh kunci tingkat baris yang telah diberikan untuk transaksi yang sedang berlangsung pada saat bersamaan. Sesi yang menunjukkan peristiwa tunggu `Lock:transactionid` diblokir karena kunci ini. Setelah transaksi yang memblokir berakhir dengan pernyataan `COMMIT` atau `ROLLBACK`, transaksi yang diblokir dapat dilanjutkan.
Semantik kontrol konkurensi multiversi dari RDS for PostgreSQL menjamin bahwa pembaca tidak memblokir penulis dan penulis tidak memblokir pembaca. Agar pertentangan tingkat baris terjadi, transaksi yang memblokir dan diblokir harus mengeluarkan pernyataan yang bertentangan dari jenis berikut:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
Pernyataan `SELECT … FOR KEY SHARE` adalah kasus khusus. Basis data menggunakan klausa `FOR KEY SHARE` untuk mengoptimalkan performa integritas referensial. Kunci tingkat baris pada baris dapat memblokintah `INSERT`, `UPDATE`, dan `DELETE` pada tabel lain yang mereferensikan baris tersebut.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa ini ditampilkan lebih dari biasanya, penyebabnya biasanya adalah pernyataan `UPDATE`, `SELECT … FOR UPDATE`, atau `SELECT … FOR KEY SHARE` yang dikombinasikan dengan kondisi berikut.
**Topics**
+ [Konkurensi tinggi](#wait-event.locktransactionid.concurrency)
+ [Idle pada transaksi](#wait-event.locktransactionid.idle)
+ [Transaksi yang berjalan lama](#wait-event.locktransactionid.long-running)
### Konkurensi tinggi
Aurora PostgreSQL dapat menggunakan semantik penguncian tingkat baris terperinci. Probabilitas pertentangan tingkat baris meningkat saat kondisi berikut terpenuhi:
+ Beberapa beban kerja yang sangat konkuren bersaing untuk baris yang sama.
+ Konkurensi meningkat.
### Idle pada transaksi
Terkadang kolom `pg_stat_activity.state` menunjukkan nilai `idle in transaction`. Nilai ini ditampilkan untuk sesi yang telah memulai transaksi, tetapi belum mengeluarkan `COMMIT` atau `ROLLBACK`. Jika nilai `pg_stat_activity.state` bukan `active`, kueri yang ditampilkan pada `pg_stat_activity` adalah yang paling baru diselesaikan. Sesi yang memblokir tidak secara aktif memproses kueri karena transaksi yang terbuka menahan kunci.
Jika transaksi yang idle memperoleh kunci tingkat baris, transaksi tersebut mungkin mencegah sesi lain memperolehnya. Kondisi ini menyebabkan peristiwa tunggu `Lock:transactionid` sering terjadi. Untuk mendiagnosis masalah, periksa output dari `pg_stat_activity` dan `pg_locks`.
### Transaksi yang berjalan lama
Transaksi yang berjalan dalam waktu lama akan mendapatkan kunci untuk waktu lama. Kunci yang lama dipegang ini dapat memblokir transaksi lain sehingga tidak berjalan.
## Tindakan
Penguncian baris adalah pertentangan antara pernyataan `UPDATE`, `SELECT … FOR UPDATE`, atau `SELECT … FOR KEY SHARE`. Sebelum mencoba solusi, cari tahu kapan pernyataan ini berjalan pada baris yang sama. Gunakan informasi ini untuk memilih strategi yang dijelaskan pada bagian berikut.
**Topics**
+ [Tangani konkurensi tinggi](#wait-event.locktransactionid.actions.problem)
+ [Tangani transaksi idle](#wait-event.locktransactionid.actions.find-blocker)
+ [Tangani transaksi yang berjalan lama](#wait-event.locktransactionid.actions.concurrency)
### Tangani konkurensi tinggi
Jika masalahnya adalah konkurensi, coba salah satu teknik berikut:
+ Turunkan konkurensi pada aplikasi. Misalnya, kurangi jumlah sesi aktif.
+ Terapkan pool koneksi. Untuk mempelajari cara melakukan pooling koneksi dengan Proksi RDS, lihat [Proksi Amazon RDS Aurora](rds-proxy.md).
+ Desain aplikasi atau model data untuk menghindari pertentangan pernyataan `UPDATE` dan `SELECT … FOR UPDATE`. Anda juga dapat mengurangi jumlah kunci asing yang diakses oleh pernyataan `SELECT … FOR KEY SHARE`.
### Tangani transaksi idle
Jika `pg_stat_activity.state` menampilkan `idle in transaction`, gunakan strategi berikut:
+ Aktifkan autocommit saat memungkinkan. Pendekatan ini mencegah transaksi memblokir transaksi lain sambil menunggu `COMMIT` atau `ROLLBACK`.
+ Cari jalur kode yang tidak memiliki `COMMIT`, `ROLLBACK`, atau `END`.
+ Pastikan logika penanganan pengecualian pada aplikasi Anda selalu memiliki jalur ke `end of transaction` yang valid.
+ Pastikan bahwa aplikasi Anda memproses hasil kueri setelah mengakhiri transaksi dengan `COMMIT` atau `ROLLBACK`.
### Tangani transaksi yang berjalan lama
Jika transaksi yang berjalan lama menyebabkan `Lock:transactionid` sering terjadi, coba strategi berikut:
+ Cegah kunci baris dari transaksi jangka panjang.
+ Batasi panjang kueri dengan menerapkan autocommit jika memungkinkan.
# Lock:tuple
Peristiwa `Lock:tuple` terjadi saat proses backend menunggu untuk memperoleh kunci pada tuple.
**Topics**
+ [Versi mesin yang didukung](#wait-event.locktuple.context.supported)
+ [Konteks](#wait-event.locktuple.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.locktuple.causes)
+ [Tindakan](#wait-event.locktuple.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
Peristiwa `Lock:tuple` menunjukkan bahwa backend menunggu untuk memperoleh kunci pada tuple, sementara backend lain memegang kunci yang bertentangan pada tuple yang sama. Tabel berikut menggambarkan skenario saat sesi membuat peristiwa `Lock:tuple`.
| Waktu | Sesi 1 | Sesi 2 | Sesi 3 |
| --- | --- | --- | --- |
| t1 | Memulai transaksi. | | |
| t2 | Memperbarui baris 1. | | |
| t3 | | Memperbarui baris 1. Sesi ini mendapatkan kunci eksklusif pada tuple, lalu menunggu sesi 1 untuk melepaskan kunci dengan melakukan komit atau rollback. | |
| t4 | | | Memperbarui baris 1. Sesi ini menunggu sesi 2 untuk melepaskan kunci eksklusif pada tuple. |
Atau Anda dapat mensimulasikan peristiwa tunggu ini dengan menggunakan alat tolok ukur `pgbench`. Konfigurasikan jumlah sesi konkuren yang tinggi untuk memperbarui baris yang sama pada tabel dengan file SQL kustom.
Untuk mempelajari selengkapnya tentang mode kunci yang bertentangan, lihat [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html) dalam dokumentasi PostgreSQL. Untuk mempelajari selengkapnya tentang `pgbench`, lihat [pgbench](https://www.postgresql.org/docs/current/pgbench.html) dalam dokumentasi PostgreSQL.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa ini muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
+ Sejumlah besar sesi konkuren mencoba mendapatkan kunci yang bertentangan untuk tuple yang sama dengan menjalankan pernyataan `UPDATE` atau `DELETE`.
+ Beberapa sesi yang sangat konkuren menjalankan pernyataan `SELECT` menggunakan mode kunci `FOR UPDATE` atau `FOR NO KEY UPDATE`.
+ Berbagai faktor mendorong aplikasi atau pool koneksi untuk membuka lebih banyak sesi agar menjalankan operasi yang sama. Saat sesi baru mencoba memodifikasi baris yang sama, beban DB dapat melonjak, dan `Lock:tuple` dapat ditampilkan.
Untuk informasi selengkapnya, lihat [Row-Level Locks](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) dalam dokumentasi PostgreSQL.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Selidiki logika aplikasi](#wait-event.locktuple.actions.problem)
+ [Temukan sesi pemblokir](#wait-event.locktuple.actions.find-blocker)
+ [Kurangi konkurensi saat tinggi](#wait-event.locktuple.actions.concurrency)
+ [Pecahkan masalah bottleneck](#wait-event.locktuple.actions.bottlenecks)
### Selidiki logika aplikasi
Cari tahu apakah sesi pemblokir telah berada pada status `idle in transaction` dalam waktu yang lama. Jika demikian, coba akhiri sesi pemblokir sebagai solusi jangka pendek. Anda dapat menggunakan fungsi `pg_terminate_backend`. Untuk informasi selengkapnya tentang fungsi ini, lihat [Server Signaling Functions](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) dalam dokumentasi PostgreSQL.
Untuk solusi jangka panjang, lakukan hal berikut:
+ Sesuaikan logika aplikasi.
+ Gunakan parameter `idle_in_transaction_session_timeout`. Parameter ini mengakhiri sesi apa pun dengan transaksi terbuka yang telah idle lebih lama dari jumlah waktu yang ditentukan. Untuk informasi selengkapnya, lihat [Client Connection Defaults](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) dalam dokumentasi PostgreSQL.
+ Gunakan autocommit sebanyak mungkin. Untuk informasi selengkapnya, lihat [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) dalam dokumentasi PostgreSQL.
### Temukan sesi pemblokir
Saat peristiwa tunggu `Lock:tuple` terjadi, identifikasi pemblokir dan sesi yang diblokir dengan mencari tahu kunci mana yang bergantung satu sama lain. Untuk informasi selengkapnya, lihat [Lock dependency information](https://wiki.postgresql.org/wiki/Lock_dependency_information) dalam wiki PostgreSQL.
Contoh berikut mengkueri semua sesi, memfilter `tuple`, dan mengurutkan berdasarkan `wait_time`.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
### Kurangi konkurensi saat tinggi
Peristiwa `Lock:tuple` mungkin terjadi terus-menerus, terutama pada waktu beban kerja yang sibuk. Dalam situasi ini, pertimbangkan untuk mengurangi konkurensi tinggi untuk baris yang sangat sibuk. Sering kali, hanya beberapa baris mengontrol antrean atau logika Boolean, sehingga membuat baris ini sangat sibuk.
Anda dapat mengurangi konkurensi dengan menggunakan pendekatan yang berbeda berdasarkan kebutuhan bisnis, logika aplikasi, dan jenis beban kerja. Misalnya, Anda dapat melakukan hal berikut:
+ Desain ulang tabel dan logika data Anda untuk mengurangi konkurensi tinggi.
+ Ubah logika aplikasi untuk mengurangi konkurensi tinggi di tingkat baris.
+ Manfaatkan dan desain ulang kueri dengan kunci tingkat baris.
+ Gunakan klausa `NOWAIT` dengan operasi percobaan ulang.
+ Pertimbangkan untuk menggunakan kontrol konkurensi logika optimistis dan kontrol konkurensi logika penguncian hibrid.
+ Pertimbangkan untuk mengubah tingkat isolasi basis data.
### Pecahkan masalah bottleneck
`Lock:tuple` dapat terjadi dengan bottleneck seperti "CPU starvation" atau penggunaan maksimum bandwidth Amazon EBS. Untuk mengurangi bottleneck, pertimbangkan pendekatan berikut:
+ Naikkan skala jenis kelas instans Anda.
+ Optimalkan kueri sarat sumber daya.
+ Ubah logika aplikasi.
+ Arsipkan data yang jarang diakses.
# LWLock: BufferMapping (:buffer\$1mapping) LWLock
Peristiwa ini terjadi saat sesi menunggu untuk mengaitkan blok data dengan buffer di pool buffer bersama.
**catatan**
Peristiwa ini dinamai `LWLock:BufferMapping` untuk RDS for PostgreSQL versi 13 dan versi yang lebih tinggi. Untuk RDS for PostgreSQL versi 12 dan versi yang lebih lama, peristiwa ini dinamai `LWLock:buffer_mapping`.
**Topics**
+ [Versi mesin yang didukung](#wait-event.lwl-buffer-mapping.context.supported)
+ [Konteks](#wait-event.lwl-buffer-mapping.context)
+ [Penyebab](#wait-event.lwl-buffer-mapping.causes)
+ [Tindakan](#wait-event.lwl-buffer-mapping.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini relevan untuk RDS for PostgreSQL versi 9.6 dan lebih tinggi.
## Konteks
*Pool buffer bersama* adalah area memori PostgreSQL yang menampung semua halaman yang sedang atau telah digunakan oleh proses. Ketika suatu proses membutuhkan halaman, proses ini membacakan halaman tersebut ke dalam pool buffer bersama. Parameter `shared_buffers` menetapkan ukuran buffer bersama dan menyediakan area memori untuk menyimpan halaman tabel dan indeks. Jika Anda mengganti parameter ini, pastikan untuk mengaktifkan ulang basis data.
Peristiwa `LWLock:buffer_mapping` tunggu terjadi dalam skenario berikut:
+ Sebuah proses mencari tabel buffer untuk halaman dan memperoleh kunci pemetaan buffer bersama.
+ Sebuah proses memuat halaman ke dalam pool buffer dan memperoleh kunci pemetaan buffer eksklusif.
+ Sebuah proses menghapus halaman dari pool dan memperoleh kunci pemetaan buffer eksklusif.
## Penyebab
Ketika peristiwa ini muncul lebih sering dari biasanya, yang mungkin menunjukkan masalah performa, basis data akan melakukan paging masuk dan keluar pada pool buffer bersama. Penyebab umumnya meliputi yang berikut:
+ Kueri besar
+ Indeks dan tabel yang mengalami bloat
+ Pemindaian tabel lengkap
+ Ukuran pool bersama yang lebih kecil dari working set
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.
**Topics**
+ [Pantau metrik terkait buffer](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [Evaluasi strategi pengindeksan Anda](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [Kurangi jumlah buffer yang harus dialokasikan dengan cepat](#wait-event.lwl-buffer-mapping.actions.buffers)
### Pantau metrik terkait buffer
Saat `LWLock:buffer_mapping` menunggu lonjakan, selidiki rasio hit buffer. Anda dapat menggunakan metrik ini untuk mendapatkan pemahaman yang lebih baik tentang apa yang terjadi di cache buffer. Periksa metrik berikut:
`blks_hit`
Metrik penghitung Wawasan Performa ini menunjukkan jumlah blok yang diambil dari pool buffer bersama. Setelah peristiwa tunggu `LWLock:buffer_mapping` muncul, Anda mungkin melihat lonjakan `blks_hit`.
`blks_read`
Metrik penghitung Performance Insights ini menunjukkan jumlah blok yang perlu dibaca I/O ke dalam kumpulan buffer bersama. Anda mungkin melihat lonjakan `blks_read` menjelang peristiwa tunggu `LWLock:buffer_mapping`.
### Evaluasi strategi pengindeksan Anda
Untuk mengonfirmasi bahwa strategi pengindeksan Anda tidak menurunkan performa, periksa hal berikut:
Bloat indeks
Pastikan bloat indeks dan tabel tidak menyebabkan halaman yang tidak perlu dibacakan ke buffer bersama. Jika tabel Anda berisi baris yang tidak digunakan, pertimbangkan untuk mengarsipkan datanya dan menghapus baris tersebut dari tabel. Anda kemudian dapat membuat kembali indeks untuk tabel yang diubah ukurannya.
Indeks untuk kueri yang sering digunakan
Untuk menentukan apakah Anda memiliki indeks optimal, pantau metrik mesin DB di Wawasan Performa. Metrik `tup_returned` menunjukkan jumlah baris yang dibaca. Metrik `tup_fetched` menunjukkan jumlah baris yang dikembalikan ke klien. Jika `tup_returned` secara signifikan lebih besar dari `tup_fetched`, data mungkin tidak diindeks dengan benar. Selain itu, statistik tabel Anda mungkin tidak terkini.
### Kurangi jumlah buffer yang harus dialokasikan dengan cepat
Untuk mengurangi peristiwa tunggu `LWLock:buffer_mapping`, coba kurangi jumlah buffer yang harus dialokasikan dengan cepat. Salah satu strateginya adalah dengan melakukan operasi batch yang lebih kecil. Anda mungkin dapat memiliki batch yang lebih kecil dengan mempartisi tabel Anda.
# LWLock:Bufferio (IPC: Bufferio)
`LWLock:BufferIO`Peristiwa ini terjadi ketika RDS untuk PostgreSQL sedang menunggu proses lain untuk menyelesaikan operasi (I/O) input/output mereka ketika secara bersamaan mencoba mengakses halaman. Tujuannya adalah agar halaman yang sama dibacakan ke buffer bersama.
**Topics**
+ [Versi mesin yang relevan](#wait-event.lwlockbufferio.context.supported)
+ [Konteks](#wait-event.lwlockbufferio.context)
+ [Penyebab](#wait-event.lwlockbufferio.causes)
+ [Tindakan](#wait-event.lwlockbufferio.actions)
## Versi mesin yang relevan
Informasi peristiwa tunggu ini relevan untuk semua versi RDS for PostgreSQL. Untuk RDS for PostgreSQL 12 dan versi sebelumnya peristiwa tunggu ini dinamai lwlock:buffer\$1io sedangkan di RDS for PostgreSQL versi 13 dinamai lwlock:bufferio. Mulai dari RDS for PostgreSQL versi 14, peristiwa tunggu BufferIO dipindahkan dari jenis peristiwa tunggu `LWLock` ke `IPC` (IPC:BufferIO).
## Konteks
Setiap buffer bersama memiliki I/O kunci yang terkait dengan peristiwa `LWLock:BufferIO` tunggu, setiap kali blok (atau halaman) harus diambil di luar kumpulan buffer bersama.
Kunci ini digunakan untuk menangani beberapa sesi yang semuanya memerlukan akses ke blok yang sama. Blok ini harus dibaca dari luar pool buffer bersama, yang ditentukan oleh parameter `shared_buffers`.
Segera setelah halaman dibaca di dalam kumpulan buffer bersama, kunci `LWLock:BufferIO` akan dilepaskan.
**catatan**
Peristiwa tunggu `LWLock:BufferIO` mendahului peristiwa tunggu [IO: DataFileRead](wait-event.iodatafileread.md). Peristiwa tunggu `IO:DataFileRead` terjadi saat data sedang dibaca dari penyimpanan.
Untuk informasi selengkapnya tentang kunci ringan, lihat [Gambaran Umum Penguncian](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Penyebab
Penyebab umum peristiwa `LWLock:BufferIO` muncul dalam peristiwa tunggu teratas mencakup yang berikut:
+ Beberapa backend atau koneksi mencoba mengakses halaman yang sama yang juga menunggu operasi I/O
+ Rasio antara ukuran pool buffer bersama (ditentukan oleh parameter `shared_buffers`) dan jumlah buffer yang dibutuhkan oleh beban kerja saat ini
+ Ukuran pool buffer bersama tidak seimbang dengan jumlah halaman yang dikosongkan oleh operasi lain
+ Indeks besar atau bloat yang mengharuskan mesin membacakan lebih banyak halaman daripada yang diperlukan ke dalam pool buffer bersama
+ Kurangnya indeks yang memaksa mesin DB untuk membaca lebih banyak halaman dari tabel daripada yang diperlukan
+ Checkpoint terjadi terlalu sering atau perlu melakukan flushing terlalu banyak halaman yang dimodifikasi
+ Lonjakan tiba-tiba untuk koneksi basis data yang mencoba melakukan operasi pada halaman yang sama
## Tindakan
Kami merekomendasikan berbagai tindakan tergantung pada penyebab peristiwa tunggu Anda:
+ Setel `max_wal_size` dan `checkpoint_timeout` berdasarkan waktu puncak beban kerja Anda jika Anda melihat `LWLock:BufferIO` bertepatan dengan penurunan metrik `BufferCacheHitRatio`. Kemudian, identifikasi kueri mana yang mungkin menyebabkannya.
+ Verifikasi apakah Anda memiliki indeks yang tidak digunakan, lalu hapus.
+ Gunakan tabel yang dipartisi (yang juga memiliki indeks yang dipartisi). Dengan melakukan hal ini, Anda dapat menjaga penyusunan ulang indeks tetap rendah dan mengurangi dampaknya.
+ Hindari kolom pengindeksan yang tidak perlu.
+ Cegah lonjakan koneksi basis data yang tiba-tiba dengan menggunakan pool koneksi.
+ Batasi jumlah maksimum koneksi ke basis data sebagai praktik terbaik.
# LWLock:buffer\$1content (BufferContent)
Peristiwa `LWLock:buffer_content` terjadi saat suatu sesi menunggu untuk membaca atau menulis halaman data di memori sementara sesi lain mengunci halaman tersebut untuk penulisan. Di RDS for PostgreSQL 13 dan yang lebih tinggi, peristiwa tunggu ini disebut `BufferContent`.
**Topics**
+ [Versi mesin yang didukung](#wait-event.lwlockbuffercontent.context.supported)
+ [Konteks](#wait-event.lwlockbuffercontent.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.lwlockbuffercontent.causes)
+ [Tindakan](#wait-event.lwlockbuffercontent.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
Untuk membaca atau memanipulasi data, PostgreSQL mengaksesnya melalui buffer memori bersama. Untuk membaca dari buffer, proses mendapatkan kunci ringan (LWLock) pada konten buffer dalam mode bersama. Untuk menulis ke buffer, proses ini mendapatkan kunci tersebut dalam mode eksklusif. Kunci bersama memungkinkan proses lain untuk secara konkuren memperoleh kunci bersama pada konten tersebut. Kunci eksklusif mencegah proses lain mendapatkan jenis kunci apa pun.
Peristiwa `LWLock:buffer_content` (`BufferContent`) menunjukkan bahwa beberapa proses mencoba mendapatkan kunci pada konten buffer tertentu.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa `LWLock:buffer_content` (`BufferContent`) muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:
**Peningkatan pembaruan konkuren ke data yang sama**
Mungkin ada peningkatan jumlah sesi konkuren dengan kueri yang memperbarui konten buffer yang sama. Pertentangan ini bisa lebih terlihat pada tabel dengan banyak indeks.
**Data beban kerja tidak ada dalam memori**
Saat data yang diproses oleh beban kerja aktif tidak ada dalam memori, peristiwa tunggu ini dapat meningkat. Efek ini terjadi karena proses yang memegang kunci dapat mempertahankannya lebih lama saat melakukan operasi I/O disk.
**Penggunaan batasan kunci asing yang berlebihan**
Batasan kunci asing dapat meningkatkan jumlah waktu saat sebuah proses memegang kunci konten buffer. Efek ini terjadi karena operasi baca memerlukan kunci konten buffer bersama pada kunci yang direferensikan saat kunci tersebut diperbarui.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Anda dapat mengidentifikasi peristiwa `LWLock:buffer_content` (`BufferContent`) dengan menggunakan Wawasan Performa Amazon RDS atau dengan mengkueri tampilan `pg_stat_activity`.
**Topics**
+ [Meningkatkan efisiensi dalam memori](#wait-event.lwlockbuffercontent.actions.in-memory)
+ [Kurangi penggunaan batasan kunci asing](#wait-event.lwlockbuffercontent.actions.foreignkey)
+ [Hapus indeks yang tidak digunakan](#wait-event.lwlockbuffercontent.actions.indexes)
+ [Tingkatkan ukuran cache saat menggunakan urutan](#wait-event.lwlockbuffercontent.actions.sequences)
### Meningkatkan efisiensi dalam memori
Untuk meningkatkan kemungkinan data beban kerja aktif ada di memori, partisi tabel atau naikkan skala kelas instans Anda. Untuk informasi tentang kelas instans DB, lihat [ DB](Concepts.DBInstanceClass.md).
### Kurangi penggunaan batasan kunci asing
Selidiki beban kerja yang mengalami jumlah peristiwa tunggu `LWLock:buffer_content` (`BufferContent`) yang tinggi untuk penggunaan batasan kunci asing. Hapus batasan kunci asing yang tidak perlu.
### Hapus indeks yang tidak digunakan
Untuk beban kerja yang mengalami jumlah peristiwa tunggu `LWLock:buffer_content` (`BufferContent`) yang tinggi, identifikasi indeks yang tidak digunakan, lalu hapus.
### Tingkatkan ukuran cache saat menggunakan urutan
Jika tabel Anda menggunakan urutan, tingkatkan ukuran cache untuk menghapus pertentangan pada halaman urutan dan halaman indeks. Setiap urutan adalah satu halaman dalam memori bersama. Cache yang telah ditentukan adalah per koneksi. Ini mungkin tidak cukup untuk menangani beban kerja ketika banyak sesi konkuren mendapatkan nilai urutan.
# LWLock:lock\$1manager (manajer kunci) LWLock
Peristiwa ini terjadi saat mesin RDS for PostgreSQL mempertahankan area memori kunci bersama untuk mengalokasikan, memeriksa, dan mendealokasikan kunci saat kunci jalur cepat tidak memungkinkan.
**Topics**
+ [Versi mesin yang didukung](#wait-event.lw-lock-manager.context.supported)
+ [Konteks](#wait-event.lw-lock-manager.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.lw-lock-manager.causes)
+ [Tindakan](#wait-event.lw-lock-manager.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini relevan untuk RDS for PostgreSQL versi 9.6 dan lebih tinggi. Untuk rilis RDS for PostgreSQL yang lebih lama dari versi 13, nama peristiwa tunggu ini adalah `LWLock:lock_manager`. Untuk RDS for PostgreSQL versi 13 dan yang lebih tinggi, nama peristiwa tunggu ini adalah `LWLock:lockmanager`.
## Konteks
Saat Anda mengeluarkan pernyataan SQL, RDS for PostgreSQL mencatat kunci untuk melindungi struktur, data, dan integritas basis data Anda selama operasi konkuren. Mesin dapat mencapai tujuan ini menggunakan kunci jalur cepat atau kunci jalur yang tidak cepat. Kunci jalur yang tidak cepat lebih mahal dan menghasilkan lebih banyak overhead daripada kunci jalur cepat.
### Penguncian jalur cepat
Untuk mengurangi overhead kunci yang sering diambil dan dilepaskan, tetapi jarang bertentangan, proses backend dapat menggunakan penguncian jalur cepat. Basis data menggunakan mekanisme ini untuk kunci yang memenuhi kriteria berikut:
+ Kunci tersebut menggunakan metode kunci DEFAULT.
+ Kunci tersebut merepresentasikan kunci pada relasi basis data, bukan relasi bersama.
+ Kunci tersebut adalah kunci lemah yang tidak mungkin bertentangan.
+ Mesin dapat dengan cepat memverifikasi bahwa tidak ada kunci yang mungkin dapat bertentangan.
Mesin tidak dapat menggunakan penguncian jalur cepat jika salah satu kondisi berikut ini berlaku:
+ Kunci tidak memenuhi kriteria di atas.
+ Tidak ada lagi slot yang tersedia untuk proses backend.
Untuk menyetel kueri Anda untuk penguncian jalur cepat, Anda dapat menggunakan kueri berikut.
```
SELECT count(*), pid, mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 4,3,2
ORDER BY pid, mode;
count | pid | mode | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock | t
```
Kueri berikut hanya menunjukkan total di seluruh basis data.
```
SELECT count(*), mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 3,2
ORDER BY mode,1;
count | mode | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock | t
(3 rows)
```
Untuk informasi selengkapnya tentang penguncian jalur cepat, lihat [fast path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) dalam README pengelola kunci PostgreSQL dan [pg-locks](https://www.postgresql.org/docs/9.3/view-pg-locks.html#AEN98195) dalam dokumentasi PostgreSQL.
### Contoh masalah penskalaan untuk pengelola kunci
Dalam contoh ini, tabel bernama `purchases` menyimpan data dari rentang waktu lima tahun, yang dipartisi berdasarkan hari. Setiap partisi memiliki dua indeks. Urutan peristiwa berikut terjadi:
1. Anda mengueri data dari rentang waktu beberapa hari, yang mengharuskan basis data untuk membaca banyak partisi.
1. Basis data membuat entri kunci untuk setiap partisi. Jika indeks partisi adalah bagian dari jalur akses pengoptimisasi, basis data juga akan membuat entri kunci untuk indeks tersebut.
1. Saat jumlah entri kunci yang diminta untuk proses backend yang sama lebih tinggi dari 16, yang merupakan nilai `FP_LOCK_SLOTS_PER_BACKEND`, pengelola kunci menggunakan metode kunci jalur yang tidak cepat.
Aplikasi modern mungkin memiliki ratusan sesi. Jika sesi konkuren mengueri induk tanpa pemangkasan partisi yang tepat, basis data mungkin membuat ratusan atau bahkan ribuan kunci jalur yang tidak cepat. Biasanya, ketika konkurensi ini lebih tinggi dari jumlah vCPUs, acara `LWLock:lock_manager` tunggu muncul.
**catatan**
Peristiwa tunggu `LWLock:lock_manager` tidak terkait dengan jumlah partisi atau indeks dalam skema basis data. Sebagai gantinya, hal ini terkait dengan jumlah kunci jalur yang tidak cepat yang harus dikontrol oleh basis data.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Saat peristiwa tunggu `LWLock:lock_manager` terjadi lebih sering dari biasanya, yang mungkin menunjukkan masalah performa, kemungkinan penyebab lonjakan yang mendadak ini adalah sebagai berikut:
+ Sesi aktif konkuren menjalankan kueri yang tidak menggunakan kunci jalur cepat. Sesi ini juga melebihi vCPU maksimum.
+ Sejumlah besar sesi aktif konkuren mengakses tabel yang memiliki banyak partisi. Setiap partisi memiliki beberapa indeks.
+ Basis data mengalami badai koneksi. Secara default, beberapa aplikasi dan perangkat lunak pool koneksi akan membuat lebih banyak koneksi ketika basis data lambat. Praktik ini memperburuk masalahnya. Setel perangkat lunak pool koneksi Anda sehingga badai koneksi tidak terjadi.
+ Sejumlah besar sesi mengueri tabel induk tanpa memangkas partisi.
+ Bahasa definisi data (DL), bahasa manipulasi data (DL), atau perintah pemeliharaan secara khusus mengunci relasi sibuk atau tuple yang sering diakses atau dimodifikasi.
## Tindakan
Jika peristiwa tunggu `CPU` terjadi, hal ini tidak selalu menunjukkan masalah performa. Tanggapi peristiwa ini hanya ketika performa menurun dan peristiwa tunggu ini mendominasi beban DB.
**Topics**
+ [Gunakan pemangkasan partisi](#wait-event.lw-lock-manager.actions.pruning)
+ [Hapus indeks yang tidak perlu](#wait-event.lw-lock-manager.actions.indexes)
+ [Setel kueri Anda untuk penguncian jalur cepat](#wait-event.lw-lock-manager.actions.tuning)
+ [Setel peristiwa tunggu lainnya](#wait-event.lw-lock-manager.actions.other-waits)
+ [Kurangi bottleneck perangkat keras](#wait-event.lw-lock-manager.actions.hw-bottlenecks)
+ [Gunakan pooler koneksi](#wait-event.lw-lock-manager.actions.pooler)
+ [Tingkatkan versi RDS for PostgreSQL Anda](#wait-event.lw-lock-manager.actions.pg-version)
### Gunakan pemangkasan partisi
*Pemangkasan partisi* adalah strategi optimisasi kueri untuk tabel yang dipartisi secara deklaratif yang mengecualikan partisi yang tidak dibutuhkan dari pemindaian tabel, sehingga meningkatkan performa. Pemangkasan partisi diaktifkan secara default. Jika dinonaktifkan, aktifkan sebagai berikut.
```
SET enable_partition_pruning = on;
```
Kueri dapat memanfaatkan pemangkasan partisi ketika klausa `WHERE`-nya berisi kolom yang digunakan untuk pembuatan partisi. Untuk informasi selengkapnya, lihat [Partition Pruning](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) dalam dokumentasi PostgreSQL.
### Hapus indeks yang tidak perlu
Basis data Anda mungkin berisi indeks yang tidak digunakan atau jarang digunakan. Jika demikian, pertimbangkan untuk menghapusnya. Lakukan salah satu dari langkah berikut:
+ Pelajari cara menemukan indeks yang tidak perlu dengan membaca [Indeks yang Tidak Digunakan](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) di wiki PostgreSQL.
+ Jalankan PG Collector. Skrip SQL ini mengumpulkan informasi basis data dan menyajikannya dalam laporan HTML terkonsolidasi. Periksa bagian “Indeks yang tidak digunakan”. Untuk informasi selengkapnya, lihat [pg-collector di repositori](https://github.com/awslabs/pg-collector) AWS Labs GitHub .
### Setel kueri Anda untuk penguncian jalur cepat
Untuk mengetahui apakah kueri Anda menggunakan penguncian jalur cepat, buat kueri pada kolom `fastpath` dalam tabel `pg_locks`. Jika kueri Anda tidak menggunakan penguncian jalur cepat, coba kurangi jumlah relasi per kueri menjadi kurang dari 16.
### Setel peristiwa tunggu lainnya
Jika `LWLock:lock_manager` adalah yang pertama atau kedua dalam daftar peristiwa tunggu teratas, periksa apakah peristiwa tunggu berikut juga ditampilkan pada daftar ini:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Jika peristiwa di atas ditampilkan pada posisi tinggi dalam daftar, pertimbangkan untuk menyetel peristiwa tunggu ini terlebih dahulu. Peristiwa ini dapat menjadi pendorong untuk `LWLock:lock_manager`.
### Kurangi bottleneck perangkat keras
Anda mungkin memiliki bottleneck perangkat keras, seperti kelaparan CPU atau penggunaan maksimum bandwidth Amazon EBS Anda. Jika demikian, maka pertimbangkan untuk mengurangi bottleneck perangkat keras. Pertimbangkan tindakan berikut:
+ Naikkan kelas instans Anda.
+ Optimalkan kueri yang mengonsumsi CPU dan memori dalam jumlah besar.
+ Ubah logika aplikasi Anda.
+ Arsipkan data Anda.
Untuk informasi selengkapnya tentang CPU, memori, dan bandwidth jaringan EBS, lihat [Jenis Instans Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Gunakan pooler koneksi
Jika jumlah total koneksi aktif Anda melebihi vCPU maksimum, lebih banyak proses OS akan memerlukan CPU yang melampaui kapasitas yang dapat didukung oleh jenis instans Anda. Jika demikian, pertimbangkan untuk menggunakan atau menyetel pool koneksi. Untuk informasi selengkapnya tentang v CPUs untuk jenis instans Anda, lihat [Jenis Instans Amazon RDS](https://aws.amazon.com/rds/instance-types/).
Untuk informasi selengkapnya tentang pooling koneksi, lihat sumber daya berikut:
+ [Proksi Amazon RDS Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Connection Pools and Data Sources](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) dalam *dokumentasi PostgreSQL*
### Tingkatkan versi RDS for PostgreSQL Anda
Jika versi RDS for PostgreSQL Anda saat ini lebih rendah dari 12, tingkatkan ke versi 12 atau lebih tinggi. PostgreSQL versi 12 dan yang lebih baru memiliki mekanisme partisi yang ditingkatkan. Untuk informasi selengkapnya tentang versi 12, lihat [Catatan Rilis PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Untuk informasi selengkapnya tentang meningkatkan RDS for PostgreSQL, lihat [Upgrade RDS untuk mesin PostgreSQL DB](USER_UpgradeDBInstance.PostgreSQL.md).
# LWLock:pg\$1stat\$1statement
Peristiwa LWLock tunggu: PG\$1STAT\$1Statements terjadi ketika ekstensi `pg_stat_statements` mengambil kunci eksklusif pada tabel hash yang melacak pernyataan SQL. Ini terjadi dalam skenario berikut:
+ Ketika jumlah pernyataan yang dilacak mencapai nilai `pg_stat_statements.max` parameter yang dikonfigurasi dan ada kebutuhan untuk memberi ruang untuk lebih banyak entri, ekstensi melakukan pengurutan pada jumlah panggilan, menghapus 5% dari pernyataan yang paling tidak dieksekusi, dan mengisi ulang hash dengan entri yang tersisa.
+ Ketika `pg_stat_statements` melakukan `garbage collection` operasi ke `pgss_query_texts.stat` file pada disk dan menulis ulang file.
**Topics**
+ [Versi mesin yang didukung](#apg-rpg-lwlockpgstat.supported)
+ [Konteks](#apg-rpg-lwlockpgstat.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#apg-rpg-lwlockpgstat.causes)
+ [Tindakan](#apg-rpg-lwlockpgstat.actions)
## Versi mesin yang didukung
## Konteks
**Memahami ekstensi pg\$1stat\$1statement - Ekstensi** pg\$1stat\$1statement melacak statistik eksekusi pernyataan SQL dalam tabel hash. Ekstensi melacak pernyataan SQL hingga batas yang ditentukan oleh `pg_stat_statements.max` parameter. Parameter ini menentukan jumlah maksimum pernyataan yang dapat dilacak yang sesuai dengan jumlah maksimum baris dalam tampilan pg\$1stat\$1statement.
**Persistensi statistik pernyataan** — Ekstensi mempertahankan statistik pernyataan di seluruh instans dimulai ulang dengan:
+ Menulis data ke file bernama pg\$1stat\$1statements.stat
+ Menggunakan parameter pg\$1stat\$1statements.save untuk mengontrol perilaku persistensi
Ketika pg\$1stat\$1statements.save diatur ke:
+ aktif (default): Statistik disimpan saat shutdown dan dimuat ulang saat server dimulai
+ off: Statistik tidak disimpan saat shutdown atau dimuat ulang saat server dimulai
**Penyimpanan teks kueri** — Ekstensi menyimpan teks kueri yang dilacak dalam file bernama. `pgss_query_texts.stat` File ini dapat tumbuh menjadi dua kali lipat ukuran rata-rata semua pernyataan SQL yang dilacak sebelum pengumpulan sampah terjadi. Ekstensi memerlukan kunci eksklusif pada tabel hash selama operasi pembersihan dan menulis ulang `pgss_query_texts.stat` file.
**Proses deallocation pernyataan** — Ketika jumlah pernyataan yang dilacak mencapai `pg_stat_statements.max` batas dan pernyataan baru perlu dilacak, ekstensi:
+ Mengambil kunci eksklusif: pg\$1stat\$1statement) LWLock pada tabel hash.
+ Memuat data yang ada ke dalam memori lokal.
+ Melakukan quicksort berdasarkan jumlah panggilan.
+ Menghapus pernyataan yang paling tidak disebut (5% bawah).
+ Mengisi ulang tabel hash dengan entri yang tersisa.
**Monitoring statement deallocation** — Di PostgreSQL 14 dan yang lebih baru, Anda dapat memantau deallocation pernyataan menggunakan tampilan pg\$1stat\$1statements\$1info. Tampilan ini mencakup kolom dealloc yang menunjukkan berapa kali pernyataan dialokasikan untuk memberi ruang bagi yang baru
Jika deallocation pernyataan sering terjadi, itu akan menyebabkan pengumpulan sampah `pgss_query_texts.stat` file yang lebih sering pada disk.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Penyebab khas peningkatan `LWLock:pg_stat_statements` menunggu meliputi:
+ Peningkatan jumlah kueri unik yang digunakan oleh aplikasi.
+ Nilai `pg_stat_statements.max` parameter menjadi kecil dibandingkan dengan jumlah query unik yang digunakan.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Anda dapat mengidentifikasi `LWLock:pg_stat_statements` peristiwa dengan menggunakan Amazon RDS Performance Insights atau dengan menanyakan tampilan. `pg_stat_activity`
Sesuaikan `pg_stat_statements` parameter berikut untuk mengontrol perilaku pelacakan dan kurangi: LWLock pg\$1stat\$1 statement wait events.
**Topics**
+ [Nonaktifkan parameter pg\$1stat\$1statements.track](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Meningkatkan parameter pg\$1stat\$1statements.max](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Nonaktifkan parameter pg\$1stat\$1statements.track\$1utility](#apg-rpg-lwlockpgstat.actions.disableutility)
### Nonaktifkan parameter pg\$1stat\$1statements.track
Jika peristiwa:pg\$1stat\$1statement LWLock wait berdampak buruk pada kinerja database, dan solusi cepat diperlukan sebelum analisis lebih lanjut dari tampilan `pg_stat_statements` untuk mengidentifikasi akar penyebab, parameter dapat dinonaktifkan dengan menyetelnya ke. `pg_stat_statements.track` `none` Ini akan menonaktifkan pengumpulan statistik pernyataan.
### Meningkatkan parameter pg\$1stat\$1statements.max
Untuk mengurangi deallocation dan meminimalkan pengumpulan sampah `pgss_query_texts.stat` file pada disk, tingkatkan nilai `pg_stat_statements.max` parameter. Nilai default-nya adalah `5,000`.
**catatan**
`pg_stat_statements.max`Parameternya statis. Anda harus memulai ulang instans DB Anda untuk menerapkan perubahan apa pun pada parameter ini.
### Nonaktifkan parameter pg\$1stat\$1statements.track\$1utility
Anda dapat menganalisis tampilan pg\$1stat\$1statement untuk menentukan perintah utilitas mana yang paling banyak menggunakan sumber daya yang dilacak. `pg_stat_statements`
`pg_stat_statements.track_utility`Parameter mengontrol apakah modul melacak perintah utilitas, yang mencakup semua perintah kecuali SELECT, INSERT, UPDATE, DELETE, dan MERGE. Secara default, parameter ini diatur ke`on`.
Misalnya, ketika aplikasi Anda menggunakan banyak kueri savepoint, yang secara inheren unik, itu dapat meningkatkan deallocation pernyataan. Untuk mengatasinya, Anda dapat menonaktifkan `pg_stat_statements.track_utility` parameter untuk berhenti melacak `pg_stat_statements` kueri savepoint.
**catatan**
`pg_stat_statements.track_utility`Parameternya adalah parameter dinamis. Anda dapat mengubah nilainya tanpa memulai ulang instance database Anda.
**Example Contoh kueri titik simpan unik di pg\$1stat\$1statement**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 memperkenalkan beberapa penyempurnaan untuk pelacakan perintah utilitas:
+ Nama Savepoint sekarang ditampilkan sebagai konstanta.
+ Global Transaction IDs (GIDs) dari perintah komit dua fase sekarang ditampilkan sebagai konstanta.
+ Nama pernyataan DEALLOCATE ditampilkan sebagai konstanta.
+ Parameter CALL sekarang ditampilkan sebagai konstanta.
# LWLock:subtransslru (:) LWLock SubtransControlLock
Peristiwa `LWLock:SubtransSLRU` dan `LWLock:SubtransBuffer` tunggu menunjukkan bahwa sesi sedang menunggu untuk mengakses cache sederhana yang paling tidak baru digunakan (SLRU) untuk informasi subtransaksi. Ini terjadi ketika menentukan visibilitas transaksi dan hubungan orang tua-anak.
+ `LWLock:SubtransSLRU`: Sebuah proses sedang menunggu untuk mengakses cache sederhana yang paling tidak baru digunakan (SLRU) untuk subtransaksi. Dalam RDS untuk PostgreSQL sebelum versi 13, acara tunggu ini dipanggil. `SubtransControlLock`
+ `LWLock:SubtransBuffer`: Sebuah proses I/O sedang menunggu buffer sederhana yang paling tidak baru digunakan (SLRU) untuk subtransaksi. Dalam RDS untuk PostgreSQL sebelum versi 13, acara tunggu ini dipanggil. `subtrans`
**Topics**
+ [Versi mesin yang didukung](#wait-event.lwlocksubtransslru.supported)
+ [Konteks](#wait-event.lwlocksubtransslru.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.lwlocksubtransslru.causes)
+ [Tindakan](#wait-event.lwlocksubtransslru.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
**Memahami subtransaksi** — Subtransaksi adalah transaksi dalam transaksi di PostgreSQL. Ini juga dikenal sebagai transaksi bersarang.
Subtransaksi biasanya dibuat saat Anda menggunakan:
+ `SAVEPOINT`perintah
+ Blok pengecualian (`BEGIN/EXCEPTION/END`)
Subtransaksi memungkinkan Anda memutar kembali bagian transaksi tanpa mempengaruhi seluruh transaksi. Ini memberi Anda kontrol halus atas manajemen transaksi.
**Detail implementasi** - PostgreSQL mengimplementasikan subtransaksi sebagai struktur bersarang dalam transaksi utama. Setiap subtransaksi mendapatkan ID transaksinya sendiri.
Aspek implementasi kunci:
+ Transaksi IDs dilacak di `pg_xact`
+ Hubungan orangtua-anak disimpan dalam subdirektori di bawah `pg_subtrans` `PGDATA`
+ Setiap sesi database dapat mempertahankan hingga `64` subtransaksi aktif
+ Melebihi batas ini menyebabkan luapan subtransaksi, yang mengharuskan mengakses cache sederhana yang paling tidak baru digunakan (SLRU) untuk informasi subtransaksi
## Kemungkinan penyebab peningkatan peristiwa tunggu
Penyebab umum pertengkaran SLRU subtransaksi meliputi:
+ **Penggunaan berlebihan penanganan SAVEPOINT dan EXCEPTION** — PL/pgSQL prosedur dengan `EXCEPTION` handler secara otomatis membuat savepoint implisit, terlepas dari apakah pengecualian terjadi. Masing-masing `SAVEPOINT` memulai subtransaksi baru. Ketika satu transaksi mengakumulasi lebih dari 64 subtransaksi, itu memicu overflow SLRU subtransaksi.
+ **Konfigurasi driver dan ORM** — `SAVEPOINT` penggunaan dapat eksplisit dalam kode aplikasi atau implisit melalui konfigurasi driver. Banyak alat ORM dan kerangka kerja aplikasi yang umum digunakan mendukung transaksi bersarang secara native. Berikut adalah beberapa contoh umum:
+ Parameter driver JDBC`autosave`, jika disetel ke `always` atau`conservative`, menghasilkan savepoint sebelum setiap kueri.
+ Definisi transaksi Spring Framework saat disetel ke`propagation_nested`.
+ Rel saat `requires_new: true` diatur.
+ SQLAlchemy kapan `session.begin_nested` digunakan.
+ Django ketika `atomic()` blok bersarang digunakan.
+ GORM saat `Savepoint` digunakan.
+ psqlodbc ketika pengaturan tingkat rollback diatur ke rollback tingkat pernyataan (misalnya,). `PROTOCOL=7.4-2`
+ **Beban kerja bersamaan yang tinggi dengan transaksi dan subtransaksi yang berjalan lama — Ketika overflow SLRU subtransaksi terjadi selama beban kerja** bersamaan yang tinggi dan transaksi serta subtransaksi yang berjalan lama, PostgreSQL mengalami peningkatan pertengkaran. Ini bermanifestasi sebagai peristiwa menunggu `LWLock:SubtransBuffer` dan `LWLock:SubtransSLRU` mengunci yang tinggi.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Beberapa tindakan memberikan bantuan segera, sementara yang lain memerlukan penyelidikan dan koreksi jangka panjang.
**Topics**
+ [Memantau penggunaan subtransaksi](#wait-event.lwlocksubtransslru.actions.monitor)
+ [Mengkonfigurasi parameter memori](#wait-event.lwlocksubtransslru.actions.memory)
+ [Tindakan jangka panjang](#wait-event.lwlocksubtransslru.actions.longterm)
### Memantau penggunaan subtransaksi
Untuk PostgreSQL versi 16.1 dan yang lebih baru, gunakan kueri berikut untuk memantau jumlah subtransaksi dan status overflow per backend. Kueri ini menggabungkan statistik backend dengan informasi aktivitas untuk menunjukkan proses mana yang menggunakan subtransaksi:
```
SELECT a.pid, usename, query, state, wait_event_type,
wait_event, subxact_count, subxact_overflowed
FROM (SELECT id, pg_stat_get_backend_pid(id) pid, subxact_count, subxact_overflowed
FROM pg_stat_get_backend_idset() id
JOIN LATERAL pg_stat_get_backend_subxact(id) AS s ON true
) a
JOIN pg_stat_activity b ON a.pid = b.pid;
```
Untuk PostgreSQL versi 13.3 dan yang lebih baru, pantau `pg_stat_slru` tampilan untuk tekanan cache subtransaction. Kueri SQL berikut mengambil statistik cache SLRU untuk komponen Subtrans:
```
SELECT * FROM pg_stat_slru WHERE name = 'Subtrans';
```
`blks_read`Nilai yang meningkat secara konsisten menunjukkan akses disk yang sering untuk subtransaksi yang tidak di-cache, menandakan potensi tekanan cache SLRU.
### Mengkonfigurasi parameter memori
Untuk PostgreSQL 17.1 dan yang lebih baru, Anda dapat mengonfigurasi ukuran cache SLRU subtransaksi menggunakan parameter. `subtransaction_buffers` Contoh konfigurasi berikut menunjukkan cara mengatur parameter buffer subtransaction:
```
subtransaction_buffers = 128
```
Parameter ini menentukan jumlah memori bersama yang digunakan untuk cache konten subtransaksi ()`pg_subtrans`. Ketika ditentukan tanpa unit, nilai mewakili blok `BLCKSZ` byte, biasanya 8KB masing-masing. Misalnya, mengatur nilai ke 128 mengalokasikan 1MB (128 \$1 8kB) memori untuk cache subtransaksi.
**catatan**
Anda dapat mengatur parameter ini di tingkat cluster sehingga semua instance tetap konsisten. Uji dan sesuaikan nilainya agar sesuai dengan persyaratan beban kerja spesifik dan kelas instance Anda. Anda harus me-reboot instance writer agar perubahan parameter diterapkan.
### Tindakan jangka panjang
+ **Periksa kode dan konfigurasi aplikasi** — Tinjau kode aplikasi dan konfigurasi driver database Anda untuk penggunaan eksplisit dan implisit serta `SAVEPOINT` penggunaan subtransaksi secara umum. Identifikasi transaksi yang berpotensi menghasilkan lebih dari 64 subtransaksi.
+ **Kurangi penggunaan savepoint** — Minimalkan penggunaan savepoint dalam transaksi Anda:
+ Tinjau PL/pgSQL prosedur dan fungsi dengan blok EXCEPTION. Blok EXCEPTION secara otomatis membuat savepoint implisit, yang dapat berkontribusi pada overflow subtransaksi. Setiap klausa EXCEPTION membuat subtransaksi, terlepas dari apakah pengecualian benar-benar terjadi selama eksekusi.
**Example**
Contoh 1: Penggunaan blok PENGECUALIAN yang bermasalah
Contoh kode berikut menunjukkan penggunaan blok EXCEPTION bermasalah yang menciptakan beberapa subtransaksi:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
BEGIN
-- This creates a subtransaction for each iteration
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW());
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
EXCEPTION
WHEN unique_violation THEN
-- Handle duplicate audit entries
UPDATE user_audit
SET timestamp = NOW()
WHERE user_id = user_record.id AND action = 'processed';
END;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
Contoh kode yang ditingkatkan berikut mengurangi penggunaan subtransaksi dengan menggunakan UPSERT alih-alih penanganan pengecualian:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
-- Use UPSERT to avoid exception handling
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW())
ON CONFLICT (user_id, action)
DO UPDATE SET timestamp = NOW();
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
**Example**
Contoh 2: Penangan pengecualian KETAT
Contoh kode berikut menunjukkan penanganan EXCEPTION bermasalah dengan NO\$1DATA\$1FOUND:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
BEGIN
-- STRICT causes an exception if no rows or multiple rows found
SELECT email INTO STRICT user_email
FROM users
WHERE id = p_user_id;
RETURN user_email;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 'Email not found';
END;
END;
$$ LANGUAGE plpgsql;
```
Contoh kode yang ditingkatkan berikut menghindari subtransaksi dengan menggunakan IF NOT FOUND alih-alih penanganan pengecualian:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
SELECT email INTO user_email
FROM users
WHERE id = p_user_id;
IF NOT FOUND THEN
RETURN 'Email not found';
ELSE
RETURN user_email;
END IF;
END;
$$ LANGUAGE plpgsql;
```
+ Driver JDBC — `autosave` Parameter, jika diatur ke `always` atau`conservative`, menghasilkan savepoint sebelum setiap kueri. Evaluasi apakah `never` pengaturan akan dapat diterima untuk aplikasi Anda.
+ Driver PostgreSQL ODBC (psqlodBC) - Pengaturan level rollback (untuk rollback tingkat pernyataan) menciptakan savepoint implisit untuk mengaktifkan fungsionalitas rollback pernyataan. Evaluasi apakah tingkat transaksi atau tidak ada rollback dapat diterima untuk aplikasi Anda.
+ Periksa konfigurasi transaksi ORM
+ Pertimbangkan strategi penanganan kesalahan alternatif yang tidak memerlukan savepoint
+ **Optimalkan desain transaksi** — Merestrukturisasi transaksi untuk menghindari penyarangan yang berlebihan dan mengurangi kemungkinan kondisi overflow subtransaksi.
+ **Mengurangi transaksi jangka panjang — Transaksi** jangka panjang dapat memperburuk masalah subtransaksi dengan menahan informasi subtransaksi lebih lama. Pantau metrik Performance Insights dan konfigurasikan `idle_in_transaction_session_timeout` parameter untuk menghentikan transaksi idle secara otomatis.
+ Monitor Metrik Performance Insights — Melacak metrik termasuk `idle_in_transaction_count` (jumlah sesi dalam keadaan idle dalam keadaan transaksi) dan `idle_in_transaction_max_time` (durasi transaksi idle yang berjalan paling lama) untuk mendeteksi transaksi yang berjalan lama.
+ Konfigurasi `idle_in_transaction_session_timeout` - Tetapkan parameter ini di grup parameter Anda untuk secara otomatis menghentikan transaksi idle setelah durasi yang ditentukan.
+ Pemantauan proaktif — Memantau kejadian tinggi `LWLock:SubtransBuffer` dan `LWLock:SubtransSLRU` menunggu peristiwa untuk mendeteksi pertikaian terkait subtransaksi sebelum menjadi kritis.
# Timeout:PgSleep
Peristiwa `Timeout:PgSleep` terjadi saat proses server telah memanggil fungsi `pg_sleep` dan menunggu batas waktu tidur berakhir.
**Topics**
+ [Versi mesin yang didukung](#wait-event.timeoutpgsleep.context.supported)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.timeoutpgsleep.causes)
+ [Tindakan](#wait-event.timeoutpgsleep.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Peristiwa tunggu ini terjadi saat aplikasi, fungsi tersimpan, atau pengguna mengeluarkan pernyataan SQL yang memanggil salah satu fungsi berikut:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Fungsi tersebut menunda eksekusi sampai jumlah detik yang ditentukan telah berlalu. Misalnya, `SELECT pg_sleep(1)` melakukan penundaan selama 1 detik. Untuk informasi selengkapnya, lihat [Delaying Execution](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) dalam dokumentasi PostgreSQL.
## Tindakan
Identifikasi pernyataan yang menjalankan fungsi `pg_sleep`. Tentukan apakah penggunaan fungsi tersebut sesuai.
# Timeout:VacuumDelay
Peristiwa `Timeout:VacuumDelay` menunjukkan bahwa batas biaya untuk I/O vakum telah terlampaui dan bahwa proses vakum telah dibuat tidur. Operasi vakum berhenti selama durasi yang ditentukan dalam parameter penundaan biaya masing-masing lalu melanjutkan pekerjaannya. Untuk perintah vakum manual, penundaan ditentukan dalam parameter `vacuum_cost_delay`. Untuk daemon autovacuum, penundaan ditentukan dalam `autovacuum_vacuum_cost_delay parameter.`
**Topics**
+ [Versi mesin yang didukung](#wait-event.timeoutvacuumdelay.context.supported)
+ [Konteks](#wait-event.timeoutvacuumdelay.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.timeoutvacuumdelay.causes)
+ [Tindakan](#wait-event.timeoutvacuumdelay.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi RDS for PostgreSQL.
## Konteks
PostgreSQL memiliki daemon autovacuum dan perintah vakum manual. Proses autovacuum “aktif” secara default untuk instans DB RDS for PostgreSQL. Perintah vakum manual digunakan sesuai kebutuhan, misalnya, untuk melakukan purging tabel tuple mati atau menghasilkan statistik baru.
Saat pemvakuman sedang berlangsung, PostgreSQL menggunakan penghitung internal untuk melacak perkiraan biaya seiring sistem melakukan berbagai operasi I/O. Ketika penghitung mencapai nilai yang ditentukan oleh parameter batas biaya, proses yang melakukan operasi akan tidur selama durasi singkat yang ditentukan dalam parameter penundaan biaya. Kemudian, proses ini akan mengatur ulang penghitung dan melanjutkan operasi.
Proses vakum memiliki parameter yang dapat digunakan untuk mengatur konsumsi sumber daya. Autovacuum dan perintah vakum manual memiliki parameter sendiri untuk menetapkan nilai batas biaya. Keduanya juga memiliki parameter sendiri untuk menentukan penundaan biaya, yaitu jumlah waktu untuk membuat proses vakum menjadi tidur ketika batasnya tercapai. Dengan cara ini, parameter penundaan biaya berfungsi sebagai mekanisme throttling untuk konsumsi sumber daya. Dalam daftar berikut, Anda dapat menemukan deskripsi parameter ini.
**Parameter yang mempengaruhi throttling daemon autovacuum**
+ `[autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)` – Menentukan nilai batas biaya yang akan digunakan dalam operasi vakum otomatis. Jika pengaturan untuk parameter ini ditingkatkan, proses vakum dapat menggunakan lebih banyak sumber daya dan peristiwa tunggu `Timeout:VacuumDelay` akan berkurang.
+ `[autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)` – Menentukan nilai penundaan biaya yang akan digunakan dalam operasi vakum otomatis. Nilai default adalah 2 milidetik. Mengatur parameter penundaan ke 0 akan menonaktifkan mekanisme throttling dan dengan demikian, peristiwa tunggu `Timeout:VacuumDelay` tidak akan muncul.
Untuk informasi selengkapnya, lihat [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY) dalam dokumentasi PostgreSQL.
**Parameter yang memengaruhi throttling proses vakum manual**
+ `vacuum_cost_limit` – Ambang batas yang membuat proses pemvakuman menjadi tidur. Secara default, batasnya adalah 200. Angka ini merepresentasikan perkiraan biaya terakumulasi untuk I/O tambahan yang dibutuhkan oleh berbagai sumber daya. Meningkatkan nilai ini akan mengurangi jumlah peristiwa tunggu `Timeout:VacuumDelay`.
+ `vacuum_cost_delay` – Jumlah waktu proses vakum tidur ketika batas biaya vakum telah tercapai. Pengaturan default adalah 0, yang berarti fitur ini tidak aktif. Anda dapat mengaturnya ke nilai bilangan bulat untuk menentukan jumlah milidetik untuk mengaktifkan fitur ini, tetapi kami sarankan Anda membiarkannya di pengaturan default.
Untuk informasi selengkapnya tentang parameter `vacuum_cost_delay`, lihat [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST) dalam dokumentasi PostgreSQL.
Untuk mempelajari selengkapnya tentang cara mengonfigurasi dan menggunakan autovacuum dengan RDS for PostgreSQL, lihat [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
## Kemungkinan penyebab peningkatan peristiwa tunggu
`Timeout:VacuumDelay` dipengaruhi oleh keseimbangan antara pengaturan parameter batas biaya (`vacuum_cost_limit`, `autovacuum_vacuum_cost_limit`) dan parameter penundaan biaya (`vacuum_cost_delay`, `autovacuum_vacuum_cost_delay`) yang mengontrol durasi tidur vakum. Meningkatkan nilai parameter batas biaya akan memungkinkan lebih banyak sumber daya digunakan oleh vakum sebelum dibuat tidur. Tindakan ini akan menghasilkan lebih sedikit peristiwa tunggu `Timeout:VacuumDelay`. Meningkatkan salah satu parameter penundaan akan menyebabkan peristiwa tunggu `Timeout:VacuumDelay` terjadi lebih sering dan berlangsung lebih lama.
Pengaturan parameter `autovacuum_max_workers` juga dapat meningkatkan jumlah `Timeout:VacuumDelay`. Setiap proses pekerja autovacuum tambahan berkontribusi pada mekanisme penghitung internal, dan dengan demikian batasnya dapat tercapai lebih cepat daripada dengan proses pekerja autovacuum tunggal. Karena batas biaya tercapai lebih cepat, penundaan biaya diberlakukan lebih sering, sehingga menghasilkan lebih banyak peristiwa tunggu `Timeout:VacuumDelay`. Untuk informasi selengkapnya, lihat [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS) dalam dokumentasi PostgreSQL.
Objek besar, seperti 500 GB atau lebih, juga meningkatkan peristiwa tunggu ini karena vakum dapat menghabiskan waktu lama untuk menyelesaikan pemrosesan objek besar.
## Tindakan
Jika operasi vakum selesai seperti yang diharapkan, tidak diperlukan remediasi. Dengan kata lain, peristiwa tunggu ini belum tentu menunjukkan masalah. Ini menunjukkan bahwa vakum sedang dibuat tidur selama periode waktu yang ditentukan dalam parameter penundaan sehingga sumber daya dapat diterapkan pada proses lain yang perlu diselesaikan.
Jika Anda ingin operasi vakum selesai lebih cepat, Anda dapat menurunkan parameter penundaan. Tindakan ini akan mempersingkat waktu tidur vakum.
# DevOps
DevOpsWawasan proaktif Guru mendeteksi kondisi pada RDS Anda untuk instans PostgreSQL DB PostgreSQL Aurora PostgreSQL DB terjadi. Wawasan proaktif dapat mengingatkan Anda tentang idle yang berjalan lama dalam koneksi transaksi. Untuk informasi selengkapnya tentang pemecahan masalah idle yang berjalan lama dalam koneksi transaksi, lihat [Basis data telah lama berjalan idle dalam koneksi transaksi](#proactive-insights.idle-txn)
DevOpsGuru dapat melakukan hal berikut:
+ Mencegah banyak masalah umum pada basis data dengan memeriksa silang konfigurasi basis data terhadap pengaturan umum yang direkomendasikan.
+ Memberi tahu Anda tentang masalah kritis dalam armada yang, jika dibiarkan tanpa diperiksa, dapat menyebabkan masalah yang lebih besar di kemudian hari.
+ Memberi tahu Anda tentang masalah yang baru ditemukan.
Setiap wawasan proaktif berisi analisis penyebab masalah dan rekomendasi untuk tindakan korektif.
Untuk informasi selengkapnya tentang Amazon DevOps Guru untuk Amazon RDS, lihat[Menganalisis anomali kinerja dengan Amazon DevOps Guru untuk Amazon RDS](devops-guru-for-rds.md).
## Basis data telah lama berjalan idle dalam koneksi transaksi
Koneksi ke basis berada dalam status `idle in transaction` selama lebih dari 1.800 detik.
**Topics**
+ [Versi mesin yang didukung](#proactive-insights.idle-txn.context.supported)
+ [Konteks](#proactive-insights.idle-txn.context)
+ [Kemungkinan penyebab masalah ini](#proactive-insights.idle-txn.causes)
+ [Tindakan](#proactive-insights.idle-txn.actions)
+ [Metrik terkait](#proactive-insights.idle-txn.metrics)
### Versi mesin yang didukung
Informasi wawasan ini didukung untuk semua versi RDS for PostgreSQL.
### Konteks
Transaksi dalam status `idle in transaction` dapat menahan kunci yang memblokir kueri lain. Ini juga dapat mencegah `VACUUM` (termasuk autovacuum) membersihkan baris mati, yang menyebabkan penggelembungan indeks atau tabel atau ID transaksi tumpang tindih.
### Kemungkinan penyebab masalah ini
Transaksi yang dimulai dalam sesi interaktif dengan BEGIN atau START TRANSACTION belum berakhir dengan menggunakan perintah COMMIT, ROLLBACK, atau END. Hal ini menyebabkan status transaksi berubah ke `idle in transaction`.
### Tindakan
Anda dapat menemukan transaksi idle dengan mengueri `pg_stat_activity`.
Di klien SQL Anda, jalankan kueri berikut untuk mencantumkan semua koneksi dalam status `idle in transaction` dan mengurutkannya berdasarkan durasi:
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Kami merekomendasikan tindakan yang berbeda bergantung pada penyebab wawasan Anda.
**Topics**
+ [Transaksi akhir](#proactive-insights.idle-txn.actions.end-txn)
+ [Mengakhiri koneksi](#proactive-insights.idle-txn.actions.end-connection)
+ [Konfigurasikan parameter idle\$1in\$1transaction\$1session\$1timeout](#proactive-insights.idle-txn.actions.parameter)
+ [Memeriksa status AUTOCOMMIT](#proactive-insights.idle-txn.actions.autocommit)
+ [Memeriksa logika transaksi dalam kode aplikasi Anda](#proactive-insights.idle-txn.actions.app-logic)
#### Transaksi akhir
Ketika Anda memulai transaksi dalam sesi interaktif dengan BEGIN atau START TRANSACTION, status akan berubah ke `idle in transaction`. Status ini tidak akan berubah hingga Anda mengakhiri transaksi dengan mengeluarkan perintah COMMIT, ROLLBACK, END atau memutuskan koneksi sepenuhnya untuk meluncurkan kembali transaksi.
#### Mengakhiri koneksi
Akhiri koneksi dengan transaksi idle menggunakan kueri berikut:
```
SELECT pg_terminate_backend(pid);
```
pid adalah ID proses koneksi.
#### Konfigurasikan parameter idle\$1in\$1transaction\$1session\$1timeout
Konfigurasikan parameter `idle_in_transaction_session_timeout` di grup parameter baru. Dengan mengonfigurasi parameter ini, intervensi manual tidak diperlukan untuk mengakhiri status idle yang lama dalam transaksi. Untuk informasi lebih lanjut tentang parameter ini, lihat [dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-client.html).
Pesan berikut akan dilaporkan dalam file log PostgreSQL setelah koneksi dihentikan jika transaksi berada dalam status idle\$1in\$1transaction yang lebih lama dari waktu yang ditentukan.
```
FATAL: terminating connection due to idle in transaction timeout
```
#### Memeriksa status AUTOCOMMIT
AUTOCOMMIT diaktifkan secara default. Namun, jika dinonaktifkan secara tidak sengaja di klien, pastikan Anda mengaktifkannya kembali.
+ Di klien psql Anda, jalankan perintah berikut:
```
postgres=> \set AUTOCOMMIT on
```
+ Di pgadmin, aktifkan dengan memilih opsi AUTOCOMMIT dari tanda panah bawah.
![\[Di pgadmin, pilih AUTOCOMMIT untuk mengaktifkannya.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/apg-insight-pgadmin-autocommit.png)
#### Memeriksa logika transaksi dalam kode aplikasi Anda
Selidiki logika aplikasi Anda untuk kemungkinan masalah. Pertimbangkan tindakan berikut:
+ Periksa apakah JDBC auto commit diatur ke true dalam aplikasi Anda. Pertimbangkan juga untuk menggunakan perintah `COMMIT` eksplisit dalam kode Anda.
+ Periksa logika penanganan kesalahan untuk mengetahui apakah transaksi ditutup setelah kesalahan terjadi.
+ Periksa apakah aplikasi Anda membutuhkan waktu lama untuk memproses baris yang ditampilkan oleh kueri saat transaksi terbuka. Jika demikian, pertimbangkan untuk mengodekan aplikasi guna menutup transaksi sebelum memproses baris.
+ Periksa apakah transaksi berisi banyak operasi yang berjalan lama. Jika demikian, bagi satu transaksi menjadi beberapa transaksi.
### Metrik terkait
Metrik PI berikut terkait dengan wawasan ini:
+ idle\$1in\$1transaction\$1count - Jumlah sesi dalam status `idle in transaction`.
+ idle\$1in\$1transaction\$1max\$1time - Durasi transaksi yang berjalan paling lama dalam status `idle in transaction`.
# Menggunakan ekstensi PostgreSQL dengan Amazon RDS for PostgreSQL
Anda dapat memperluas fungsionalitas PostgreSQL dengan menginstal berbagai ekstensi dan modul. Misalnya, untuk bekerja dengan data spasial Anda dapat menginstal dan menggunakan ekstensi PostGIS. Untuk informasi selengkapnya, lihat [Mengelola data spasial dengan ekstensi PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md). Sebagai contoh lain, jika Anda ingin meningkatkan entri data untuk tabel yang sangat besar, Anda dapat mempertimbangkan untuk mempartisi data Anda dengan menggunakan ekstensi `pg_partman`. Untuk mempelajari selengkapnya, lihat [Mengelola partisi PostgreSQL dengan ekstensi pg\$1partman](PostgreSQL_Partitions.md).
**catatan**
RDS untuk PostgreSQL mendukung Ekstensi Bahasa Tepercaya untuk PostgreSQL melalui ekstensi, yang dapat Anda tambahkan ke instans DB Anda. `pg_tle` Dengan menggunakan ekstensi ini, developer dapat membuat ekstensi PostgreSQL mereka sendiri di lingkungan yang aman yang menyederhanakan persyaratan penyiapan dan konfigurasi. Untuk mempelajari tentang RDS untuk versi PostgreSQL yang `pg_tle` mendukung ekstensi dan untuk informasi selengkapnya, lihat. [Bekerja dengan Ekstensi Bahasa Tepercaya untuk PostgreSQL](PostgreSQL_trusted_language_extension.md)
Dalam beberapa kasus, daripada menginstal ekstensi, Anda dapat menambahkan modul tertentu ke daftar `shared_preload_libraries` dalam grup parameter DB kustom instans DB RDS For PostgreSQL. Biasanya, grup parameter klaster DB default hanya memuat `pg_stat_statements`, tetapi beberapa modul lain tersedia untuk ditambahkan ke daftar. Misalnya, Anda dapat menambahkan kemampuan penjadwalan dengan menambahkan modul `pg_cron`, seperti yang dijelaskan dalam [Menjadwalkan pemeliharaan dengan ekstensi pg\$1cron PostgreSQL](PostgreSQL_pg_cron.md). Sebagai contoh lain, Anda dapat membuat log rencana eksekusi kueri dengan memuat modul `auto_explain`. Untuk mempelajari lebih lanjut, [lihat Mencatat rencana eksekusi kueri](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) di pusat AWS pengetahuan.
Bergantung pada versi RDS for PostgreSQL Anda, menginstal ekstensi mungkin memerlukan izin `rds_superuser`, sebagai berikut:
+ Untuk RDS for PostgreSQL versi 12 dan versi sebelumnya, menginstal ekstensi yang memerlukan hak istimewa `rds_superuser`.
+ Untuk RDS for PostgreSQL versi 13 dan versi yang lebih tinggi, pengguna (peran) dengan izin membuat pada instans basis data tertentu yang dapat menginstal dan menggunakan *ekstensi tepercaya apa pun*. Untuk daftar ekstensi tepercaya, lihat [Ekstensi terpercaya PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted).
Anda juga dapat menentukan dengan tepat ekstensi mana yang dapat diinstal pada instans DB RDS for PostgreSQL, dengan mencantumkannya dalam parameter `rds.allowed_extensions`. Untuk informasi selengkapnya, lihat [Membatasi penginstalan ekstensi PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Untuk mempelajari lebih lanjut tentang peran `rds_superuser` tersebut, lihat [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
**Topics**
+ [Menggunakan fungsi dari ekstensi orafce](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [Menggunakan dukungan ekstensi yang didelegasikan Amazon RDS untuk PostgreSQL](RDS_delegated_ext.md)
+ [Mengelola partisi PostgreSQL dengan ekstensi pg\$1partman](PostgreSQL_Partitions.md)
+ [Menggunakan pgAudit untuk mencatat aktivitas database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [Menjadwalkan pemeliharaan dengan ekstensi pg\$1cron PostgreSQL](PostgreSQL_pg_cron.md)
+ [Menggunakan pglogical untuk menyinkronkan data di seluruh instans](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [Menggunakan pgactive untuk mendukung replikasi aktif-aktif](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [Mengurangi bloat dalam tabel dan indeks dengan ekstensi pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [Memutakhirkan dan menggunakan ekstensi PLV8](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [Menggunakan PL/Rust untuk menulis fungsi PostgreSQL dalam bahasa Rust](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [Mengelola data spasial dengan ekstensi PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# Menggunakan fungsi dari ekstensi orafce
Ekstensi Orafce menyediakan fungsi dan operator yang meniru subset fungsi dan paket dari basis data Oracle. Ekstensi orafce memudahkan Anda untuk mem-port aplikasi Oracle ke PostgreSQL. RDS for PostgreSQL versi 9.6.6 dan yang lebih tinggi mendukung ekstensi ini. Untuk informasi lebih lanjut tentang orafce, lihat [orafce](https://github.com/orafce/orafce) di. GitHub
**catatan**
RDS for PostgreSQL tidak mendukung paket `utl_file` yang merupakan bagian dari ekstensi orafce. Karena fungsi skema `utl_file` menyediakan operasi baca dan tulis pada file teks sistem operasi, yang membutuhkan akses superuser ke host yang mendasarinya. Sebagai layanan terkelola, RDS for PostgreSQL tidak menyediakan akses host.
**Menggunakan ekstensi orafce**
1. Hubungkan ke instans DB dengan nama pengguna utama yang Anda gunakan untuk membuat instans DB.
Jika Anda ingin mengaktifkan orafce untuk basis data yang berbeda dalam instans DB yang sama, gunakan perintah psql `/c dbname`. Dengan menggunakan perintah ini, Anda dapat mengubah dari basis data utama setelah memulai koneksi.
1. Nyalakan ekstensi orafce dengan pernyataan `CREATE EXTENSION`.
```
CREATE EXTENSION orafce;
```
1. Transfer kepemilikan skema oracle ke peran rds\$1superuser dengan pernyataan `ALTER SCHEMA`.
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
Jika Anda ingin melihat daftar pemilik untuk skema oracle, gunakan perintah psql `\dn`.
# Menggunakan dukungan ekstensi yang didelegasikan Amazon RDS untuk PostgreSQL
Menggunakan dukungan ekstensi yang didelegasikan Amazon RDS untuk PostgreSQL, Anda dapat mendelegasikan manajemen ekstensi ke pengguna yang tidak perlu menjadi file. `rds_superuser` Dengan dukungan ekstensi yang didelegasikan ini, peran baru yang `rds_extension` disebut dibuat dan Anda harus menetapkan ini kepada pengguna untuk mengelola ekstensi lainnya. Peran ini dapat membuat, memperbarui, dan menjatuhkan ekstensi.
Anda dapat menentukan ekstensi yang dapat diinstal pada instans RDS DB Anda, dengan mencantumkannya di `rds.allowed_extensions` parameter. Untuk informasi selengkapnya, lihat [Menggunakan ekstensi PostgreSQL dengan Amazon RDS for PostgreSQL.](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html)
Anda dapat membatasi daftar ekstensi yang tersedia yang dapat dikelola oleh pengguna dengan `rds_extension` peran menggunakan `rds.allowed_delegated_extensions` parameter.
Dukungan ekstensi yang didelegasikan tersedia dalam versi berikut:
+ Semua versi yang lebih tinggi
+ 16.4 dan versi 16 yang lebih tinggi
+ 15.8 dan versi 15 yang lebih tinggi
+ 14.13 dan versi 14 yang lebih tinggi
+ 13.16 dan 13 versi yang lebih tinggi
+ 12.20 dan versi 12 yang lebih tinggi
**Topics**
+ [Mengaktifkan dukungan ekstensi delegasi ke pengguna](#RDSPostgreSQL.delegated_ext_mgmt)
+ [Konfigurasi yang digunakan dalam dukungan ekstensi yang didelegasikan RDS untuk PostgreSQL](#RDSPostgreSQL.delegated_ext_config)
+ [Mematikan dukungan untuk ekstensi yang didelegasikan](#RDSPostgreSQL.delegated_ext_disable)
+ [Manfaat menggunakan dukungan ekstensi yang didelegasikan Amazon RDS](#RDSPostgreSQL.delegated_ext_benefits)
+ [Batasan dukungan ekstensi yang didelegasikan Amazon RDS untuk PostgreSQL](#RDSPostgreSQL.delegated_ext_limit)
+ [Izin diperlukan untuk ekstensi tertentu](#RDSPostgreSQL.delegated_ext_perm)
+ [Pertimbangan Keamanan](#RDSPostgreSQL.delegated_ext_sec)
+ [Jatuhkan kaskade ekstensi dinonaktifkan](#RDSPostgreSQL.delegated_ext_drop)
+ [Contoh ekstensi yang dapat ditambahkan menggunakan dukungan ekstensi yang didelegasikan](#RDSPostgreSQL.delegated_ext_support)
## Mengaktifkan dukungan ekstensi delegasi ke pengguna
Anda harus melakukan hal berikut untuk mengaktifkan dukungan ekstensi delegasi kepada pengguna:
1. **Berikan `rds_extension` peran kepada pengguna** - Connect ke database sebagai `rds_superuser` dan jalankan perintah berikut:
```
Postgres => grant rds_extension to user_name;
```
1. **Mengatur daftar ekstensi yang tersedia bagi pengguna yang didelegasikan untuk dikelola** — `rds.allowed_delegated_extensions` Memungkinkan Anda menentukan subset ekstensi yang tersedia menggunakan parameter `rds.allowed_extensions` cluster DB. Anda dapat melakukan ini di salah satu level berikut:
+ Di cluster atau grup parameter instance, melalui Konsol Manajemen AWS atau API. Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
+ Gunakan perintah berikut di tingkat database:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Gunakan perintah berikut di tingkat pengguna:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**catatan**
Anda tidak perlu me-restart database setelah mengubah parameter `rds.allowed_delegated_extensions` dinamis.
1. **Izinkan akses ke pengguna yang didelegasikan ke objek yang dibuat selama proses pembuatan ekstensi** - Ekstensi tertentu membuat objek yang memerlukan izin tambahan untuk diberikan sebelum pengguna dengan `rds_extension` peran dapat mengaksesnya. `rds_superuser`Harus memberikan akses pengguna yang didelegasikan ke objek tersebut. Salah satu opsi adalah menggunakan pemicu peristiwa untuk secara otomatis memberikan izin kepada pengguna yang didelegasikan.
**Contoh pemicu peristiwa**
Jika Anda ingin mengizinkan pengguna yang didelegasikan `rds_extension` untuk menggunakan ekstensi yang memerlukan izin pengaturan pada objek mereka yang dibuat oleh pembuatan ekstensi, Anda dapat menyesuaikan contoh pemicu peristiwa di bawah ini dan hanya menambahkan ekstensi yang Anda inginkan agar pengguna yang didelegasikan memiliki akses ke fungsionalitas penuh. Pemicu peristiwa ini dapat dibuat pada template1 (template default), oleh karena itu semua database yang dibuat dari template1 akan memiliki pemicu peristiwa itu. Ketika pengguna yang didelegasikan menginstal ekstensi, pemicu ini akan secara otomatis memberikan kepemilikan pada objek yang dibuat oleh ekstensi.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Konfigurasi yang digunakan dalam dukungan ekstensi yang didelegasikan RDS untuk PostgreSQL
| Nama Konfigurasi | Deskripsi | nilai default | Catatan | Siapa yang dapat memodifikasi atau memberikan izin |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Parameter ini membatasi ekstensi yang dapat dikelola peran rds\$1extension dalam database. Itu harus merupakan bagian dari rds.allowed\$1extensions. | string kosong | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) Untuk mempelajari lebih lanjut tentang pengaturan parameter ini, lihat[Mengaktifkan dukungan ekstensi delegasi ke pengguna](#RDSPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Parameter ini memungkinkan pelanggan membatasi ekstensi yang dapat diinstal dalam instans RDS DB. Untuk informasi selengkapnya, lihat [Membatasi pemasangan ekstensi PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction) | "\$1" | Secara default, parameter ini diatur ke “\$1”, yang berarti bahwa semua ekstensi yang didukung pada RDS untuk PostgreSQL dan Aurora PostgreSQL diizinkan untuk dibuat oleh pengguna dengan hak istimewa yang diperlukan. Kosong berarti tidak ada ekstensi yang dapat diinstal di instans RDS DB. | administrator |
| `rds-delegated_extension_allow_drop_cascade` | Parameter ini mengontrol kemampuan pengguna `rds_extension` untuk menjatuhkan ekstensi menggunakan opsi kaskade. | off | Secara default, `rds-delegated_extension_allow_drop_cascade` diatur ke `off`. Ini berarti bahwa pengguna dengan tidak `rds_extension` diizinkan untuk menjatuhkan ekstensi menggunakan opsi kaskade. Untuk memberikan kemampuan itu, `rds.delegated_extension_allow_drop_cascade` parameter harus diatur ke`on`. | rds\$1superuser |
## Mematikan dukungan untuk ekstensi yang didelegasikan
**Mematikan sebagian**
Pengguna yang didelegasikan tidak dapat membuat ekstensi baru tetapi masih dapat memperbarui ekstensi yang ada.
+ Atur ulang `rds.allowed_delegated_extensions` ke nilai default di grup parameter cluster DB.
+ Gunakan perintah berikut di tingkat database:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Gunakan perintah berikut di tingkat pengguna:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Mematikan sepenuhnya**
Mencabut `rds_extension` peran dari pengguna akan mengembalikan pengguna ke izin standar. Pengguna tidak dapat lagi membuat, memperbarui, atau menjatuhkan ekstensi.
```
postgres => revoke rds_extension from user_name;
```
## Manfaat menggunakan dukungan ekstensi yang didelegasikan Amazon RDS
Dengan menggunakan dukungan ekstensi yang didelegasikan Amazon RDS untuk PostgreSQL, Anda mendelegasikan manajemen ekstensi dengan aman kepada pengguna yang tidak memiliki peran tersebut. `rds_superuser` Fitur ini memberikan manfaat sebagai berikut:
+ Anda dapat dengan mudah mendelegasikan manajemen ekstensi kepada pengguna pilihan Anda.
+ Ini tidak membutuhkan `rds_superuser` peran.
+ Menyediakan kemampuan untuk mendukung kumpulan ekstensi yang berbeda untuk database yang berbeda di cluster DB yang sama.
## Batasan dukungan ekstensi yang didelegasikan Amazon RDS untuk PostgreSQL
+ Objek yang dibuat selama proses pembuatan ekstensi mungkin memerlukan hak istimewa tambahan agar ekstensi berfungsi dengan baik.
+ Beberapa ekstensi tidak dapat dikelola oleh pengguna ekstensi yang didelegasikan secara default, termasuk yang berikut:`log_fdw`,,`pg_cron`,`pg_tle`,`pgactive`,`pglogical`, `postgis_raster``postgis_tiger_geocoder`,`postgis_topology`.
## Izin diperlukan untuk ekstensi tertentu
Untuk membuat, menggunakan, atau memperbarui ekstensi berikut, pengguna yang didelegasikan harus memiliki hak istimewa yang diperlukan pada fungsi, tabel, dan skema berikut.
| Ekstensi yang membutuhkan kepemilikan atau izin | Fungsi | Tabel | Skema | Kamus Pencarian Teks | Komentar |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | none | us\$1gaz, us\$1lex, us\$1lex, i.us\$1rules | none | none | none |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | none | none | none | none |
| dict\$1int | none | none | none | intdict | none |
| pg\$1partman | none | custom\$1time\$1partisi, part\$1config, part\$1config\$1sub | none | none | none |
| pg\$1stat\$1statements | none | none | none | none | none |
| PostGIS | st\$1tileamplop | spatial\$1ref\$1sys | none | none | none |
| postgis\$1raster | none | none | none | none | none |
| postgis\$1topology | none | topologi, lapisan | topologi | none | pengguna yang didelegasikan Harus menjadi pemilik database |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | none | none | none | none |
| rds\$1tools | role\$1password\$1encryption\$1type | none | none | none | none |
| postgis\$1tiger\$1geocoder | none | geocode\$1settings\$1default, geocode\$1settings | harimau | none | none |
| pg\$1freespacemap | pg\$1freespace | none | none | none | none |
| pg\$1visibility | pg\$1visibility | none | none | none | none |
## Pertimbangan Keamanan
Perlu diingat bahwa pengguna dengan `rds_extension` peran akan dapat mengelola ekstensi di semua database tempat mereka memiliki hak istimewa terhubung. Jika tujuannya adalah agar pengguna yang didelegasikan mengelola ekstensi pada satu database, praktik yang baik adalah mencabut semua hak istimewa dari publik di setiap database, kemudian secara eksplisit memberikan hak istimewa koneksi untuk database spesifik tersebut kepada pengguna delegasi.
Ada beberapa ekstensi yang dapat memungkinkan pengguna untuk mengakses informasi dari beberapa database. Pastikan pengguna yang Anda berikan `rds_extension` memiliki kemampuan lintas basis data sebelum menambahkan ekstensi ini`rds.allowed_delegated_extensions`. Misalnya, `postgres_fdw` dan `dblink` menyediakan fungsionalitas untuk kueri di seluruh database pada instance yang sama atau instance jarak jauh. `log_fdw`membaca file log mesin postgres, yang untuk semua database dalam instance, berpotensi berisi kueri lambat atau pesan kesalahan dari beberapa database. `pg_cron`memungkinkan menjalankan pekerjaan latar belakang terjadwal pada instans DB dan dapat mengonfigurasi pekerjaan untuk dijalankan di database yang berbeda.
## Jatuhkan kaskade ekstensi dinonaktifkan
Kemampuan untuk menjatuhkan ekstensi dengan opsi kaskade oleh pengguna dengan `rds_extension` peran dikendalikan oleh `rds.delegated_extension_allow_drop_cascade` parameter. Secara default, `rds-delegated_extension_allow_drop_cascade` diatur ke `off`. Ini berarti bahwa pengguna dengan `rds_extension` peran tidak diizinkan untuk menjatuhkan ekstensi menggunakan opsi kaskade seperti yang ditunjukkan pada kueri di bawah ini.
```
DROP EXTENSION CASCADE;
```
Karena ini akan secara otomatis menjatuhkan objek yang bergantung pada ekstensi, dan pada gilirannya semua objek yang bergantung pada objek tersebut. Mencoba menggunakan opsi kaskade akan menghasilkan kesalahan.
Untuk memberikan kemampuan itu, `rds.delegated_extension_allow_drop_cascade` parameter harus diatur ke`on`.
Mengubah parameter `rds.delegated_extension_allow_drop_cascade` dinamis tidak memerlukan restart database. Anda dapat melakukan ini di salah satu level berikut:
+ Di cluster atau grup parameter instance, melalui Konsol Manajemen AWS atau API.
+ Menggunakan perintah berikut di tingkat database:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Menggunakan perintah berikut di tingkat pengguna:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Contoh ekstensi yang dapat ditambahkan menggunakan dukungan ekstensi yang didelegasikan
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Mengelola partisi PostgreSQL dengan ekstensi pg\$1partman
Partisi tabel PostgreSQL menyediakan kerangka kerja untuk penanganan input data dan laporan performa tinggi. Gunakan partisi untuk basis data yang memerlukan input data dalam jumlah besar dengan cepat. Partisi juga menyediakan kueri tabel besar yang lebih cepat. Partisi membantu memelihara data tanpa memengaruhi instans basis data karena sumber daya I/O yang diperlukan lebih sedikit.
Dengan partisi, Anda dapat membagi data menjadi beberapa bagian berukuran kustom untuk diproses. Misalnya, Anda dapat membagi data deret waktu ke dalam berbagai rentang seperti per jam, harian, mingguan, bulanan, triwulanan, tahunan, kustom, atau kombinasinya. Untuk contoh data deret waktu, jika Anda membagi tabel berdasarkan jam, setiap partisi akan berisi data per satu jam. Jika Anda membagi tabel deret waktu berdasarkan hari, partisi akan berisi data per hari, dan seterusnya. Kunci partisi mengontrol ukuran partisi.
Saat Anda menggunakan perintah SQL `INSERT` atau `UPDATE` pada tabel yang dipartisi, mesin basis data merutekan data ke partisi yang sesuai. Partisi tabel PostgreSQL yang menyimpan data adalah tabel turunan dari tabel utama.
Selama pembacaan kueri basis data, pengoptimal PostgreSQL memeriksa klausul `WHERE` pada kueri dan, jika memungkinkan, mengarahkan pemindaian basis data hanya untuk partisi yang relevan.
Mulai versi 10, PostgreSQL menggunakan partisi deklaratif untuk mengimplementasikan partisi tabel. Ini juga dikenal sebagai partisi PostgreSQL asli. Sebelum PostgreSQL versi 10, Anda menggunakan pemicu untuk mengimplementasikan partisi.
Partisi tabel PostgreSQL menyediakan fitur berikut:
+ Pembuatan partisi baru setiap saat.
+ Rentang partisi bervariasi.
+ Partisi yang dapat dilepas dan dapat dipasang kembali menggunakan pernyataan bahasa definisi data (DDL).
Sebagai contoh, partisi yang dapat dilepas berguna untuk menghapus data historis dari partisi utama, tetapi menyimpan data historis untuk analisis.
+ Partisi baru mewarisi properti tabel basis data induk, termasuk yang berikut ini:
+ Indeks
+ Kunci primer, yang harus berisi kolom kunci partisi
+ Kunci asing
+ Batasan pemeriksaan
+ Referensi
+ Membuat indeks untuk seluruh tabel atau partisi tertentu.
Anda tidak dapat mengubah skema partisi individual. Namun, Anda dapat mengubah tabel induk (seperti menambahkan kolom baru), yang disebarkan ke partisi.
**Topics**
+ [Ikhtisar ekstensi pg\$1partman PostgreSQL](#PostgreSQL_Partitions.pg_partman)
+ [Mengaktifkan ekstensi pg\$1partman](#PostgreSQL_Partitions.enable)
+ [Mengonfigurasi partisi menggunakan fungsi create\$1parent](#PostgreSQL_Partitions.create_parent)
+ [Mengonfigurasi pemeliharaan partisi menggunakan fungsi run\$1maintenance\$1proc](#PostgreSQL_Partitions.run_maintenance_proc)
## Ikhtisar ekstensi pg\$1partman PostgreSQL
Anda dapat menggunakan ekstensi `pg_partman` PostgreSQL untuk mengotomatiskan pembuatan dan pemeliharaan partisi tabel. Untuk informasi umum selengkapnya, lihat [PG Partition Manager](https://github.com/pgpartman/pg_partman) dalam dokumentasi `pg_partman`.
**catatan**
Ekstensi `pg_partman` didukung pada RDS for PostgreSQL versi 12.5 dan yang lebih tinggi.
Alih-alih membuat setiap partisi secara manual, Anda dapat mengonfigurasi `pg_partman` dengan pengaturan berikut:
+ Tabel yang akan dipartisi
+ Jenis partisi
+ Kunci partisi
+ Granularitas partisi
+ Opsi pra-pembuatan dan manajemen partisi
Setelah membuat tabel yang dipartisi PostgreSQL, daftarkan dengan `pg_partman` dengan memanggil fungsi `create_parent`. Tindakan ini akan membuat partisi yang diperlukan berdasarkan parameter yang Anda teruskan ke fungsi.
Ekstensi `pg_partman` juga menyediakan fungsi `run_maintenance_proc`, yang dapat Anda panggil sesuai jadwal untuk secara otomatis mengelola partisi. Untuk memastikan bahwa partisi yang tepat dibuat sesuai kebutuhan, jadwalkan fungsi ini untuk berjalan secara berkala (seperti per jam). Anda juga dapat memastikan bahwa partisi secara otomatis dibatalkan.
## Mengaktifkan ekstensi pg\$1partman
Jika Anda memiliki beberapa basis data di dalam instans DB PostgreSQL yang partisinya ingin Anda kelola, aktifkan ekstensi `pg_partman` secara terpisah untuk setiap basis data. Untuk mengaktifkan ekstensi `pg_partman` untuk basis data tertentu, buat skema pemeliharaan partisi, kemudian buat ekstensi `pg_partman` seperti berikut.
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**catatan**
Untuk membuat ekstensi `pg_partman`, pastikan Anda memiliki hak istimewa `rds_superuser`.
Jika Anda menerima kesalahan seperti berikut, berikan hak istimewa `rds_superuser` untuk akun tersebut atau gunakan akun pengguna super Anda.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Untuk memberikan hak istimewa `rds_superuser`, hubungkan dengan akun pengguna super Anda dan jalankan perintah berikut.
```
GRANT rds_superuser TO user-or-role;
```
Untuk contoh yang menunjukkan penggunaan ekstensi pg\$1partman, kita gunakan contoh tabel dan partisi basis data berikut. Basis data ini menggunakan tabel yang dipartisi berdasarkan stempel waktu. Skema `data_mart` berisi tabel bernama `events` dengan kolom bernama `created_at`. Pengaturan berikut disertakan dalam tabel `events`:
+ Kunci primer `event_id` dan `created_at`, yang harus memiliki kolom yang digunakan untuk memandu partisi.
+ Batasan pemeriksaan `ck_valid_operation` guna menerapkan nilai untuk kolom tabel `operation`.
+ Dua kunci asing, yang salah satunya (`fk_orga_membership)` menunjuk ke tabel eksternal `organization` dan kunci lainnya (`fk_parent_event_id`) adalah kunci asing referensi mandiri.
+ Dua indeks, yang salah satunya (`idx_org_id`) untuk kunci asing dan indeks lainnya (`idx_event_type`) untuk jenis peristiwa.
Pernyataan DDL berikut membuat objek ini, yang secara otomatis disertakan pada setiap partisi.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Mengonfigurasi partisi menggunakan fungsi create\$1parent
Setelah mengaktifkan ekstensi `pg_partman`, gunakan fungsi `create_parent` untuk mengonfigurasi partisi di dalam skema pemeliharaan partisi. Contoh berikut menggunakan contoh tabel `events` yang dibuat di [Mengaktifkan ekstensi pg\$1partmanMengonfigurasi pemeliharaan partisi menggunakan fungsi run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable). Panggil fungsi `create_parent` seperti berikut.
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Parameternya adalah sebagai berikut:
+ `p_parent_table` – Tabel induk yang dipartisi. Tabel ini harus sudah ada dan sepenuhnya memenuhi syarat, termasuk skemanya.
+ `p_control` – Kolom yang menjadi dasar pembuatan partisi. Jenis data harus bilangan bulat atau berbasis waktu.
+ `p_type` – Jenisnya adalah `'range'` atau `'list'`.
+ `p_interval` – Interval waktu atau rentang bilangan bulat untuk setiap partisi. Contoh nilai meliputi `1 day``1 hour`,, dan sebagainya.
+ `p_premake` – Jumlah partisi yang akan dibuat terlebih dahulu untuk mendukung sisipan baru.
Untuk keterangan lengkap tentang fungsi `create_parent`, lihat [Creation Functions](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions) dalam dokumentasi `pg_partman`.
## Mengonfigurasi pemeliharaan partisi menggunakan fungsi run\$1maintenance\$1proc
Anda dapat menjalankan operasi pemeliharaan partisi untuk secara otomatis membuat partisi baru, melepaskan partisi, atau menghapus partisi lama. Pemeliharaan partisi bergantung pada fungsi `run_maintenance_proc` pada ekstensi `pg_partman` dan `pg_cron`, yang memulai penjadwal internal. Penjadwal `pg_cron` secara otomatis mengeksekusi pernyataan, fungsi, dan prosedur SQL yang ditetapkan dalam basis data Anda.
Contoh berikut menggunakan contoh tabel `events` yang dibuat di [Mengaktifkan ekstensi pg\$1partmanMengonfigurasi pemeliharaan partisi menggunakan fungsi run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable) untuk mengatur operasi pemeliharaan partisi agar berjalan secara otomatis. Sebagai prasyarat, tambahkan `pg_cron` ke parameter `shared_preload_libraries` dalam grup parameter instans DB.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
Berikut ini, Anda dapat menemukan step-by-step penjelasan dari contoh sebelumnya:
1. Modifikasi grup parameter yang terkait dengan instans DB Anda dan tambahkan `pg_cron` ke nilai parameter `shared_preload_libraries`. Untuk menerapkan perubahan, instans DB harus dimulai ulang. Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Modifying.md).
1. Jalankan perintah `CREATE EXTENSION pg_cron;` menggunakan akun yang memiliki izin `rds_superuser`. Tindakan ini akan mengaktifkan ekstensi `pg_cron`. Untuk informasi selengkapnya, lihat [Menjadwalkan pemeliharaan dengan ekstensi pg\$1cron PostgreSQL](PostgreSQL_pg_cron.md).
1. Jalankan perintah `UPDATE partman.part_config` guna menyesuaikan pengaturan `pg_partman` untuk tabel `data_mart.events`.
1. Jalankan perintah `SET` . . . untuk mengonfigurasi tabel `data_mart.events` dengan klausul berikut:
1. `infinite_time_partitions = true,` – Mengonfigurasi tabel untuk dapat secara otomatis membuat partisi baru tanpa batas.
1. `retention = '3 months',` – Mengonfigurasi tabel agar memiliki retensi maksimum tiga bulan.
1. `retention_keep_table=true `– Mengonfigurasi tabel agar ketika periode retensi sudah habis, tabel tidak akan dihapus secara otomatis. Sebaliknya, partisi yang lebih lama dari periode retensi hanya dilepaskan dari tabel induk.
1. Jalankan perintah `SELECT cron.schedule` . . . untuk membuat panggilan fungsi `pg_cron`. Panggilan ini menetapkan frekuensi penjadwal menjalankan prosedur pemeliharaan `pg_partman`, `partman.run_maintenance_proc`. Untuk contoh ini, prosedur berjalan setiap jam.
Untuk keterangan lengkap tentang fungsi `run_maintenance_proc`, lihat [Maintenance Functions](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions) dalam dokumentasi `pg_partman`.
# Menggunakan pgAudit untuk mencatat aktivitas database
Lembaga keuangan, lembaga pemerintah, dan banyak industri perlu menyimpan *log audit* untuk memenuhi persyaratan regulasi. Dengan menggunakan ekstensi Postgre SQL Audit (pgAudit) dengan Anda RDSuntuk instans Postgre SQL DB, Anda dapat menangkap catatan terperinci yang biasanya dibutuhkan oleh auditor atau untuk memenuhi persyaratan peraturan. Misalnya, Anda dapat mengatur pgAudit ekstensi untuk melacak perubahan yang dibuat pada database dan tabel tertentu, untuk merekam pengguna yang membuat perubahan, dan banyak detail lainnya.
pgAudit Ekstensi dibangun di atas fungsionalitas infrastruktur SQL logging Postgre asli dengan memperluas pesan log dengan lebih detail. Dengan kata lain, Anda menggunakan pendekatan yang sama untuk melihat log audit seperti untuk melihat pesan log lain. Untuk informasi lebih lanjut tentang SQL pencatatan Postgre, lihat. [](USER_LogAccess.Concepts.PostgreSQL.md)
pgAudit Ekstensi menyunting data sensitif seperti kata sandi cleartext dari log. Jika Anda RDSuntuk instans Postgre SQL DB dikonfigurasi untuk mencatat pernyataan bahasa manipulasi data (DML) seperti yang dijelaskan dalam[Mengaktifkan pencatatan kueri untuk ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md), Anda dapat menghindari masalah kata sandi cleartext dengan menggunakan ekstensi Postgre Audit. SQL
Anda dapat mengonfigurasi audit pada basis data instans dengan tingkat kekhususan yang tinggi. Anda dapat mengaudit semua basis data dan semua pengguna. Atau, Anda dapat memilih untuk mengaudit hanya basis data, pengguna, dan objek tertentu lainnya. Anda juga dapat secara eksplisit mengecualikan pengguna dan basis data tertentu agar tidak diaudit. Untuk informasi selengkapnya, lihat [Mengecualikan pengguna atau basis data dari pencatatan log audit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Mengingat jumlah detail yang dapat ditangkap, kami menyarankan jika Anda menggunakannyapgAudit, Anda memantau konsumsi penyimpanan Anda.
pgAudit Ekstensi ini didukung pada semua versi RDSuntuk versi PostgreSQL. Untuk daftar versi yang didukung oleh tersedia RDS untuk pgAudit versi Postgre, lihat SQL [Versi ekstensi untuk Amazon untuk Postgre di Catatan Rilis *Amazon RDS RDS untuk SQL* Postgre](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html). SQL
**Topics**
+ [Menyiapkan pgAudit ekstensi](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [Mengaudit objek basis data](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [Mengecualikan pengguna atau basis data dari pencatatan log audit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [Referensi untuk ekstensi pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Menyiapkan pgAudit ekstensi
Untuk menyiapkan pgAudit ekstensi pada , Anda terlebih dahulu menambahkan pgAudit ke pustaka bersama pada grup parameter DB kustom untuk instans Postgre DB Anda. RDS RDS SQL Untuk informasi cara membuat grup parameter DB kustom, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md). Selanjutnya, Anda menginstal pgAudit ekstensi. Terakhir, Anda menentukan basis data dan objek yang ingin diaudit. Prosedur di bagian ini menunjukkan caranya kepada Anda. Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI.
Anda harus memiliki izin sebagai peran `rds_superuser` untuk melakukan semua tugas ini.
## Konsol
**Untuk mengatur pgAudit ekstensi**
1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih instance . SQL
1. Buka tab **Konfigurasi** untuk instance penulis cluster Anda. RDSuntuk contoh Postgre SQL DB. Di antara detail Instans, temukan tautan **Grup parameter**.
1. Pilih tautan untuk membuka parameter khusus yang terkait dengan cluster DB Anda. RDSuntuk contoh Postgre SQL DB.
1. Di kolom pencarian **Parameter**, ketik `shared_pre` untuk menemukan parameter `shared_preload_libraries`.
1. Pilih **Edit parameter** untuk mengakses nilai properti.
1. Tambahkan `pgaudit` ke daftar di kolom **Nilai**. Gunakan koma untuk memisahkan item dalam daftar nilai.
![\[Gambar shared_preload_libaries parameter dengan pgAudit ditambahkan.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Reboot untuk instance Postgre SQL DB sehingga perubahan Anda pada parameter berlaku. `shared_preload_libraries`
1. Ketika instance tersedia, verifikasi yang pgAudit telah diinisialisasi. Gunakan `psql` untuk terhubung ke dan kemudian jalankan perintah berikut.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Dengan pgAudit diinisialisasi, Anda sekarang dapat membuat ekstensi. Anda perlu membuat ekstensi setelah menginisialisasi pustaka karena `pgaudit` ekstensi menginstal pemicu peristiwa untuk mengaudit pernyataan bahasa definisi data (). DDL
```
CREATE EXTENSION pgaudit;
```
1. Tutup sesi `psql`.
```
labdb=> \q
```
1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Temukan parameter `pgaudit.log` dalam daftar lalu atur ke nilai yang sesuai untuk kasus penggunaan Anda. Misalnya, menyetel parameter `pgaudit.log` ke `write` seperti yang ditunjukkan pada gambar berikut menangkap sisipan, pembaruan, penghapusan, dan beberapa jenis lainnya yang berubah pada log.
![\[Gambar parameter pgaudit.log dengan pengaturan.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
Anda juga dapat memilih salah satu nilai berikut untuk parameter `pgaudit.log`.
+ none – Ini adalah default. Tidak ada perubahan basis data yang dibuat log.
+ semua – Semua dibuat log (baca, tulis, fungsi, peran, ddl, misc).
+ ddl — Mencatat semua pernyataan bahasa definisi data (DDL) yang tidak termasuk dalam `ROLE` kelas.
+ fungsi – Membuat log panggilan fungsi dan blok `DO`.
+ misc – Membuat log berbagai perintah, seperti `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM`, dan `SET`.
+ baca – Membuat log `SELECT` dan `COPY` saat sumbernya adalah relasi (seperti tabel) atau kueri.
+ peran – Membuat log pernyataan yang terkait dengan peran dan hak akses, seperti `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE`, dan `DROP ROLE`.
+ write – Membuat log `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, dan `COPY` saat tujuannya adalah relasi (tabel).
1. Pilih **Simpan perubahan**.
1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih Postgre SQL DB dari daftar Database.
## AWS CLI
**Untuk pengaturan pgAudit**
Untuk pengaturan pgAudit menggunakan AWS CLI, Anda memanggil [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)operasi untuk memodifikasi parameter log audit di grup parameter kustom Anda, seperti yang ditunjukkan dalam prosedur berikut.
1. Gunakan yang berikut ini AWS CLI perintah untuk `pgaudit` menambah `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan yang berikut ini AWS CLI perintah untuk me-reboot sehingga pustaka SQL pgaudit diinisialisasi.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Saat instans tersedia, verifikasikan bahwa `pgaudit` telah diinisialisasi. Gunakan `psql` untuk terhubung ke dan kemudian jalankan perintah berikut.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Dengan pgAudit diinisialisasi, Anda sekarang dapat membuat ekstensi.
```
CREATE EXTENSION pgaudit;
```
1. Tutup `psql` sesi sehingga Anda dapat menggunakan AWS CLI.
```
labdb=> \q
```
1. Gunakan yang berikut ini AWS CLI perintah untuk menentukan kelas pernyataan yang ingin dicatat oleh sesi audit logging. Contoh ini menetapkan parameter `pgaudit.log` ke `write`, yang menangkap sisipan, pembaruan, dan penghapusan ke log.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
Anda juga dapat memilih salah satu nilai berikut untuk parameter `pgaudit.log`.
+ none – Ini adalah default. Tidak ada perubahan basis data yang dibuat log.
+ semua – Semua dibuat log (baca, tulis, fungsi, peran, ddl, misc).
+ ddl — Mencatat semua pernyataan bahasa definisi data (DDL) yang tidak termasuk dalam `ROLE` kelas.
+ fungsi – Membuat log panggilan fungsi dan blok `DO`.
+ misc – Membuat log berbagai perintah, seperti `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM`, dan `SET`.
+ baca – Membuat log `SELECT` dan `COPY` saat sumbernya adalah relasi (seperti tabel) atau kueri.
+ peran – Membuat log pernyataan yang terkait dengan peran dan hak akses, seperti `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE`, dan `DROP ROLE`.
+ write – Membuat log `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, dan `COPY` saat tujuannya adalah relasi (tabel).
Nyalakan ulang menggunakan yang berikut SQL ini AWS CLI perintah.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Mengaudit objek basis data
Dengan pgAudit pengaturan pada Anda RDSuntuk instans Postgre SQL DB dan dikonfigurasi untuk kebutuhan Anda, informasi yang lebih rinci ditangkap dalam log Postgre. SQL Misalnya, sementara konfigurasi SQL logging Postgre default mengidentifikasi tanggal dan waktu perubahan dibuat dalam tabel database, dengan pgAudit ekstensi entri log dapat mencakup skema, pengguna yang membuat perubahan, dan detail lainnya tergantung pada bagaimana parameter ekstensi dikonfigurasi. Anda dapat menyiapkan audit untuk melacak perubahan dengan cara berikut.
+ Untuk setiap sesi, oleh pengguna. Untuk tingkat sesi, Anda dapat menangkap teks perintah yang sepenuhnya memenuhi syarat.
+ Untuk setiap objek, oleh pengguna dan basis data.
Kemampuan audit objek diaktifkan saat Anda membuat peran `rds_pgaudit` pada sistem, lalu menambahkan peran ini ke parameter `pgaudit.role` dalam grup parameter kustom Anda. Secara default, parameter `pgaudit.role` tidak ditetapkan dan satu-satunya nilai yang diizinkan adalah `rds_pgaudit`. Langkah-langkah berikut mengasumsikan bahwa `pgaudit` telah diinisialisasi dan bahwa Anda telah membuat ekstensi `pgaudit` dengan mengikuti prosedur di [Menyiapkan pgAudit ekstensi](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
![\[Gambar file SQL log Postgre setelah pengaturan. pgAudit\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
Seperti yang ditunjukkan dalam contoh ini, baris "LOGAUDIT::SESSION" memberikan informasi tentang tabel dan skemanya, di antara detail lainnya.
**Menyiapkan audit objek**
1. Gunakan `psql` untuk terhubung ke . RDSuntuk contoh Postgre SQL DB.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Buat peran basis data yang dinamai `rds_pgaudit` menggunakan perintah berikut.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Tutup sesi `psql`.
```
labdb=> \q
```
Dalam beberapa langkah berikutnya, gunakan AWS CLI untuk memodifikasi parameter log audit di grup parameter kustom Anda.
1. Gunakan yang berikut AWS CLI perintah untuk mengatur `pgaudit.role` parameter ke`rds_pgaudit`. Secara default, parameter ini kosong, dan `rds_pgaudit` merupakan satu-satunya nilai yang diizinkan.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan yang berikut AWS CLI perintah untuk me-reboot untuk instance Postgre SQL DB sehingga perubahan Anda pada parameter berlaku.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Jalankan perintah berikut untuk mengonfirmasi bahwa `pgaudit.role` diatur ke `rds_pgaudit`.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Untuk menguji pgAudit logging, Anda dapat menjalankan beberapa contoh perintah yang ingin Anda audit. Misalnya, Anda dapat menjalankan perintah berikut.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Log basis data harus berisi entri yang serupa dengan entri berikut.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Untuk informasi tentang menampilkan log, lihat [Memantau file RDS Amazon](USER_LogAccess.md).
Untuk mempelajari lebih lanjut tentang pgAudit ekstensi, lihat [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md)di GitHub.
# Mengecualikan pengguna atau basis data dari pencatatan log audit
Seperti dibahas dalam[](USER_LogAccess.Concepts.PostgreSQL.md), SQL log Postgre mengkonsumsi ruang penyimpanan. Menggunakan pgAudit ekstensi menambah volume data yang dikumpulkan di log Anda ke berbagai tingkat, tergantung pada perubahan yang Anda lacak. Anda mungkin tidak perlu mengaudit setiap pengguna atau database di cluster DB Anda. RDSuntuk contoh Postgre SQL DB.
Untuk meminimalkan dampak pada penyimpanan dan untuk menghindari pengambilan catatan audit yang tidak perlu, Anda dapat mengecualikan pengguna dan basis data agar tidak diaudit. Anda juga dapat mengubah pencatatan log dalam sesi tertentu. Contoh berikut menunjukkan caranya kepada Anda.
**catatan**
Pengaturan parameter pada tingkat sesi lebih diutamakan daripada pengaturan dalam Postgre DB. RDS SQL Jika Anda tidak ingin pengguna basis data melewati pengaturan konfigurasi pencatatan audit, pastikan untuk mengubah izin mereka.
Misalkan Anda RDSuntuk instans Postgre SQL DB dikonfigurasi untuk mengaudit tingkat aktivitas yang sama untuk semua pengguna dan database. Anda kemudian memutuskan bahwa Anda tidak ingin mengaudit pengguna `myuser`. Anda dapat menonaktifkan audit `myuser` dengan SQL perintah berikut.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
Kemudian, Anda dapat menggunakan kueri berikut untuk memeriksa kolom `user_specific_settings` untuk `pgaudit.log` guna mengonfirmasi bahwa parameter ditetapkan ke `NONE`.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Anda akan melihat output seperti berikut ini.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Anda dapat menonaktifkan pencatatan log untuk pengguna tertentu di tengah-tengah sesi mereka menggunakan basis data dengan perintah berikut.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Gunakan kueri berikut untuk memeriksa kolom pengaturan pgaudit.log untuk kombinasi pengguna dan basis data tertentu.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Anda akan melihat output yang mirip dengan berikut ini.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Setelah menonaktifkan audit `myuser`, Anda memutuskan bahwa Anda tidak ingin melacak perubahan ke `mydatabase`. Anda menonaktifkan audit untuk basis data spesifik tersebut menggunakan perintah berikut.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
Kemudian, gunakan kueri berikut untuk memeriksa kolom database\$1specific\$1settings untuk mengonfirmasi bahwa pgaudit.log disetel ke. NONE
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Anda akan melihat output seperti berikut ini.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Untuk mengembalikan pengaturan ke pengaturan default untuk myuser, gunakan perintah berikut:
```
ALTER USER myuser RESET pgaudit.log;
```
Untuk mengembalikan pengaturan ke pengaturan default untuk basis data, gunakan perintah berikut ini.
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Untuk mengatur ulang pengguna dan basis data ke pengaturan default, gunakan perintah berikut.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
Anda juga dapat menangkap peristiwa tertentu ke log dengan menyetel `pgaudit.log` ke salah satu nilai lain yang diizinkan untuk parameter `pgaudit.log`. Untuk informasi selengkapnya, lihat [Daftar pengaturan yang diizinkan untuk parameter `pgaudit.log`](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Referensi untuk ekstensi pgAudit
Anda dapat menentukan tingkat detail yang diinginkan untuk log audit Anda dengan mengubah satu atau beberapa parameter yang tercantum di bagian ini.
## Mengatur perilaku pgAudit
Anda dapat mengontrol pencatatan log audit dengan mengubah satu atau beberapa parameter yang tercantum pada tabel berikut.
| Parameter | Deskripsi |
| --- | --- |
| `pgaudit.log` | Menentukan kelas pernyataan yang akan di-log oleh sesi audit pencatatan log. Nilai yang diizinkan termasuk ddl, fungsi, misc, baca, peran, tulis, tidak ada, semua. Untuk informasi selengkapnya, lihat [Daftar pengaturan yang diizinkan untuk parameter `pgaudit.log`](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Saat diaktifkan (diatur ke 1), tambahkan pernyataan ke jejak audit jika semua relasi dalam pernyataan ada di pg\$1catalog. |
| `pgaudit.log_level` | Menentukan tingkat log untuk digunakan dalam entri log. Nilai yang diizinkan: debug5, debug4, debug3, debug2, debug1, info, notifikasi, peringatan, log |
| `pgaudit.log_parameter` | Saat diaktifkan (diatur ke 1), parameter yang diteruskan dengan pernyataan ditangkap dalam log audit. |
| `pgaudit.log_relation` | Saat diaktifkan (diatur ke 1), log audit untuk sesi akan membuat entri log terpisah untuk setiap relasi (TABLE, VIEW, dan sebagainya) yang direferensikan dalam pernyataan SELECT atau DML. |
| `pgaudit.log_statement_once` | Menentukan apakah logging akan mencakup teks pernyataan dan parameter dengan entri log pertama untuk statement/substatement kombinasi atau dengan setiap entri. |
| `pgaudit.role` | Menentukan peran utama yang akan digunakan untuk pencatatan log audit objek. Satu-satunya entri yang diizinkan adalah `rds_pgaudit`. |
## Daftar pengaturan yang diizinkan untuk parameter `pgaudit.log`
| Nilai | Deskripsi |
| --- | --- |
| Tidak ada | Ini adalah opsi default. Tidak ada perubahan basis data yang dibuat log. |
| semua | Membuat log untuk semua (baca, tulis, fungsi, peran, ddl, misc). |
| ddl | Membuat log semua pernyataan bahasa definisi data (DDL) yang tidak disertakan dalam kelas `ROLE`. |
| Fungsi | Membuat log panggilan fungsi dan blok `DO`. |
| misc | Membuat log berbagai perintah, seperti `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` dan `SET`. |
| baca | Membuat log `SELECT` dan `COPY` saat sumbernya adalah relasi (seperti tabel) atau kueri. |
| peran | Membuat log pernyataan terkait peran dan hak akses, seperti `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE`, dan `DROP ROLE`. |
| tulis | Membuat log `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, dan `COPY` saat tujuannya adalah relasi (tabel). |
Untuk mencatat beberapa jenis peristiwa dengan audit sesi, gunakan daftar yang dipisahkan koma. Untuk membuat log semua jenis peristiwa, atur `pgaudit.log` ke `ALL`. Boot ulang instans DB Anda untuk menerapkan perubahan.
Dengan objek audit, Anda dapat memperbaiki pencatatan log audit agar berfungsi dengan relasi tertentu. Misalnya, Anda dapat menentukan bahwa Anda ingin pencatatan log audit untuk operasi `READ` di satu tabel atau lebih.
# Menjadwalkan pemeliharaan dengan ekstensi pg\$1cron PostgreSQL
Anda dapat menggunakan ekstensi `pg_cron` PostgreSQL untuk menjadwalkan perintah pemeliharaan dalam basis data PostgreSQL. Untuk informasi selengkapnya tentang ekstensi ini, lihat [What is pg\$1cron?](https://github.com/citusdata/pg_cron) dalam dokumentasi pg\$1cron.
Ekstensi `pg_cron` didukung pada mesin RDS for PostgreSQL versi 12.5 dan yang lebih tinggi.
Untuk mempelajari selengkapnya tentang penggunaan `pg_cron`, lihat [Menjadwalkan pekerjaan dengan pg\$1cron di RDS for PostgreSQL atau basis data Aurora Edisi Kompatibel PostgreSQL](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/).
**catatan**
Versi `pg_cron` ekstensi ditampilkan sebagai versi dua digit, misalnya, 1.6, dalam tampilan pg\$1available\$1extensions. Meskipun Anda mungkin melihat versi tiga digit, misalnya, 1.6.4 atau 1.6.5, tercantum dalam beberapa konteks, Anda harus menentukan versi dua digit saat melakukan peningkatan ekstensi.
**Topics**
+ [Menyiapkan ekstensi pg\$1cron](#PostgreSQL_pg_cron.enable)
+ [Mengizinkan pengguna basis data untuk menggunakan pg\$1cron](#PostgreSQL_pg_cron.permissions)
+ [Menjadwalkan pekerjaan pg\$1cron](#PostgreSQL_pg_cron.examples)
+ [Referensi untuk ekstensi pg\$1cron](#PostgreSQL_pg_cron.reference)
## Menyiapkan ekstensi pg\$1cron
Siapkan ekstensi `pg_cron` sebagai berikut:
1. Modifikasi grup parameter kustom yang terkait dengan instans DB PostgreSQL Anda dengan menambahkan `pg_cron` ke nilai parameter `shared_preload_libraries`.
+ Jika instans DB RDS for PostgreSQL menggunakan parameter `rds.allowed_extensions` untuk secara eksplisit mencantumkan ekstensi yang dapat diinstal, Anda perlu menambahkan ekstensi `pg_cron` ke daftar. Hanya versi RDS for PostgreSQL tertentu yang mendukung parameter `rds.allowed_extensions`. Secara default, semua ekstensi yang tersedia diizinkan. Untuk informasi selengkapnya, lihat [Membatasi penginstalan ekstensi PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Mulai ulang instans DB PostgreSQL untuk menerapkan perubahan pada grup parameter. Untuk mempelajari selengkapnya tentang penggunaan grup parameter, lihat [](USER_WorkingWithParamGroups.Modifying.md).
1. Setelah instans DB PostgreSQL dimulai ulang, jalankan perintah berikut menggunakan akun yang memiliki izin `rds_superuser`. Misalnya, jika Anda menggunakan pengaturan default saat membuat instans DB RDS for PostgreSQL, hubungkan sebagai pengguna `postgres` dan buat ekstensi.
```
CREATE EXTENSION pg_cron;
```
Penjadwal `pg_cron` diatur dalam basis data PostgreSQL default bernama `postgres`. Objek `pg_cron` dibuat dalam basis data `postgres` ini dan semua tindakan penjadwalan berjalan dalam basis data ini.
1. Anda dapat menggunakan pengaturan default, atau Anda dapat menjadwalkan pekerjaan untuk berjalan di basis data lain dalam instans DB PostgreSQL Anda. Untuk menjadwalkan pekerjaan basis data lain dalam instans DB PostgreSQL Anda, lihat contoh di [Menjadwalkan pekerjaan cron untuk basis data selain basis data default](#PostgreSQL_pg_cron.otherDB).
## Mengizinkan pengguna basis data untuk menggunakan pg\$1cron
Menginstal ekstensi `pg_cron` membutuhkan hak istimewa `rds_superuser`. Namun, izin untuk menggunakan `pg_cron` dapat diberikan (oleh anggota grup/peran `rds_superuser`) kepada pengguna basis data lain, sehingga mereka dapat menjadwalkan pekerjaannya sendiri. Sebaiknya hanya berikan izin yang diperlukan ke skema `cron` sesuai kebutuhan ketika skema ini dapat meningkatkan operasi di lingkungan produksi Anda.
Untuk memberikan izin pengguna basis data dalam skema `cron`, jalankan perintah berikut:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Ini memberikan *db-user* izin untuk mengakses `cron` skema untuk menjadwalkan pekerjaan cron untuk objek yang mereka memiliki izin untuk mengakses. Jika pengguna basis data tidak memiliki izin, tugas akan gagal setelah memposting pesan kesalahan ke file `postgresql.log`, seperti yang ditunjukkan berikut:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
Dengan kata lain, pastikan bahwa pengguna database yang diberikan izin pada `cron` skema juga memiliki izin pada objek (tabel, skema, dan sebagainya) yang mereka rencanakan untuk dijadwalkan.
Detail pekerjaan cron dan keberhasilan atau kegagalannya juga ditangkap dalam `cron.job_run_details` tabel. Untuk informasi selengkapnya, lihat [Tabel untuk menjadwalkan pekerjaan dan menangkap status](#PostgreSQL_pg_cron.tables).
## Menjadwalkan pekerjaan pg\$1cron
Bagian berikut menunjukkan bagaimana Anda dapat menjadwalkan berbagai tugas manajemen menggunakan pekerjaan `pg_cron`.
**catatan**
Saat membuat pekerjaan `pg_cron`, periksa apakah pengaturan jumlah `max_worker_processes` lebih besar dari `cron.max_running_jobs`. Pekerjaan `pg_cron` akan gagal jika kehabisan proses pekerja latar belakang. Jumlah default pekerjaan `pg_cron` adalah `5`. Untuk informasi selengkapnya, lihat [Parameter untuk mengelola ekstensi pg\$1cron](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [Mengosongkan tabel](#PostgreSQL_pg_cron.vacuum)
+ [Membersihkan tabel riwayat pg\$1cron](#PostgreSQL_pg_cron.job_run_details)
+ [Mencatat log kesalahan ke file postgresql.log saja](#PostgreSQL_pg_cron.log_run)
+ [Menjadwalkan pekerjaan cron untuk basis data selain basis data default](#PostgreSQL_pg_cron.otherDB)
### Mengosongkan tabel
Pengosongan otomatis menangani pemeliharaan vakum untuk kebanyakan kasus. Namun, Anda mungkin ingin menjadwalkan pengosongan tabel pada waktu yang Anda pilih.
Lihat juga, [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
Berikut adalah contoh penggunaan fungsi `cron.schedule` guna menyiapkan pekerjaan untuk menggunakan `VACUUM FREEZE` pada tabel tertentu setiap hari pada pukul 22.00 (GMT).
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Setelah contoh sebelumnya berjalan, Anda dapat memeriksa riwayatnya di tabel `cron.job_run_details` seperti berikut.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
Berikut ini adalah query dari `cron.job_run_details` tabel untuk melihat pekerjaan gagal.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Untuk informasi selengkapnya, lihat [Tabel untuk menjadwalkan pekerjaan dan menangkap status](#PostgreSQL_pg_cron.tables).
### Membersihkan tabel riwayat pg\$1cron
Tabel `cron.job_run_details` berisi riwayat pekerjaan cron yang ukurannya bisa menjadi sangat besar dari waktu ke waktu. Sebaiknya jadwalkan pekerjaan untuk membersihkan tabel ini. Sebagai contoh, menyimpan entri selama seminggu mungkin sudah cukup untuk tujuan pemecahan masalah.
Contoh berikut ini menggunakan fungsi [cron.schedule](#PostgreSQL_pg_cron.schedule) untuk menjadwalkan pekerjaan yang berjalan setiap hari pada tengah malam untuk membersihkan tabel `cron.job_run_details`. Pekerjaan ini hanya menyimpan tujuh hari terakhir. Gunakan akun `rds_superuser` untuk menjadwalkan pekerjaan seperti berikut.
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Untuk informasi selengkapnya, lihat [Tabel untuk menjadwalkan pekerjaan dan menangkap status](#PostgreSQL_pg_cron.tables).
### Mencatat log kesalahan ke file postgresql.log saja
Untuk mencegah penulisan ke tabel `cron.job_run_details`, modifikasi grup parameter yang terkait dengan instans DB PostgreSQL dan nonaktifkan parameter `cron.log_run`. Ekstensi `pg_cron` tidak lagi menulis ke tabel dan menangkap kesalahan ke file `postgresql.log` saja. Untuk informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.Modifying.md).
Gunakan perintah berikut untuk memeriksa nilai parameter `cron.log_run`.
```
postgres=> SHOW cron.log_run;
```
Untuk informasi selengkapnya, lihat [Parameter untuk mengelola ekstensi pg\$1cron](#PostgreSQL_pg_cron.parameters).
### Menjadwalkan pekerjaan cron untuk basis data selain basis data default
Semua metadata untuk `pg_cron` disimpan dalam basis data default PostgreSQL bernama `postgres`. Karena pekerja latar belakang digunakan untuk menjalankan pekerjaan pemeliharaan cron, Anda dapat menjadwalkan pekerjaan di salah satu basis data Anda dalam instans DB PostgreSQL:
**catatan**
Hanya pengguna dengan `rds_superuser` peran atau `rds_superuser` hak istimewa yang dapat mencantumkan semua pekerjaan cron dalam database. Pengguna lain hanya dapat melihat pekerjaan mereka sendiri di `cron.job` tabel.
1. Dalam basis data cron, jadwalkan pekerjaan seperti yang biasa Anda lakukan menggunakan [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. Sebagai pengguna dengan peran `rds_superuser`, perbarui kolom basis data untuk pekerjaan yang baru saja Anda buat agar berjalan di basis data lain dalam instans DB PostgreSQL Anda.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Verifikasi dengan membuat kueri tabel `cron.job`.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**catatan**
Dalam beberapa situasi, Anda mungkin menambahkan pekerjaan cron yang ingin Anda jalankan di basis data yang berbeda. Dalam kasus tersebut, pekerjaan mungkin mencoba untuk dijalankan dalam basis data default (`postgres`) sebelum kolom basis data ditentukan dengan benar. Jika nama pengguna memiliki izin, berarti pekerjaan berhasil dijalankan di basis data default.
## Referensi untuk ekstensi pg\$1cron
Anda dapat menggunakan parameter, fungsi, dan tabel berikut dengan ekstensi `pg_cron`. Untuk informasi selengkapnya, lihat [What is pg\$1cron?](https://github.com/citusdata/pg_cron) dalam dokumentasi pg\$1cron.
**Topics**
+ [Parameter untuk mengelola ekstensi pg\$1cron](#PostgreSQL_pg_cron.parameters)
+ [Referensi fungsi: cron.schedule](#PostgreSQL_pg_cron.schedule)
+ [Referensi fungsi: cron.unschedule](#PostgreSQL_pg_cron.unschedule)
+ [Tabel untuk menjadwalkan pekerjaan dan menangkap status](#PostgreSQL_pg_cron.tables)
### Parameter untuk mengelola ekstensi pg\$1cron
Berikut adalah daftar parameter yang mengontrol perilaku ekstensi `pg_cron`.
| Parameter | Deskripsi |
| --- | --- |
| cron.database\$1name | Basis data penyimpanan metadata `pg_cron`. |
| cron.host | Nama host untuk menghubungkan ke PostgreSQL. Anda tidak dapat mengubah nilai ini. |
| cron.log\$1run | Catat log setiap pekerjaan yang berjalan di tabel `job_run_details`. Nilainya adalah `on` atau `off`. Untuk informasi selengkapnya, lihat [Tabel untuk menjadwalkan pekerjaan dan menangkap status](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Catat log semua pernyataan cron sebelum menjalankannya. Nilainya adalah `on` atau `off`. |
| cron.max\$1running\$1jobs | Jumlah maksimum pekerjaan yang dapat dijalankan secara bersamaan. |
| cron.use\$1background\$1workers | Gunakan pekerja latar belakang, bukan sesi klien. Anda tidak dapat mengubah nilai ini. |
Gunakan perintah SQL berikut untuk menampilkan parameter ini dan nilainya.
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Referensi fungsi: cron.schedule
Fungsi ini menjadwalkan pekerjaan cron. Pada mulanya, pekerjaan dijadwalkan di basis data `postgres` default. Fungsi tersebut mengembalikan nilai `bigint` yang mewakili pengidentifikasi pekerjaan. Untuk menjadwalkan pekerjaan agar berjalan di basis data lain dalam instans DB PostgreSQL Anda, lihat contoh di [Menjadwalkan pekerjaan cron untuk basis data selain basis data default](#PostgreSQL_pg_cron.otherDB).
Fungsi ini memiliki dua format sintaks.
**Sintaks**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parameter**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Contoh**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Referensi fungsi: cron.unschedule
Fungsi ini menghapus pekerjaan cron. Anda dapat menentukan `job_name` atau `job_id`. Suatu kebijakan memastikan bahwa Anda adalah pemilik guna menghapus jadwal pekerjaan. Fungsi akan mengembalikan Boolean yang menunjukkan keberhasilan atau kegagalan.
Fungsi memiliki format sintaks berikut.
**Sintaks**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parameter**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Contoh**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tabel untuk menjadwalkan pekerjaan dan menangkap status
Tabel berikut digunakan untuk menjadwalkan pekerjaan cron dan mencatat bagaimana pekerjaan tersebut diselesaikan.
| Tabel | Deskripsi |
| --- | --- |
| cron.job | Berisi metadata tentang setiap pekerjaan yang dijadwalkan. Sebagian besar interaksi dengan tabel ini harus dilakukan menggunakan fungsi `cron.schedule` dan `cron.unschedule`. Sebaiknya jangan memberikan pembaruan atau memasukkan hak istimewa secara langsung ke tabel ini. Hal tersebut akan memungkinkan pengguna untuk memperbarui kolom `username` agar berjalan sebagai `rds-superuser`. |
| cron.job\$1run\$1details | Berisi informasi historis tentang pekerjaan terjadwal yang telah dijalankan sebelumnya. Hal ini berguna untuk menyelidiki status, pesan kembali, dan waktu mulai dan akhir dari pekerjaan yang berjalan. Agar ukuran tabel ini tidak bertambah besar, bersihkan secara rutin. Sebagai contoh, lihat [Membersihkan tabel riwayat pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Menggunakan pglogical untuk menyinkronkan data di seluruh instans
Semua versi RDS for PostgreSQL yang tersedia saat ini mendukung ekstensi `pglogical`. Ekstensi pglogical mendahului fitur replikasi logis yang mirip secara fungsional yang diperkenalkan oleh PostgreSQL di versi 10. Untuk informasi selengkapnya, lihat [Melakukan replikasi logis untuk Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
Ekstensi `pglogical` ini mendukung replikasi logis antara dua atau lebih. Instans DB RDS for PostgreSQL. Ini juga mendukung replikasi antara versi PostgreSQL yang berbeda, dan antara basis data yang berjalan pada instans DB RDS for PostgreSQL dan klaster DB Aurora PostgreSQL. Ekstensi `pglogical` menggunakan model terbitkan-dan-langganan untuk mereplikasi perubahan pada tabel dan objek lain, seperti urutan, dari penerbit ke pelanggan. Itu bergantung pada slot replikasi untuk memastikan bahwa perubahan disinkronkan dari simpul penerbit ke simpul pelanggan, didefinisikan sebagai berikut.
+ *Simpul penerbit* adalah instans DB RDS for PostgreSQL yang merupakan sumber data yang akan direplikasi ke simpul lain. Simpul penerbit mendefinisikan tabel yang akan direplikasi dalam set publikasi.
+ *Simpul pelanggan* adalah instans DB RDS for PostgreSQL yang menerima pembaruan WAL dari penerbit. Pelanggan membuat langganan untuk menghubungkan ke penerbit dan mendapatkan data WAL yang dikodekan. Saat pelanggan membuat langganan, slot replikasi dibuat pada simpul penerbit.
Berikut ini, Anda dapat menemukan informasi tentang cara mengatur ekstensi `pglogical`.
**Topics**
+ [Persyaratan dan batasan untuk ekstensi pglogical](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [Menyiapkan ekstensi pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [Menyiapkan replikasi logis untuk instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [Membangun kembali replikasi logis setelah peningkatan besar](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [Mengelola slot replikasi logis untuk untuk PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [Referensi parameter untuk ekstensi pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Persyaratan dan batasan untuk ekstensi pglogical
Semua rilis RDS for PostgreSQL yang tersedia saat ini mendukung ekstensi `pglogical`.
Baik simpul penerbit maupun simpul pelanggan harus disiapkan untuk replikasi logis.
Tabel yang ingin Anda replikasi dari penerbit ke pelanggan harus memiliki nama dan skema yang sama. Tabel ini juga harus berisi kolom yang sama, dan kolom harus menggunakan jenis data yang sama. Tabel penerbit dan pelanggan harus memiliki kunci primer yang sama. Sebaiknya Anda hanya menggunakan PRIMARY KEY sebagai batasan unik.
Tabel pada simpul pelanggan dapat memiliki batasan yang lebih permisif dibandingkan yang ada di simpul penerbit untuk batasan CHECK dan NOT NULL.
Ekstensi `pglogical` ini menyediakan fitur seperti replikasi dua arah yang tidak didukung oleh fitur replikasi logis default PostgreSQL (versi 10 dan lebih tinggi). Untuk informasi selengkapnya, lihat [replikasi bi-direksional PostgreSQL menggunakan pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
# Menyiapkan ekstensi pglogical
Untuk menyiapkan ekstensi `pglogical` pada instans DB RDS for PostgreSQL , tambahkan `pglogical` ke pustaka bersama pada grup parameter DB kustom untuk instans DB RDS for PostgreSQL. Anda juga perlu mengatur nilai parameter `rds.logical_replication` ke `1`, untuk mengaktifkan penguraian kode logis. Terakhir, Anda membuat ekstensi di basis data. Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk tugas-tugas ini.
Anda harus memiliki izin sebagai peran `rds_superuser` untuk melakukan semua tugas ini.
Langkah-langkah berikut mengasumsikan bahwa instans DB RDS for PostgreSQL Anda terhubung dengan grup parameter klaster DB kustom. Untuk informasi cara membuat grup parameter DB kustom, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
## Konsol
**Menyiapkan ekstensi pglogical**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih instans DB RDS for PostgreSQL.
1. Buka tab **Konfigurasi** untuk Instans DB RDS for PostgreSQL. Di antara detail Instans, temukan tautan **Grup parameter**.
1. Pilih tautan untuk membuka parameter kustom yang terkait dengan Anda. Instans DB RDS for PostgreSQL.
1. Di kolom pencarian **Parameter**, ketik `shared_pre` untuk menemukan parameter `shared_preload_libraries`.
1. Pilih **Edit parameter** untuk mengakses nilai properti.
1. Tambahkan `pglogical` ke daftar di kolom **Nilai**. Gunakan koma untuk memisahkan item dalam daftar nilai.
![\[Gambar parameter shared_preload_libraries dengan pglogical yang ditambahkan.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Temukan parameter `rds.logical_replication` dan atur ke `1`, untuk mengaktifkan replikasi logis.
1. Boot ulang instans DB RDS for PostgreSQL DB Anda agar perubahan Anda diterapkan.
1. Saat instans tersedia, Anda dapat menggunakan `psql` (atau pgAdmin) untuk terhubung ke instans DB RDS for PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Untuk memverifikasi bahwa pglogical telah diinisialisasi, jalankan perintah berikut.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Verifikasikan pengaturan yang memungkinkan penguraian kode logis, sebagai berikut.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Buat ekstensi, sebagai berikut.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Pilih **Simpan perubahan**.
1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih instans DB RDS for PostgreSQL dari daftar Basis Data untuk memilihnya, lalu pilih **Boot ulang** dari menu Tindakan.
## AWS CLI
**Menyiapkan ekstensi pglogical**
Untuk mengatur pglogical menggunakan AWS CLI, Anda memanggil [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)operasi untuk memodifikasi parameter tertentu dalam grup parameter kustom Anda seperti yang ditunjukkan dalam prosedur berikut.
1. Gunakan AWS CLI perintah berikut `pglogical` untuk menambah `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan AWS CLI perintah berikut untuk mengatur `rds.logical_replication` `1` untuk mengaktifkan kemampuan decoding logis untuk . Instans DB RDS for PostgreSQL.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan AWS CLI perintah berikut untuk me-reboot sehingga pustaka pglogical diinisialisasi.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Saat instans tersedia, gunakan `psql` untuk terhubung ke instans DB RDS for PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Buat ekstensi, sebagai berikut.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Reboot menggunakan perintah berikut. AWS CLI
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Menyiapkan replikasi logis untuk instans DB RDS for PostgreSQL
Prosedur berikut menunjukkan cara memulai replikasi logis di antara dua instans DB RDS for PostgreSQL. Langkah-langkah mengasumsikan bahwa sumber (penerbit) dan target (pelanggan) memiliki ekstensi `pglogical` yang disiapkan seperti yang dijelaskan dalam [Menyiapkan ekstensi pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
**catatan**
`node_name`Node pelanggan tidak dapat memulai dengan`rds`.
**Untuk membuat simpul penerbit dan menentukan tabel untuk direplikasi**
Langkah-langkah ini mengasumsikan bahwa instans DB RDS for PostgreSQL memiliki basis data yang memiliki satu atau beberapa tabel yang ingin direplikasi ke simpul lain. Anda perlu membuat ulang struktur tabel dari penerbit pada pelanggan, jadi pertama-tama, dapatkan struktur tabel jika perlu. Anda dapat melakukannya dengan menggunakan `psql` metacommand `\d tablename`, lalu membuat tabel yang sama pada instans pelanggan. Prosedur berikut membuat tabel contoh pada penerbit (sumber) untuk tujuan demonstrasi.
1. Gunakan `psql` untuk terhubung ke instans yang memiliki tabel yang ingin Anda gunakan sebagai sumber untuk pelanggan.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Jika tidak memiliki tabel yang ingin ditiru, Anda dapat membuat tabel contoh sebagai berikut.
1. Buat contoh tabel menggunakan pernyataan SQL berikut.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Mengisi tabel dengan data yang dihasilkan menggunakan pernyataan SQL berikut.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Verifikasikan bahwa data ada dalam tabel menggunakan pernyataan SQL berikut.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifikasi instans DB RDS for PostgreSQL ini sebagai simpul penerbit, sebagai berikut.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Tambahkan tabel yang ingin Anda replikasi ke set replikasi default. Untuk informasi set replikasi selengkapnya, lihat [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) dalam dokumentasi pglogical.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
Penyiapan simpul penerbit selesai. Anda sekarang dapat menyiapkan simpul pelanggan untuk menerima informasi terkini dari penerbit.
**Untuk menyiapkan simpul pelanggan dan membuat langganan untuk menerima informasi terkini**
Langkah-langkah ini mengasumsikan bahwa instans DB RDS for PostgreSQL telah disiapkan dengan ekstensi `pglogical`. Untuk informasi selengkapnya, lihat [Menyiapkan ekstensi pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Gunakan `psql` untuk terhubung ke instans yang ingin Anda terima informasi terkini dari penerbit.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Pada pelanggan instans DB RDS for PostgreSQL, buat tabel yang sama yang ada pada penerbit. Untuk contoh ini, tabelnya adalah `docs_lab_table`. Anda dapat membuat tabel sebagai berikut.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Verifikasi bahwa tabel ini kosong.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifikasi instans DB RDS for PostgreSQL ini sebagai simpul pelanggan, sebagai berikut.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Buat langganan.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Saat Anda menyelesaikan langkah ini, data dari tabel pada penerbit akan dibuat dalam tabel pada pelanggan. Anda dapat memverifikasi bahwa tabel telah dibuat menggunakan query SQL berikut.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
Mulai dari titik ini, perubahan yang dilakukan pada tabel pada penerbit direplikasi ke tabel pada pelanggan.
# Membangun kembali replikasi logis setelah peningkatan besar
Sebelum Anda dapat melakukan upgrade versi utama dari untuk instance Postgre SQL DB yang diatur sebagai node penerbit untuk replikasi logis, Anda harus menghapus semua slot replikasi, bahkan yang tidak aktif. Kami menyarankan Anda mengalihkan sementara transaksi database dari node penerbit, menjatuhkan slot replikasi, meningkatkan dan kemudian membangun kembali dan memulai ulang replikasi.
Slot replikasi hanya di-hosting di simpul penerbit. Node SQL pelanggan RDS untuk Postgre dalam skenario replikasi logis tidak memiliki slot untuk turun, tetapi tidak dapat ditingkatkan ke versi utama sementara itu ditetapkan sebagai simpul pelanggan dengan berlangganan ke penerbit. Sebelum memutakhirkan node SQL pelanggan RDS untuk Postgre, lepaskan langganan dan node. Untuk informasi selengkapnya, lihat [Mengelola slot replikasi logis untuk untuk PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
## Menentukan bahwa replikasi logis telah terganggu
Anda dapat menentukan bahwa proses replikasi telah terganggu dengan menanyakan simpul penerbit atau simpul pelanggan, sebagai berikut.
**Untuk memeriksa simpul penerbit**
+ Gunakan `psql` untuk terhubung ke simpul penerbit, lalu buat kueri fungsi `pg_replication_slots`. Perhatikan nilai di kolom aktif. Biasanya, ini akan kembali `t` (benar), menunjukkan bahwa replikasi aktif. Jika kueri kembali `f` (salah), ini merupakan indikasi bahwa replikasi ke pelanggan telah berhenti.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**Untuk memeriksa simpul pelanggan**
Pada simpul pelanggan, Anda dapat memeriksa status replikasi dengan tiga cara berbeda.
+ Lihat melalui SQL log Postgre pada node pelanggan untuk menemukan pesan kegagalan. Log dapat mengidentifikasi kegagalan dengan pesan yang menyertakan kode keluar 1, sebagaimana ditunjukkan berikut.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Buat kueri fungsi `pg_replication_origin`. Hubungkan ke basis data pada simpul pelanggan menggunakan `psql` dan buat kueri fungsi `pg_replication_origin`, sebagai berikut.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
Set hasil kosong berarti replikasi telah terganggu. Biasanya, Anda akan melihat output seperti berikut.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Buat kueri fungsi `pglogical.show_subscription_status` sebagaimana ditunjukkan pada contoh berikut.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Output ini menunjukkan bahwa replikasi telah terganggu. Statusnya adalah `down`. Biasanya, output menunjukkan status sebagai `replicating`.
Jika proses replikasi logis terganggu, Anda dapat membangun kembali replikasi dengan mengikuti langkah-langkah berikut.
**Untuk membangun kembali replikasi logis antara simpul penerbit dan pelanggan**
Untuk membangun kembali replikasi, pertama-tama Anda memutuskan sambungan pelanggan dari simpul penerbit, lalu membangun kembali langganan, seperti yang diuraikan dalam langkah-langkah ini.
1. Hubungkan ke simpul pelanggan menggunakan `psql`, sebagai berikut.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Nonaktifkan langganan menggunakan fungsi `pglogical.alter_subscription_disable`.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Dapatkan identifier simpul penerbit dengan menanyakan `pg_replication_origin`, sebagai berikut.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Gunakan respons dari langkah sebelumnya dengan perintah `pg_replication_origin_create` untuk menetapkan pengenal yang dapat digunakan oleh langganan saat dibuat kembali.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Aktifkan langganan dengan meneruskan namanya menggunakan status `true`, sebagaimana ditunjukkan dalam contoh berikut.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Periksa status simpul. Statusnya harus `replicating` sebagaimana ditunjukkan dalam contoh ini.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Periksa status slot replikasi pelanggan pada simpul penerbit. Kolom `active` slot harus kembali `t` (benar), menunjukkan bahwa replikasi telah dibuat kembali.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Mengelola slot replikasi logis untuk untuk PostgreSQL
Sebelum dapat melakukan peningkatan versi utama dari instans DB RDS for PostgreSQL yang disiapkan sebagai simpul penerbit untuk replikasi logis, Anda harus menghapus semua slot replikasi, bahkan yang tidak aktif. Proses pra-pemeriksaan peningkatan versi utama akan memberi tahu Anda bahwa peningkatan tidak dapat dilanjutkan sampai slot dihapuskan sementara.
Untuk menghapus sementara slot dari instans DB RDS for PostgreSQL Anda, pertama-tama hapus sementara langganan, lalu hapus sementara slotnya.
Untuk mengidentifikasi slot replikasi yang dibuat menggunakan ekstensi `pglogical`, masuk ke setiap basis data dan dapatkan nama simpul. Bila membuat kueri simpul pelanggan, Anda akan mendapatkan simpul penerbit dan pelanggan dalam output, sebagaimana ditunjukkan dalam contoh ini.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Anda dapat memperoleh detail tentang langganan dengan kueri berikut.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Anda sekarang dapat menghapus sementara langganan, sebagai berikut.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Setelah menghapus sementara langganan, Anda dapat menghapus simpul.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Anda dapat memverifikasi bahwa simpul tidak ada lagi, sebagai berikut.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Referensi parameter untuk ekstensi pglogical
Dalam tabel, Anda dapat menemukan parameter yang terkait dengan ekstensi `pglogical`. Parameter seperti `pglogical.conflict_log_level` dan `pglogical.conflict_resolution` digunakan untuk menangani konflik pembaruan. Konflik dapat muncul saat perubahan dilakukan secara lokal ke tabel yang sama yang berlangganan terhadap perubahan dari penerbit. Konflik juga dapat terjadi selama berbagai skenario, seperti replikasi dua arah atau saat beberapa pelanggan mereplikasi dari penerbit yang sama. Untuk informasi selengkapnya, lihat [replikasi bi-direksional PostgreSQL menggunakan pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
| Parameter | Deskripsi |
| --- | --- |
| pglogical.batch\$1inserts | Melakukan penyisipan batch jika memungkinkan. Tidak diatur secara default. Ubah ke '1' untuk mengaktifkan, '0' untuk menonaktifkan. |
| pglogical.conflict\$1log\$1level | Menetapkan tingkat log yang digunakan untuk mencatat log konflik yang diselesaikan. Nilai string yang didukung adalah debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. |
| pglogical.conflict\$1resolution | Menetapkan metode yang digunakan untuk menyelesaikan konflik saat konflik dapat diselesaikan. Nilai string yang didukung adalah kesalahan, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Opsi koneksi untuk ditambahkan ke semua koneksi simpul peer. |
| pglogical.synchronous\$1commit | nilai komit sinkron spesifik pglogical |
| pglogical.use\$1spi | Gunakan SPI (antarmuka pemrograman server) alih-alih API tingkat rendah untuk menerapkan perubahan. Atur ke '1' untuk mengaktifkan, '0' untuk menonaktifkan. Untuk informasi SPI selengkapnya, lihat [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) dalam dokumentasi PostgreSQL. |
# Menggunakan pgactive untuk mendukung replikasi aktif-aktif
Ekstensi `pgactive` menggunakan replikasi aktif-aktif untuk mendukung dan mengoordinasikan operasi penulisan pada beberapa RDS untuk basis data PostgreSQL. Amazon RDS for `pgactive` PostgreSQL mendukung ekstensi pada versi berikut:
+ RDS untuk PostgreSQL 17.0 dan semua versi yang lebih tinggi
+ RDS untuk PostgreSQL 16.1 dan versi 16 yang lebih tinggi
+ RDS untuk PostgreSQL 15.4-R2 dan versi 15 yang lebih tinggi
+ RDS untuk PostgreSQL 14.10 dan versi 14 yang lebih tinggi
+ RDS untuk PostgreSQL 13.13 dan versi 13 yang lebih tinggi
+ RDS untuk PostgreSQL 12.17 dan versi 12 yang lebih tinggi
+ RDS untuk PostgreSQL 11.22
**catatan**
Ketika ada operasi tulis pada lebih dari satu basis data dalam konfigurasi replikasi, konflik mungkin terjadi. Untuk informasi selengkapnya, lihat [Menangani konflik dalam replikasi aktif-aktif](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
**Topics**
+ [Batasan untuk ekstensi pgactive](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [Menginisialisasi kemampuan ekstensi pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [Menyiapkan replikasi aktif-aktif untuk instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [Mengukur lag replikasi di antara anggota pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [Mengkonfigurasi pengaturan parameter untuk ekstensi pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [Memahami konflik aktif-aktif](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [Memahami skema pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [referensi fungsi pgactive](pgactive-functions-reference.md)
+ [Menangani konflik dalam replikasi aktif-aktif](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [Menangani urutan dalam replikasi aktif-aktif](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Batasan untuk ekstensi pgactive
+ Semua tabel memerlukan Kunci Primer, jika bukan Pembaruan dan Hapus tidak akan diperbolehkan. Nilai di kolom Kunci Primer tidak boleh diperbarui.
+ Urutan mungkin memiliki celah dan terkadang mungkin tidak mengikuti perintah. Urutan tidak direplikasi. Untuk informasi selengkapnya, lihat [Menangani urutan dalam replikasi aktif-aktif](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ DDL dan objek besar tidak direplikasi.
+ Indeks unik sekunder dapat menyebabkan divergensi data.
+ Kolasi harus identik pada semua simpul dalam grup.
+ Penyeimbang beban di seluruh simpul adalah anti-pola.
+ Transaksi besar dapat menyebabkan kelambatan replikasi.
# Menginisialisasi kemampuan ekstensi pgactive
Untuk menginisialisasi kemampuan ekstensi `pgactive` pada instans DB RDS for PostgreSQL, tetapkan nilai parameter `rds.enable_pgactive` ke `1` dan kemudian buat ekstensi dalam basis data. Melakukannya secara otomatis menyalakan parameter `rds.logical_replication` dan `track_commit_timestamp` lalu menetapkan nilai `wal_level` ke `logical`.
Anda harus memiliki izin sebagai peran `rds_superuser` untuk melakukan tugas-tugas ini.
Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk membuat RDS yang diperlukan untuk instance PostgreSQL DB. Langkah-langkah berikut mengasumsikan bahwa instans DB RDS for PostgreSQL Anda dikaitkan dengan grup parameter DB kustom. Untuk informasi tentang cara membuat grup parameter DB kustom, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
## Konsol
**Untuk menginisialisasi kemampuan ekstensi pgactive**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih instans DB RDS for PostgreSQL.
1. Buka tab **Konfigurasi** untuk instans DB RDS for PostgreSQL. Dalam detail instans, temukan tautan **grup parameter instans DB**.
1. Pilih tautan untuk membuka parameter kustom yang terkait dengan instans DB RDS for PostgreSQL.
1. Temukan parameter `rds.enable_pgactive`, lalu atur ke `1` untuk menginisialisasi kemampuan `pgactive`.
1. Pilih **Simpan perubahan**.
1. Dalam panel navigasi yang ada pada konsol Amazon RDS, pilih **Basis Data**.
1. Pilih instans DB RDS for PostgreSQL, kemudian pilih **Boot ulang** dari menu **Tindakan**.
1. Konfirmasikan boot ulang instans DB sehingga perubahan Anda berlaku.
1. Ketika instans tersedia, Anda dapat menggunakan `psql` klien PostgreSQL lainnya agar terhubung ke instans DB RDS for PostgreSQL.
Contoh berikut mengasumsikan bahwa RDS Anda untuk PostgreSQL DB instance memiliki database default bernama. *postgres*
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Untuk memverifikasi bahwa pgactive telah diinisialisasi, jalankan perintah berikut.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Jika `pgactive` berada di `shared_preload_libraries`, perintah sebelumnya akan mengembalikan yang berikut:
```
?column?
----------
t
```
## AWS CLI
**Untuk menginisialisasi kemampuan ekstensi pgactive**
Untuk menginisialisasi `pgactive` penggunaan AWS CLI, panggil [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)operasi untuk memodifikasi parameter tertentu dalam grup parameter kustom Anda seperti yang ditunjukkan dalam prosedur berikut.
1. Gunakan AWS CLI perintah berikut untuk mengatur `rds.enable_pgactive` untuk menginisialisasi `pgactive` kemampuan `1` untuk RDS untuk PostgreSQL DB instance.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan AWS CLI perintah berikut untuk me-reboot RDS untuk PostgreSQL DB instance sehingga perpustakaan diinisialisasi. `pgactive`
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Saat instans tersedia, gunakan `psql` untuk terhubung ke instans DB RDS for PostgreSQL.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Untuk memverifikasi bahwa pgactive telah diinisialisasi, jalankan perintah berikut.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Jika `pgactive` berada di `shared_preload_libraries`, perintah sebelumnya akan mengembalikan yang berikut:
```
?column?
----------
t
```
# Menyiapkan replikasi aktif-aktif untuk instans DB RDS for PostgreSQL
Prosedur berikut menunjukkan cara memulai replikasi aktif-aktif antara dua klaster jika tersedia. `pgactive` Untuk menjalankan contoh ketersediaan tinggi beberapa wilayah, Anda perlu menerapkan instans Amazon RDS for PostgreSQL di dua wilayah berbeda dan menyiapkan VPC Peering. Untuk informasi selengkapnya, lihat [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**catatan**
Mengirim lalu lintas antar beberapa wilayah dapat menimbulkan biaya tambahan.
Langkah-langkah ini mengasumsikan bahwa RDS untuk instance PostgreSQL DB telah diaktifkan dengan ekstensi. `pgactive` Untuk informasi selengkapnya, lihat [Menginisialisasi kemampuan ekstensi pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**Mengonfigurasi instans DB RDS for PostgreSQL dengan ekstensi `pgactive`**
Contoh berikut menggambarkan cara grup `pgactive` dibuat, bersama dengan langkah-langkah lain yang diperlukan untuk membuat ekstensi `pgactive` pada instans DB RDS for PostgreSQL.
1. Gunakan `psql` atau alat klien lain agar terhubung ke instans DB RDS for PostgreSQL.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Buat basis data pada instans RDS for PostgreSQL menggunakan perintah berikut:
```
postgres=> CREATE DATABASE app;
```
1. Alihkan koneksi ke basis data baru menggunakan perintah berikut:
```
\c app
```
1. Buat dan konten tabel menggunakan pernyataan SQL berikut:
1. Buat contoh tabel menggunakan pernyataan SQL berikut.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Mengisi tabel dengan beberapa contoh data yang dihasilkan dengan menggunakan pernyataan SQL berikut.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Verifikasi bahwa data ada dalam tabel dengan menggunakan pernyataan SQL berikut.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Buat ekstensi `pgactive` pada basis data yang ada.
```
app=> CREATE EXTENSION pgactive;
```
1. Untuk membuat dan menginisialisasi grup pgactive dengan aman, gunakan perintah berikut:
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Sekarang Anda dapat menginisialisasi grup replikasi dan menambahkan contoh pertama ini:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Gunakan perintah berikut sebagai metode alternatif tetapi kurang aman untuk membuat dan menginisialisasi grup pgactive:
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app adalah nama yang Anda tetapkan untuk mengidentifikasi simpul secara unik dalam grup `pgactive`.
**catatan**
Untuk melakukan langkah ini dengan sukses pada instans DB yang dapat diakses publik, Anda harus mengaktifkan parameter `rds.custom_dns_resolution` dengan menyetelnya ke `1`.
1. Untuk memeriksa apakah instans DB sudah siap, gunakan perintah berikut ini:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Jika perintah berhasil, Anda dapat melihat output sebagai berikut:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**Mengonfigurasi instans RDS for PostgreSQL kedua dan bergabung ke grup `pgactive`**
Contoh berikut menggambarkan cara instans DB RDS for PostgreSQL bergabung ke grup `pgactive`, bersama dengan langkah-langkah lain yang diperlukan untuk membuat ekstensi `pgactive` pada instans DB.
Langkah-langkah ini mengasumsikan bahwa instans DB RDS for PostgreSQL lainnya telah disiapkan dengan ekstensi `pgactive`. Untuk informasi selengkapnya, lihat [Menginisialisasi kemampuan ekstensi pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Gunakan `psql` untuk terhubung ke instans yang ingin Anda terima pembaruan dari penerbit.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Buat basis data pada instans DB RDS for PostgreSQL kedua menggunakan perintah berikut:
```
postgres=> CREATE DATABASE app;
```
1. Alihkan koneksi ke basis data baru menggunakan perintah berikut:
```
\c app
```
1. Buat ekstensi `pgactive` pada basis data yang ada.
```
app=> CREATE EXTENSION pgactive;
```
1. Bergabunglah dengan kedua PostgreSQL ke grup dengan cara yang lebih aman menggunakan perintah berikut: `pgactive`
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Gunakan perintah berikut sebagai metode alternatif tetapi kurang aman untuk bergabung dengan ke grup `pgactive`
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app adalah nama yang Anda tetapkan untuk mengidentifikasi simpul secara unik dalam grup `pgactive`.
1. Untuk memeriksa apakah instans DB sudah siap, gunakan perintah berikut ini:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Jika perintah berhasil, Anda dapat melihat output sebagai berikut:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Jika basis data RDS for PostgreSQL pertama relatif besar, Anda dapat melihat `pgactive.pgactive_wait_for_node_ready()` yang merilis laporan kemajuan operasi pemulihan. Output akan terlihat serupa dengan yang berikut ini:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Dari titik ini ke depan, `pgactive` menyinkronkan data antara dua instans DB.
1. Anda dapat menggunakan perintah berikut untuk memverifikasi apakah basis data instans DB kedua memiliki data:
```
app=> SELECT count(*) FROM inventory.products;
```
Jika data berhasil disinkronkan, Anda akan melihat output sebagai berikut:
```
count
-------
3
```
1. Jalankan perintah berikut ini untuk memasukkan nilai baru:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Hubungkan ke basis data instans DB pertama dan jalankan kueri berikut:
```
app=> SELECT count(*) FROM inventory.products;
```
Jika replikasi aktif-aktif diinisialisasi, output serupa dengan berikut ini:
```
count
-------
4
```
**Melepas dan menghapus instans DB dari grup `pgactive`**
Anda dapat melepas dan menghapus instans DB dari grup `pgactive` menggunakan langkah-langkah berikut:
1. Anda dapat melepas instans DB kedua dari instans DB pertama menggunakan perintah berikut:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Menghapus ekstensi `pgactive` dari instans DB kedua menggunakan perintah berikut:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
Untuk menghapus ekstensi secara paksa:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Hapus sementara ekstensi menggunakan perintah berikut ini:
```
app=> DROP EXTENSION pgactive;
```
# Mengukur lag replikasi di antara anggota pgactive
Anda dapat menggunakan kueri berikut untuk melihat lag replikasi di antara `pgactive` anggota. Jalankan kueri ini di setiap `pgactive` node untuk mendapatkan gambaran lengkap.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Pantau diagnostik berikut minimal:
aktif
Siapkan peringatan saat aktif salah, yang menunjukkan bahwa slot saat ini tidak digunakan (instance pelanggan telah terputus dari penerbit).
pending\$1wal\$1decoding
Dalam replikasi logis PostgreSQL, file WAL disimpan dalam format biner. Penerbit harus memecahkan kode perubahan WAL ini dan mengubahnya menjadi perubahan logis (seperti menyisipkan, memperbarui, atau menghapus operasi).
Metrik pending\$1wal\$1decoding menunjukkan jumlah file WAL yang menunggu untuk didekodekan di sisi penerbit.
Jumlah ini dapat meningkat karena faktor-faktor ini:
+ Ketika pelanggan tidak terhubung, status aktif akan salah dan pending\$1wal\$1decoding akan meningkat
+ Slot aktif, tetapi penerbit tidak dapat mengikuti volume perubahan WAL
pending\$1wal\$1to\$1apply
Metrik pending\$1wal\$1apply menunjukkan jumlah file WAL yang menunggu untuk diterapkan di sisi pelanggan.
Beberapa faktor dapat mencegah pelanggan menerapkan perubahan dan berpotensi menyebabkan skenario penuh disk:
+ Perbedaan skema - misalnya, ketika Anda memiliki perubahan dalam aliran WAL untuk tabel bernama sampel, tetapi tabel itu tidak ada di sisi pelanggan
+ Nilai di kolom kunci primer diperbarui
+ Indeks unik sekunder dapat menyebabkan divergensi data
# Mengkonfigurasi pengaturan parameter untuk ekstensi pgactive
Anda dapat menggunakan kueri berikut untuk melihat semua parameter yang terkait dengan ekstensi `pgactive`.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Anda dapat mengkonfigurasi `pgactive` ekstensi menggunakan berbagai parameter. Parameter ini dapat diatur melalui antarmuka Konsol Manajemen AWS atau AWS CLI.
## Parameter ekstensi pgactive utama
Tabel berikut memberikan referensi untuk parameter utama `pgactive` ekstensi:
| Parameter | Unit | Default | Deskripsi |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Log informasi Tuple lengkap untuk `pgactive` ekstensi. Restart server diperlukan agar perubahan diterapkan. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Menentukan apakah `pgactive` ekstensi mencatat konflik yang terdeteksi ke `pgactive.pgactive_conflict_history` tabel. Untuk informasi selengkapnya, lihat Pencatatan konflik untuk detailnya. Restart server diperlukan agar perubahan diterapkan. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Menentukan apakah `pgactive` ekstensi mencatat konflik yang terdeteksi ke file log PostgreSQL. Untuk informasi selengkapnya, lihat Pencatatan konflik untuk detailnya. Restart server diperlukan agar perubahan diterapkan. |
| pgactive.synchronous\$1commit | `boolean` | off | Menentukan perilaku komit untuk pekerja terapan pgactive. Saat dinonaktifkan (tidak aktif), pekerja terapkan melakukan komit asinkron, yang meningkatkan throughput PostgreSQL selama operasi penerapan tetapi menunda konfirmasi pemutaran ulang ke hulu. Mengaturnya `off` selalu aman dan tidak akan menyebabkan kerugian transaksi atau lompatan. Pengaturan ini hanya memengaruhi waktu pembilasan disk pada node hilir dan saat konfirmasi dikirim ke hulu. Sistem menunda pengiriman konfirmasi pemutaran ulang hingga komit dibuang ke disk melalui operasi yang tidak terkait seperti pos pemeriksaan atau pekerjaan berkala. Namun, jika bagian hulu memiliki hilir yang terdaftar`synchronous_standby_names`, menyetelnya untuk `off` menyebabkan komit sinkron di hulu membutuhkan waktu lebih lama untuk melaporkan keberhasilan kepada klien. Dalam hal ini, atur parameter ke`on`. Bahkan ketika parameter ini disetel ke `on` dengan node yang terdaftar di`synchronous_standby_names`, konflik replikasi masih dapat terjadi dalam konfigurasi aktif-aktif. Ini karena sistem tidak memiliki penguncian antar simpul dan manajemen snapshot global, memungkinkan transaksi bersamaan pada node yang berbeda untuk memodifikasi tuple yang sama. Selain itu, transaksi hanya memulai replikasi setelah melakukan pada node hulu. Mengaktifkan komit sinkron tidak mengubah ekstensi pgactive menjadi sistem yang selalu konsisten. |
| pgactive.temp\$1dump\$1directory | `string` | – | Mendefinisikan jalur penyimpanan sementara yang diperlukan untuk operasi kloning database selama penyiapan awal. Direktori ini harus dapat ditulis oleh pengguna postgres dan memiliki ruang penyimpanan yang cukup untuk berisi dump database lengkap. Sistem menggunakan lokasi ini hanya selama pengaturan database awal dengan operasi salinan logis. Parameter ini tidak digunakan oleh file`pgactive_init_copy command`. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Menentukan waktu tunggu maksimum untuk kunci DDL sebelum secara paksa membatalkan transaksi tulis bersamaan. Nilai defaultnya adalah`-1`, yang mengadopsi nilai yang ditetapkan. `max_standby_streaming_delay` Parameter ini menerima satuan waktu. Misalnya, Anda dapat mengaturnya ke 10 detik selama 10 detik. Selama periode tunggu ini, sistem mencoba untuk memperoleh kunci DDL sambil menunggu transaksi tulis yang sedang berlangsung untuk melakukan atau memutar kembali. Untuk informasi lebih lanjut, lihat Penguncian DDL. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Menentukan berapa lama upaya kunci DDL menunggu untuk mendapatkan kunci. Nilai default adalah`-1`, yang menggunakan nilai yang ditentukan dalam lock\$1timeout. Anda dapat mengatur parameter ini menggunakan satuan waktu seperti 10 detik selama 10 detik. Timer ini hanya mengontrol masa tunggu untuk mendapatkan kunci DDL. Setelah sistem mendapatkan kunci dan memulai operasi DDL, timer berhenti. Parameter ini tidak membatasi durasi total kunci DDL dapat ditahan atau waktu operasi DDL keseluruhan. Untuk mengontrol total durasi operasi, gunakan `statement_timeout` sebagai gantinya. Untuk informasi lebih lanjut, lihat Penguncian DDL. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Mengganti level log debug default untuk operasi penguncian DDL di ekstensi. `pgactive` Saat dikonfigurasi, pengaturan ini menyebabkan pesan terkait penguncian DDL dipancarkan pada tingkat debug LOG, bukan tingkat defaultnya. Gunakan parameter ini untuk memantau aktivitas penguncian DDL tanpa mengaktifkan tingkat verbose `DEBUG1` atau `DEBUG2` log di seluruh server Anda. Level log yang tersedia, dalam urutan verbositas yang meningkat: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Untuk informasi selengkapnya tentang opsi pemantauan, lihat Memantau kunci DDL global. Perubahan pada setelan ini berlaku saat Anda memuat ulang konfigurasi. Anda tidak perlu me-restart server. |
## Parameter ekstensi pgactive tambahan
Tabel berikut menyajikan opsi konfigurasi internal yang lebih jarang digunakan dan tersedia untuk `pgactive` ekstensi.
| Parameter | Unit | Default | Deskripsi |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Menetapkan penundaan penerapan (dalam milidetik) untuk koneksi yang dikonfigurasi yang tidak memiliki penundaan penerapan eksplisit dalam entri mereka`pgactive.pgactive_connections`. Penundaan ini diatur selama pembuatan node atau waktu bergabung, dan pgactive tidak akan memutar ulang transaksi pada node rekan sampai setidaknya jumlah milidetik yang ditentukan telah berlalu sejak dilakukan. Terutama digunakan untuk mensimulasikan jaringan latensi tinggi di lingkungan pengujian untuk membuatnya lebih mudah untuk menciptakan konflik. Misalnya, dengan penundaan 500 ms pada node A dan B, Anda memiliki setidaknya 500 ms untuk melakukan penyisipan yang bertentangan pada node B setelah memasukkan nilai pada node A. Memerlukan server memuat ulang atau memulai ulang pekerja terapan agar berlaku. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Menentukan durasi (dalam detik) bahwa pekerja database mencoba untuk membuat koneksi selama upaya gagal. Pekerja membuat satu upaya koneksi per detik hingga berhasil atau mencapai nilai batas waktu ini. Pengaturan ini berguna ketika mesin database dimulai sebelum pekerja siap untuk membuat koneksi. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Mengontrol bagaimana perubahan DDL direplikasi atau ditangani di Amazon RDS dengan diaktifkan. `pgactive` Ketika diatur ke`on`, node memproses perubahan DDL seperti node non-pgcctive. Persyaratan berikut berlaku saat bekerja dengan parameter ini: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Anda dapat memodifikasi parameter ini dengan dua cara dengan hak istimewa pengguna super: secara global, lokal (tingkat sesi). Mengubah parameter ini secara tidak benar dapat merusak pengaturan replikasi Anda. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Parameter ini hanya untuk penggunaan internal. Ketika Anda mengatur parameter ini dalam transaksi, perubahan tidak direplikasi ke node lain di cluster DB Anda. Mengubah parameter ini secara tidak benar dapat merusak pengaturan replikasi Anda. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Parameter ini ditujukan hanya untuk penggunaan spesialis. Sebaiknya gunakan parameter ini hanya saat memecahkan masalah replikasi tertentu. Gunakan parameter ini ketika: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Pengaturan ini mengesampingkan pesan kesalahan berikut dan memungkinkan divergensi data muncul agar replikasi berlanjut: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Mengubah parameter ini secara tidak benar dapat merusak pengaturan replikasi Anda. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Ketika diatur ke`on`, itu memancarkan pesan log untuk setiap tindakan jarak jauh yang menerapkan proses pekerja di hilir. Log meliputi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Log juga menangkap perintah DDL yang diantrian dan tetesan tabel.para> Secara default, log tidak menyertakan isi bidang baris. Untuk menyertakan nilai baris dalam log, Anda harus mengkompilasi ulang dengan flag berikut diaktifkan: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Mengaktifkan pengaturan logging ini dapat memengaruhi kinerja. Kami menyarankan untuk mengaktifkannya hanya bila diperlukan untuk pemecahan masalah. Perubahan pada pengaturan ini berlaku saat Anda memuat ulang konfigurasi. Anda tidak perlu me-restart server. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Anda dapat mengonfigurasi parameter koneksi untuk semua koneksi node peer dengan node pgactive. Parameter ini mengontrol pengaturan seperti keepalives dan mode SSL. Secara default, pgactive menggunakan parameter koneksi berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Untuk mengganti parameter default, gunakan perintah serupa berikut: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' String koneksi node individual lebih diutamakan daripada pengaturan ini dan opsi koneksi bawaan pgactive. Untuk informasi selengkapnya tentang format string koneksi, lihat string koneksi [libpq](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Sebaiknya tetap mengaktifkan pengaturan keepalive default. Hanya nonaktifkan keepalives jika Anda mengalami masalah dengan transaksi besar yang diselesaikan melalui jaringan yang tidak dapat diandalkan. Sebaiknya tetap mengaktifkan pengaturan keepalive default. Hanya nonaktifkan keepalives jika Anda mengalami masalah dengan transaksi besar yang diselesaikan melalui jaringan yang tidak dapat diandalkan. Perubahan pada pengaturan ini berlaku saat Anda memuat ulang konfigurasi. Anda tidak perlu me-restart server. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Menentukan jumlah pekerjaan paralel yang `pg_dump` dan `pg_restore` dapat digunakan selama node logis bergabung dengan fungsi. `pgactive.pgactive_join_group` Perubahan pada pengaturan ini berlaku saat Anda memuat ulang konfigurasi. Anda tidak perlu me-restart server. |
| pgactive.max\$1nodes | `int` | 4 | Menentukan jumlah maksimum node yang diizinkan dalam grup ekstensi pgactive. Nilai defaultnya adalah 4 node. Anda harus mempertimbangkan hal berikut saat mengatur nilai parameter ini: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Anda dapat mengatur parameter ini dengan dua cara: dalam file konfigurasi, menggunakan `ALTER SYSTEM SET` perintah Nilai default untuk parameter ini adalah`4`, artinya, bisa ada maksimal 4 node yang diizinkan dalam grup `pgactive` ekstensi pada setiap titik waktu. Perubahan berlaku setelah Anda me-restart server. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Parameter ini ditujukan untuk penggunaan internal saja. Saat diaktifkan, `pgactive` ekstensi memungkinkan pembuatan fungsi pengenal node pgactive. |
# Memahami konflik aktif-aktif
Saat Anda menggunakan pgactive dalam mode aktif-aktif, menulis ke tabel yang sama dari beberapa node dapat membuat konflik data. Sementara beberapa sistem pengelompokan menggunakan kunci terdistribusi untuk mencegah akses bersamaan, pgactive mengambil pendekatan optimis yang lebih cocok untuk aplikasi yang didistribusikan secara geografis.
Beberapa sistem pengelompokan database mencegah akses data bersamaan dengan menggunakan kunci terdistribusi. Meskipun pendekatan ini bekerja ketika server berada dalam jarak dekat, itu tidak mendukung aplikasi yang didistribusikan secara geografis karena memerlukan latensi yang sangat rendah untuk kinerja yang baik. Alih-alih menggunakan kunci terdistribusi (pendekatan pesimis), ekstensi pgactive menggunakan pendekatan optimis. Ini berarti:
+ Membantu Anda menghindari konflik jika memungkinkan.
+ Memungkinkan jenis konflik tertentu terjadi.
+ Memberikan resolusi konflik ketika konflik terjadi.
Pendekatan ini memberi Anda lebih banyak fleksibilitas saat membangun aplikasi terdistribusi.
## Bagaimana konflik terjadi
Konflik antar node muncul dari urutan peristiwa yang tidak dapat terjadi jika semua transaksi yang terlibat terjadi secara bersamaan pada node yang sama. Karena node hanya bertukar perubahan setelah transaksi dilakukan, setiap transaksi valid secara individual pada node yang dilakukannya tetapi tidak akan valid jika dijalankan pada node lain yang telah melakukan pekerjaan lain sementara itu. Karena pgactive apply pada dasarnya memutar ulang transaksi pada node lain, operasi replay dapat gagal jika ada konflik antara transaksi yang diterapkan dan transaksi yang dilakukan pada node penerima.
Alasan sebagian besar konflik tidak dapat terjadi ketika semua transaksi berjalan pada satu node adalah karena PostgreSQL memiliki mekanisme komunikasi antar-transaksi untuk mencegahnya, termasuk:
+ Indeks UNIK
+ SEQUENCEs
+ Penguncian baris dan relasi
+ Pelacakan ketergantungan SERIALIZABLE
Semua mekanisme ini adalah cara untuk berkomunikasi antar transaksi untuk mencegah masalah konkurensi yang tidak diinginkan
pgactive mencapai latensi rendah dan menangani partisi jaringan dengan baik karena tidak menggunakan manajer transaksi terdistribusi atau pengelola kunci. Namun, ini berarti transaksi pada node yang berbeda berjalan dalam isolasi lengkap satu sama lain. Sementara isolasi biasanya meningkatkan konsistensi database, dalam hal ini, Anda perlu mengurangi isolasi untuk mencegah konflik.
## Jenis konflik
Konflik yang dapat terjadi meliputi:
**Topics**
+ [KUNCI PRIMER atau konflik UNIK](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [Konflik INSERT/INSERT](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [INSERTs yang melanggar beberapa kendala UNIK](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [Konflik PEMBARUIAN/PEMBARUAN](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [PERBARUI konflik pada KUNCI PRIMARY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [UPDATEs yang melanggar beberapa kendala UNIK](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [PERBARUI/HAPUS konflik](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [Konflik INSERT/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [HAPUS/HAPUS konflik](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [Konflik Kendala Kunci Asing](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [Konflik kendala pengecualian](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [Konflik data global](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [Mengunci konflik dan kebuntuan dibatalkan](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [Konflik yang berbeda](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### KUNCI PRIMER atau konflik UNIK
Konflik baris terjadi ketika beberapa operasi mencoba memodifikasi kunci baris yang sama dengan cara yang tidak mungkin dilakukan pada satu node. Konflik ini mewakili jenis konflik data yang paling umum.
pgactive menyelesaikan konflik yang terdeteksi melalui last-update-wins penanganan atau penangan konflik kustom Anda.
Konflik baris meliputi:
+ SISIPKAN vs SISIPKAN
+ SISIPKAN vs PEMBARUAN
+ PEMBARUAN vs HAPUS
+ SISIPKAN vs HAPUS
+ HAPUS vs HAPUS
+ SISIPKAN vs HAPUS
### Konflik INSERT/INSERT
Konflik yang paling umum ini terjadi ketika INSERTs pada dua node yang berbeda membuat tupel dengan nilai KUNCI PRIMARY yang sama (atau nilai kendala UNIK identik ketika tidak ada KUNCI PRIMARY).
pgactivelink menyelesaikan konflik INSERT dengan menggunakan stempel waktu dari host asal untuk mempertahankan tupel terbaru. Anda dapat mengganti perilaku default ini dengan penangan konflik kustom Anda. Meskipun proses ini tidak memerlukan tindakan administrator khusus, ketahuilah bahwa pgactivelink membuang salah satu operasi INSERT di semua node. Tidak ada penggabungan data otomatis yang terjadi kecuali handler kustom Anda mengimplementasikannya.
Pgactivelink hanya dapat menyelesaikan konflik yang melibatkan pelanggaran kendala tunggal. Jika INSERT melanggar beberapa kendala UNIK, Anda harus menerapkan strategi penyelesaian konflik tambahan.
### INSERTs yang melanggar beberapa kendala UNIK
INSERT/INSERT Konflik dapat melanggar beberapa kendala UNIK, termasuk KUNCI PRIMAR. pgactivelink hanya dapat menangani konflik yang melibatkan satu kendala UNIK. Ketika konflik melanggar beberapa kendala UNIK, pekerja penerapan gagal dan mengembalikan kesalahan berikut:
`multiple unique constraints violated by remotely INSERTed tuple.`
Dalam versi yang lebih lama, situasi ini menghasilkan kesalahan 'konflik keunikan yang menyimpang' sebagai gantinya.
Untuk mengatasi konflik ini, Anda harus mengambil tindakan manual. Baik HAPUS tupel lokal yang bertentangan atau PERBARUI untuk menghapus konflik dengan tupel jarak jauh yang baru. Ketahuilah bahwa Anda mungkin perlu mengatasi beberapa tupel yang saling bertentangan. Saat ini, pgactivelink tidak menyediakan fungsionalitas bawaan untuk mengabaikan, membuang, atau menggabungkan tupel yang melanggar beberapa kendala unik.
**catatan**
Untuk informasi selengkapnya, lihat UPDATEs bahwa melanggar beberapa kendala UNIK.
### Konflik PEMBARUIAN/PEMBARUAN
Konflik ini terjadi ketika dua node secara bersamaan memodifikasi Tuple yang sama tanpa mengubah KUNCI PRIMAR-nya. pgactivelink menyelesaikan konflik ini menggunakan last-update-wins logika atau penangan konflik kustom Anda, jika ditentukan. KUNCI UTAMA sangat penting untuk pencocokan tupel dan resolusi konflik. Untuk tabel tanpa KUNCI UTAMA, pgactivelink menolak operasi UPDATE dengan kesalahan berikut:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### PERBARUI konflik pada KUNCI PRIMARY
pgactive memiliki batasan saat menangani pembaruan PRIMARY KEY. Meskipun Anda dapat melakukan operasi UPDATE pada KUNCI UTAMA, pgactive tidak dapat secara otomatis menyelesaikan konflik menggunakan last-update-wins logika untuk operasi ini. Anda harus memastikan bahwa pembaruan PRIMARY KEY Anda tidak bertentangan dengan nilai yang ada. Jika konflik terjadi selama pembaruan PRIMARY KEY, konflik tersebut menjadi konflik yang berbeda yang memerlukan intervensi manual Anda. Untuk informasi selengkapnya tentang penanganan situasi ini, lihat[Konflik yang berbeda](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATEs yang melanggar beberapa kendala UNIK
pgactivelink tidak dapat menerapkan resolusi last-update-wins konflik ketika UPDATE yang masuk melanggar beberapa batasan UNIK atau nilai KUNCI UTAMA. Perilaku ini mirip dengan operasi INSERT dengan beberapa pelanggaran kendala. Situasi ini menciptakan konflik yang berbeda yang memerlukan intervensi manual Anda. Untuk informasi selengkapnya, lihat [Konflik yang berbeda](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### PERBARUI/HAPUS konflik
Konflik ini terjadi ketika UPDATEs satu node baris sementara node lain DELETEs secara bersamaan. Dalam hal ini terjadi UPDATE/DELETE konflik pada pemutaran ulang. Resolusinya adalah membuang PEMBARUAN apa pun yang tiba setelah DELETE, kecuali penangan konflik kustom Anda menentukan sebaliknya.
pgactivelink membutuhkan KUNCI UTAMA untuk mencocokkan tupel dan menyelesaikan konflik. Untuk tabel tanpa KUNCI PRIMARY, ia menolak operasi DELETE dengan kesalahan berikut:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**catatan**
pgactivelink tidak dapat membedakan antara dan konflik. UPDATE/DELETE INSERT/UPDATE Dalam kedua kasus, UPDATE mempengaruhi baris yang tidak ada. Karena replikasi asinkron dan kurangnya urutan pemutaran ulang antar node, pgactivelink tidak dapat menentukan apakah PEMBARUAN adalah untuk baris baru (INSERT belum diterima) atau baris yang dihapus. Dalam kedua skenario, pgactivelink membuang UPDATE.
### Konflik INSERT/UPDATE
Konflik ini dapat terjadi di lingkungan multi-node. Itu terjadi ketika INSERTs satu node baris, node kedua UPDATEs itu, dan node ketiga menerima UPDATE sebelum INSERT asli. Secara default, pgactivelink menyelesaikan konflik ini dengan membuang UPDATE, kecuali pemicu konflik kustom Anda menentukan sebaliknya. Ketahuilah bahwa metode resolusi ini dapat mengakibatkan inkonsistensi data di seluruh node. Untuk informasi selengkapnya tentang skenario serupa dan penanganannya, lihat[PERBARUI/HAPUS konflik](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### HAPUS/HAPUS konflik
Konflik ini terjadi ketika dua node berbeda secara bersamaan menghapus tuple yang sama. pgactivelink menganggap konflik ini tidak berbahaya karena kedua operasi DELETE memiliki hasil akhir yang sama. Dalam skenario ini, pgactivelink dengan aman mengabaikan salah satu operasi DELETE tanpa mempengaruhi konsistensi data.
### Konflik Kendala Kunci Asing
Kendala KUNCI ASING dapat menyebabkan konflik saat menerapkan transaksi jarak jauh ke data lokal yang ada. Konflik ini biasanya terjadi ketika transaksi diterapkan dalam urutan yang berbeda dari urutan logisnya pada node asal.
Secara default, pgactive menerapkan perubahan dengan session\$1replication\$1role as`replica`, yang melewati pemeriksaan kunci asing selama replikasi. Dalam konfigurasi aktif-aktif, ini dapat menyebabkan pelanggaran kunci asing. Sebagian besar pelanggaran bersifat sementara dan diselesaikan setelah replikasi menyusul. Namun, kunci asing yang menggantung dapat terjadi karena pgactive tidak mendukung penguncian baris lintas-simpul.
Perilaku ini melekat pada sistem aktif-aktif asinkron yang toleran partisi. Misalnya, node A mungkin menyisipkan baris anak baru sementara node B secara bersamaan menghapus baris induknya. Sistem tidak dapat mencegah jenis modifikasi bersamaan di seluruh node.
Untuk meminimalkan konflik kunci asing, kami merekomendasikan hal berikut:
+ Batasi hubungan kunci asing ke entitas yang terkait erat.
+ Ubah entitas terkait dari satu node bila memungkinkan.
+ Pilih entitas yang jarang membutuhkan modifikasi.
+ Menerapkan kontrol konkurensi tingkat aplikasi untuk modifikasi.
### Konflik kendala pengecualian
tautan pgactive tidak mendukung batasan pengecualian dan membatasi pembuatannya.
**catatan**
Jika Anda mengonversi database mandiri yang ada ke database pgactivelink, jatuhkan semua batasan pengecualian secara manual.
Dalam sistem asinkron terdistribusi, tidak mungkin untuk menjamin bahwa tidak ada kumpulan baris yang melanggar batasan. Ini karena semua transaksi pada node yang berbeda sepenuhnya terisolasi. Kendala pengecualian dapat menyebabkan kebuntuan pemutaran ulang, di mana pemutaran ulang tidak dapat berkembang dari node mana pun ke node lain karena pelanggaran batasan pengecualian.
Jika Anda memaksa pgactive Link untuk membuat batasan pengecualian, atau jika Anda tidak menghapus yang sudah ada saat mengonversi database mandiri menjadi pgactive Link, replikasi kemungkinan akan rusak. Untuk mengembalikan kemajuan replikasi, hapus atau ubah tupel lokal yang bertentangan dengan tupel jarak jauh yang masuk sehingga transaksi jarak jauh dapat diterapkan.
### Konflik data global
Saat menggunakan pgactivelink, konflik dapat terjadi ketika node memiliki data seluruh sistem PostgreSQL global yang berbeda, seperti peran. Konflik ini dapat menyebabkan operasi—terutama DDL—berhasil dan berkomitmen pada satu node tetapi gagal diterapkan ke node lain.
Jika pengguna ada di satu node tetapi tidak yang lain, masalah replikasi dapat terjadi:
+ Node1 memiliki nama pengguna`fred`, tetapi pengguna ini tidak ada di Node2
+ Saat `fred` membuat tabel di Node1, tabel direplikasi dengan `fred` sebagai pemilik
+ Ketika perintah DDL ini diterapkan ke Node2, itu gagal karena pengguna `fred` tidak ada
+ Kegagalan ini menghasilkan ERROR di log PostgreSQL di Node2 dan menambah penghitung `pgactive.pgactive_stats.nr_rollbacks`
**Resolusi:** Buat pengguna `fred` di Node2. Pengguna tidak memerlukan izin yang identik tetapi harus ada di kedua node.
Jika tabel ada pada satu node tetapi tidak yang lain, operasi modifikasi data akan gagal:
+ Node1 memiliki tabel bernama `foo` yang tidak ada di Node2
+ Setiap operasi DHTML pada `foo` tabel pada Node1 akan gagal ketika direplikasi ke Node2
**Resolusi:** Buat tabel `foo` di Node2 dengan struktur yang sama.
**catatan**
pgactivelink saat ini tidak mereplikasi perintah CREATE USER atau operasi DDL. Replikasi DDL direncanakan untuk rilis future.
### Mengunci konflik dan kebuntuan dibatalkan
Karena proses penerapan pgactive beroperasi seperti sesi pengguna normal, mereka mengikuti aturan penguncian baris dan tabel standar. Hal ini dapat mengakibatkan pgactivelink menerapkan proses menunggu pada kunci yang dipegang oleh transaksi pengguna atau oleh proses penerapan lainnya.
Jenis kunci berikut dapat memengaruhi proses penerapan:
+ Penguncian tingkat tabel eksplisit (LOCK TABLE...) oleh sesi pengguna
+ Penguncian tingkat baris eksplisit (PILIH... UNTUK UPDATE/FOR BERBAGI) oleh sesi pengguna
+ Mengunci dari kunci asing
+ Penguncian implisit karena baris UPDATEs, INSERTs, atau DELETEs, baik dari aktivitas lokal atau berlaku dari server lain
Kebuntuan dapat terjadi antara:
+ Proses penerapan pgactivelink dan transaksi pengguna
+ Dua menerapkan proses
Ketika kebuntuan terjadi, detektor kebuntuan PostgreSQL mengakhiri salah satu transaksi masalah. Jika proses pgactivelink apply worker dihentikan, proses tersebut secara otomatis mencoba ulang dan biasanya berhasil.
**catatan**
Masalah ini bersifat sementara dan umumnya tidak memerlukan intervensi administrator. Jika proses penerapan diblokir untuk jangka waktu yang lama dengan mengunci sesi pengguna yang tidak aktif, Anda dapat menghentikan sesi pengguna untuk melanjutkan replikasi. Situasi ini mirip dengan ketika pengguna memegang kunci panjang yang memengaruhi sesi pengguna lain.
Untuk mengidentifikasi penundaan pemutaran ulang terkait penguncian, aktifkan fasilitas `log_lock_waits` di PostgreSQL.
### Konflik yang berbeda
Konflik divergen terjadi ketika data yang seharusnya identik di seluruh node berbeda secara tak terduga. Meskipun konflik ini seharusnya tidak terjadi, tidak semua dapat dicegah dengan andal dalam implementasi saat ini.
**catatan**
Memodifikasi KUNCI UTAMA baris dapat menyebabkan konflik yang berbeda jika node lain mengubah kunci baris yang sama sebelum semua node memproses perubahan. Hindari mengubah kunci utama, atau membatasi perubahan pada satu node yang ditunjuk. Untuk informasi selengkapnya, lihat [PERBARUI konflik pada KUNCI PRIMARY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Konflik divergen yang melibatkan data baris biasanya memerlukan intervensi administrator. Untuk mengatasi konflik ini, Anda harus menyesuaikan data secara manual pada satu node agar sesuai dengan yang lain sambil menonaktifkan replikasi sementara menggunakan. `pgactive.pgactive_do_not_replicate` Konflik ini seharusnya tidak terjadi ketika Anda menggunakan pgactive seperti yang didokumentasikan dan menghindari pengaturan atau fungsi yang ditandai sebagai tidak aman.
Sebagai administrator, Anda harus menyelesaikan konflik ini secara manual. Bergantung pada jenis konflik, Anda harus menggunakan opsi lanjutan seperti`pgactive.pgactive_do_not_replicate`. Gunakan opsi ini dengan hati-hati, karena penggunaan yang tidak tepat dapat memperburuk situasi. Karena berbagai kemungkinan konflik, kami tidak dapat memberikan instruksi resolusi universal.
Konflik divergen terjadi ketika data yang seharusnya identik di seluruh node yang berbeda secara tak terduga berbeda. Meskipun konflik ini seharusnya tidak terjadi, tidak semua konflik semacam itu dapat dicegah dengan andal dalam implementasi saat ini.
## Menghindari atau mentolerir konflik
Dalam kebanyakan kasus, Anda dapat menggunakan desain aplikasi yang sesuai untuk menghindari konflik atau membuat aplikasi Anda toleran terhadap konflik.
Konflik hanya terjadi ketika operasi simultan terjadi pada beberapa node. Untuk menghindari konflik:
+ Menulis hanya ke satu simpul
+ Menulis ke subset database independen pada setiap node (misalnya, menetapkan setiap node skema terpisah)
Untuk konflik INSERT vs INSERT, gunakan urutan Global untuk mencegah konflik sepenuhnya.
Jika konflik tidak dapat diterima untuk kasus penggunaan Anda, pertimbangkan untuk menerapkan penguncian terdistribusi di tingkat aplikasi. Seringkali, pendekatan terbaik adalah merancang aplikasi Anda untuk bekerja dengan mekanisme resolusi konflik pgactive daripada mencoba mencegah semua konflik. Untuk informasi selengkapnya, lihat [Jenis konflik](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Penebangan konflik
pgactivelink mencatat insiden konflik dalam `pgactive.pgactive_conflict_history` tabel untuk membantu Anda mendiagnosis dan menangani konflik aktif-aktif. Pencatatan konflik ke tabel ini hanya terjadi ketika Anda menyetel `pgactive.log_conflicts_to_table` ke true. Ekstensi pgactive juga mencatat konflik ke file log PostgreSQL saat log\$1min\$1messages disetel ke atau, terlepas dari pengaturannya. `LOG` `lower` `pgactive.log_conflicts_to_table`
Gunakan tabel riwayat konflik untuk:
+ Ukur seberapa sering aplikasi Anda membuat konflik
+ Identifikasi di mana konflik terjadi
+ Tingkatkan aplikasi Anda untuk mengurangi tingkat konflik
+ Mendeteksi kasus di mana resolusi konflik tidak menghasilkan hasil yang diinginkan
+ Tentukan di mana Anda memerlukan pemicu konflik yang ditentukan pengguna atau perubahan desain aplikasi
Untuk konflik baris, Anda dapat mencatat nilai baris secara opsional. Ini dikendalikan oleh `pgactive.log_conflicts_to_table` pengaturan. Perhatikan bahwa:
+ Ini adalah opsi seluruh basis data global
+ Tidak ada kontrol per tabel atas pencatatan nilai baris
+ Tidak ada batasan yang diterapkan pada nomor bidang, elemen array, atau panjang bidang
+ Mengaktifkan fitur ini mungkin tidak disarankan jika Anda bekerja dengan baris multi-megabyte yang dapat memicu konflik
Karena tabel riwayat konflik berisi data dari setiap tabel dalam database (masing-masing dengan skema yang berpotensi berbeda), nilai baris yang dicatat disimpan sebagai bidang JSON. JSON dibuat menggunakan`row_to_json`, mirip dengan memanggilnya langsung dari SQL. PostgreSQL tidak menyediakan `json_to_row` fungsi, jadi Anda memerlukan kode khusus tabel (PL/pgSQL, PL/Python, PL/Perlin, dll.) untuk merekonstruksi tupel yang diketik komposit dari JSON yang dicatat.
**catatan**
Support untuk konflik yang ditentukan pengguna direncanakan sebagai fitur ekstensi future.
# Memahami skema pgactive
Skema pgactive mengelola replikasi aktif-aktif dalam RDS untuk PostgreSQL. Skema ini berisi tabel yang menyimpan konfigurasi replikasi dan informasi status.
**catatan**
Skema pgactive berkembang dan dapat berubah. Jangan memodifikasi data dalam tabel ini secara langsung.
Tabel kunci dalam skema pgactive meliputi:
+ `pgactive_nodes`— Menyimpan informasi tentang node dalam grup replikasi aktif-aktif.
+ `pgactive_connections`— Menyimpan detail koneksi untuk setiap node.
## pgactive\$1nodes
Pgactive\$1nodes menyimpan informasi tentang node yang berpartisipasi dalam grup replikasi aktif-aktif.
| Kolom | Tipe | Kolasi | Nullable | Default |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | tidak null | – |
| node\$1timeline | oid | – | tidak null | – |
| node\$1dboid | oid | – | tidak null | – |
| node\$1status | char | – | tidak null | – |
| node\$1name | text | – | tidak null | – |
| node\$1dsn | text | – | tidak null | – |
| node\$1init\$1from\$1dsn | text | – | tidak null | – |
| node\$1read\$1only | boolean | – | – | false |
| node\$1seq\$1id | smallint | – | tidak null | – |
**node\$1sysid**
ID unik untuk node, dihasilkan selama `pgactive_create_group` atau `pgactive_join_group`
**node\$1status**
Kesiapan simpul:
+ **b** - pengaturan awal
+ **i** - menginisialisasi
+ **c** - menyusul
+ **o** - membuat slot keluar
+ **r** - siap
+ **k** - terbunuh
Kolom ini tidak menunjukkan apakah node terhubung atau terputus.
**node\$1name**
Nama simpul unik yang disediakan pengguna.
**node\$1dsn**
String koneksi atau nama pemetaan pengguna
**node\$1init\$1from\$1dsn**
DSN dari mana node ini dibuat.
## pgactive\$1connection
Pgactive\$1connections menyimpan detail koneksi untuk setiap node.
| Kolom | Tipe | Kolasi | Nullable | Default |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | none | tidak null | none |
| conn\$1timeline | oid | none | tidak null | none |
| conn\$1dboid | oid | none | tidak null | none |
| conn\$1dsn | text | none | tidak null | none |
| conn\$1apply\$1delay | integer | none | none | none |
| conn\$1replication\$1sets | text | none | none | none |
conn\$1sysid
Node identifier untuk node entri ini mengacu pada.
conn\$1dsn
Sama seperti `node_dsn` pgactive.pgactive\$1nodes.
conn\$1apply\$1delay
Jika diatur, milidetik menunggu sebelum menerapkan setiap transaksi dari node jarak jauh. Terutama untuk debugging. Jika null, default global berlaku.
## Bekerja dengan set replikasi
Set replikasi menentukan tabel mana yang akan disertakan atau dikecualikan dari operasi replikasi. Secara default, semua tabel direplikasi kecuali Anda menentukan sebaliknya menggunakan fungsi berikut:
+ `pgactive_exclude_table_replication_set()`- Tidak termasuk tabel tertentu dari replikasi
+ `pgactive_include_table_replication_set()`- Termasuk tabel tertentu dalam replikasi
**catatan**
Sebelum Anda mengonfigurasi set replikasi, pertimbangkan hal berikut:
Anda dapat mengonfigurasi penyertaan atau pengecualian tabel hanya setelah menjalankan `pgactive_create_group()` tetapi sebelumnya`pgactive_join_group()`.
Setelah Anda menggunakannya`pgactive_exclude_table_replication_set()`, Anda tidak dapat menggunakannya`pgactive_include_table_replication_set()`.
Setelah Anda menggunakannya`pgactive_include_table_replication_set()`, Anda tidak dapat menggunakannya`pgactive_exclude_table_replication_set()`.
Sistem menangani tabel yang baru dibuat secara berbeda berdasarkan konfigurasi awal Anda:
+ Jika Anda mengecualikan tabel: Setiap tabel baru yang dibuat setelah `pgactive_join_group()` secara otomatis disertakan dalam replikasi
+ Jika Anda menyertakan tabel: Setiap tabel baru yang dibuat setelahnya secara otomatis `pgactive_join_group()` dikecualikan dari replikasi.
Untuk melihat konfigurasi set replikasi untuk tabel tertentu, gunakan `pgactive.pgactive_get_table_replication_sets()` fungsi.
# referensi fungsi pgactive
Berikut ini, Anda dapat menemukan daftar fungsi pgactive dengan parameternya, nilai pengembalian, dan catatan penggunaan praktis untuk membantu Anda menggunakannya secara efektif:
## get\$1last\$1applied\$1xact\$1info
Mengambil informasi transaksi yang diterapkan terakhir untuk node tertentu.
**Argumen**
+ sysid (teks) - garis waktu OID
+ dboid (OID)
**Jenis pengembalian**
Ini mencatat yang berikut:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (stempel waktu dengan zona waktu)
+ last\$1applied\$1xact\$1at (stempel waktu dengan zona waktu)
**Catatan penggunaan**
Gunakan fungsi ini untuk mengambil informasi transaksi yang diterapkan terakhir untuk node tertentu.
## pgactive\$1apply\$1pause
Menjeda proses penerapan replikasi.
**Argumen**
Tidak ada
**Jenis pengembalian**
boolean
**Catatan penggunaan**
Panggil fungsi ini untuk menjeda proses penerapan replikasi.
## pgactive\$1apply\$1resume
Melanjutkan proses penerapan replikasi.
**Argumen**
Tidak ada
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Panggil fungsi ini untuk melanjutkan proses penerapan replikasi.
## pgactive\$1is\$1apply\$1paused
Memeriksa apakah replikasi berlaku saat ini dijeda.
**Argumen**
Tidak ada
**Jenis pengembalian**
boolean
**Catatan penggunaan**
Gunakan fungsi ini untuk memeriksa apakah replikasi berlaku saat ini dijeda.
## pgactive\$1create\$1group
Membuat grup pgactive dengan mengubah database mandiri menjadi node awal.
**Argumen**
+ node\$1name (teks)
+ node\$1dsn (teks)
+ apply\$1delay integer DEFAULT NULL: :integer - replication\$1sets text [] DEFAULT ARRAY ['default': :text]
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Membuat grup pgactive dengan mengubah database mandiri menjadi node awal. Fungsi melakukan pemeriksaan kewarasan sebelum mengubah node menjadi node pgactive. Sebelum menggunakan fungsi ini, pastikan klaster PostgreSQL Anda memiliki `max_worker_processes` cukup tersedia untuk mendukung pekerja latar belakang pgactive.
## pgactive\$1detach\$1nodes
Menghapus node tertentu dari grup pgactive.
**Argumen**
+ p\$1nodes (teks [])
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Gunakan fungsi ini untuk menghapus node tertentu dari grup pgactive.
## pgactive\$1exclude\$1table\$1replication\$1set
Tidak termasuk tabel tertentu dari replikasi.
**Argumen**
+ p\$1relation (regclass)
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Gunakan fungsi ini untuk mengecualikan tabel tertentu dari replikasi.
## pgactive\$1get\$1replication\$1lag\$1info
Mengambil informasi lag replikasi rinci, termasuk rincian node, status WAL, dan nilai LSN.
**Argumen**
Tidak ada
**Jenis pengembalian**
Rekaman SETOF - teks node\$1name - teks node\$1sysid - teks application\$1name - teks slot\$1name - boolean aktif - integer active\$1pid - pending\$1wal\$1decoding bigint - Perkiraan ukuran WAL dalam byte yang akan diterjemahkan pada node pengirim - pending\$1wal\$1to\$1apply bigint - Perkiraan ukuran WAL dalam byte yang akan diterapkan pada penerimaan simpul - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**Catatan penggunaan**
Panggil fungsi ini untuk mengambil informasi lag replikasi, termasuk detail node, status WAL, dan nilai LSN.
## pgactive\$1get\$1stats
Mengambil statistik replikasi pgaktif.
**Argumen**
Tidak ada
**Jenis pengembalian**
Catatan SETOF - rep\$1node\$1id oid - rilocalid oid - teks riremoteid - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1delete\$1conflict bigint - nr\$1delete bigint - nr\$1deleteet \$1conflict bigint - nr\$1disconnect bigint
**Catatan penggunaan**
Gunakan fungsi ini untuk mengambil statistik replikasi pgactive.
## pgactive\$1get\$1table\$1replication\$1sets
Mendapat konfigurasi set replikasi untuk relasi tertentu.
**Argumen**
+ hubungan (regclass)
**Jenis pengembalian**
Catatan SETOF
**Catatan penggunaan**
Panggil fungsi ini untuk mendapatkan konfigurasi set replikasi untuk relasi tertentu.
## pgactive\$1include\$1table\$1replication\$1set
Termasuk tabel tertentu dalam replikasi.
**Argumen**
+ p\$1relation (regclass)
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Gunakan fungsi ini untuk menyertakan tabel tertentu dalam replikasi.
## pgactive\$1join\$1group
Menambahkan node ke grup pgactive yang ada.
**Argumen**
+ node\$1name (teks)
+ node\$1dsn (teks)
+ join\$1using\$1dsn (teks)
+ apply\$1delay (bilangan bulat, opsional)
+ replication\$1sets (teks [], default: ['default'])
+ bypass\$1collation\$1check (boolean, default: false)
+ bypass\$1node\$1identifier\$1creation (boolean, default: false)
+ bypass\$1user\$1tables\$1check (boolean, default: false)
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Panggil fungsi ini untuk menambahkan node ke grup pgactive yang ada. Pastikan klaster PostgreSQL Anda memiliki max\$1worker\$1processes yang cukup untuk pekerja latar belakang pgactive.
## pgactive\$1remove
Menghapus semua komponen pgactive dari node lokal.
**Argumen**
+ memaksa (boolean, default: false)
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Panggil fungsi ini untuk menghapus semua komponen pgactive dari node lokal.
## pgactive\$1snowflake\$1id\$1nextval
Menghasilkan nilai urutan unik khusus simpul.
**Argumen**
+ regclass
**Jenis pengembalian**
bigint
**Catatan penggunaan**
Gunakan fungsi ini untuk menghasilkan nilai urutan unik khusus simpul.
## pgactive\$1update\$1node\$1conninfo
Memperbarui informasi koneksi untuk node pgactive.
**Argumen**
+ node\$1name\$1to\$1update (teks)
+ node\$1dsn\$1to\$1update (teks)
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Gunakan fungsi ini untuk memperbarui informasi koneksi untuk node pgactive.
## pgactive\$1wait\$1for\$1node\$1ready
Memantau kemajuan pembuatan grup atau bergabung dengan operasi.
**Argumen**
+ batas waktu (bilangan bulat, default: 0)
+ progress\$1interval (bilangan bulat, default: 60)
**Jenis pengembalian**
kosong
**Catatan penggunaan**
Panggil fungsi ini untuk memantau kemajuan pembuatan grup atau bergabung dengan operasi.
# Menangani konflik dalam replikasi aktif-aktif
Ekstensi `pgactive` bekerja per basis data dan bukan per klaster. Setiap instans DB yang menggunakan `pgactive` adalah instans independen dan dapat menerima perubahan data dari sumber apa pun. Ketika perubahan dikirim ke instans DB, PostgreSQL meng-commit perubahan tersebut secara lokal dan kemudian menggunakan `pgactive` untuk mereplikasi perubahan tersebut secara asinkron ke instans DB lainnya. Ketika dua instans DB PostgreSQL memperbarui catatan yang sama pada waktu yang hampir bersamaan, konflik dapat terjadi.
Ekstensi `pgactive` menyediakan mekanisme untuk deteksi konflik dan resolusi otomatis. Ini akan melacak stempel waktu ketika transaksi dilakukan pada kedua instans DB dan secara otomatis menerapkan perubahan dengan stempel waktu terbaru. Ekstensi `pgactive` juga melakukan log ketika konflik terjadi dalam tabel `pgactive.pgactive_conflict_history`.
`pgactive.pgactive_conflict_history`Akan terus tumbuh. Anda mungkin ingin menentukan kebijakan pembersihan. Ini dapat dilakukan dengan menghapus beberapa catatan secara teratur atau mendefinisikan skema partisi untuk hubungan ini (dan kemudian melepaskan, menjatuhkan, memotong partisi yang menarik). Untuk menerapkan kebijakan pembersihan secara teratur, salah satu opsi adalah menggunakan `pg_cron` ekstensi. Lihat informasi berikut dari contoh untuk tabel `pg_cron` riwayat, [Penjadwalan pemeliharaan dengan ekstensi PostgreSQL pg\$1cron](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Menangani urutan dalam replikasi aktif-aktif
Sebuah instans DB RDS for PostgreSQL dengan ekstensi `pgactive` menggunakan dua mekanisme urutan yang berbeda untuk menghasilkan nilai unik.
**Urutan Global**
Untuk menggunakan urutan global, buat urutan lokal dengan pernyataan `CREATE SEQUENCE`. Gunakan `pgactive.pgactive_snowflake_id_nextval(seqname)` alih-alih `usingnextval(seqname)` untuk mendapatkan nilai unik berikutnya dari urutan.
Contoh berikut membuat urutan global:
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Urutan yang dipartisi**
Dalam urutan split-step atau partisi, urutan PostgreSQL normal digunakan pada setiap simpul. Setiap urutan bertambah dengan jumlah yang sama dan dimulai pada offset yang berbeda. Misalnya, dengan langkah 100, simpul 1 menghasilkan urutan sebagai 101, 201, 301, dan seterusnya dan simpul 2 menghasilkan urutan sebagai 102, 202, 302, dan seterusnya. Skema ini bekerja dengan baik bahkan jika simpul tidak dapat berkomunikasi untuk waktu yang lama, tetapi mengharuskan perancang menentukan jumlah simpul maksimum saat membuat skema dan memerlukan konfigurasi per-simpul. Kesalahan dapat dengan mudah menyebabkan urutan yang tumpang tindih.
Hal ini relatif mudah untuk mengonfigurasi pendekatan ini dengan `pgactive` dengan membuat urutan yang diinginkan pada simpul sebagai berikut:
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
Kemudian panggil `setval` setiap simpul untuk memberikan nilai awal offset yang berbeda sebagai berikut.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# Mengurangi bloat dalam tabel dan indeks dengan ekstensi pg\$1repack
Anda dapat menggunakan `pg_repack` ekstensi untuk menghapus bloat dari tabel dan indeks sebagai alternatif. `VACUUM FULL` Ekstensi didukung pada RDS for PostgreSQL versi 9.6.3 dan yang lebih tinggi. Untuk informasi selengkapnya tentang `pg_repack` ekstensi dan pengemasan ulang tabel lengkap, lihat [dokumentasi GitHub proyek](https://reorg.github.io/pg_repack/).
Tidak seperti`VACUUM FULL`, `pg_repack` ekstensi memerlukan kunci eksklusif (AccessExclusiveLock) hanya untuk waktu yang singkat selama operasi membangun kembali tabel dalam kasus berikut:
+ Pembuatan awal tabel log - Tabel log dibuat untuk merekam perubahan yang terjadi selama salinan awal data, seperti yang ditunjukkan pada contoh berikut:
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ swap-and-dropFase terakhir.
Untuk sisa operasi pembangunan kembali, hanya perlu `ACCESS SHARE` kunci pada tabel asli untuk menyalin baris dari itu ke tabel baru. Ini membantu operasi INSERT, UPDATE, dan DELETE untuk melanjutkan seperti biasa.
## Rekomendasi
Rekomendasi berikut berlaku saat Anda menghapus bloat dari tabel dan indeks menggunakan ekstensi: `pg_repack`
+ Lakukan pengemasan ulang selama jam non-bisnis atau melalui jendela pemeliharaan untuk meminimalkan dampaknya terhadap kinerja aktivitas database lainnya.
+ Pantau sesi pemblokiran selama aktivitas membangun kembali dan memastikan bahwa tidak ada aktivitas di tabel asli yang berpotensi memblokir`pg_repack`, khususnya selama swap-and-drop fase akhir ketika memerlukan kunci eksklusif pada tabel asli. Untuk informasi selengkapnya, lihat [Mengidentifikasi apa yang memblokir kueri](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked).
Ketika Anda melihat sesi pemblokiran, Anda dapat menghentikannya menggunakan perintah berikut setelah mempertimbangkan dengan cermat. Ini membantu dalam kelanjutan `pg_repack` untuk menyelesaikan pembangunan kembali:
```
SELECT pg_terminate_backend(pid);
```
+ Saat menerapkan perubahan yang masih harus dibayar dari tabel `pg_repack's` log pada sistem dengan tingkat transaksi yang sangat tinggi, proses penerapan mungkin tidak dapat mengikuti tingkat perubahan. Dalam kasus seperti itu, tidak `pg_repack` akan dapat menyelesaikan proses penerapan. Untuk informasi selengkapnya, lihat [Memantau tabel baru selama pengemasan ulang](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Jika indeks sangat membengkak, solusi alternatif adalah melakukan pengemasan ulang indeks saja. Ini juga membantu siklus pembersihan indeks VACUUM untuk menyelesaikan lebih cepat.
Anda dapat melewati fase pembersihan indeks menggunakan VACUUM manual dari PostgreSQL versi 12, dan dilewati secara otomatis selama autovacuum darurat dari PostgreSQL versi 14. Ini membantu VACUUM menyelesaikan lebih cepat tanpa menghilangkan kembung indeks dan hanya dimaksudkan untuk situasi darurat seperti mencegah VACUUM sampul. Untuk informasi selengkapnya, lihat [Menghindari kembung dalam indeks di Panduan](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) Pengguna Amazon Aurora.
## Prasyarat
+ Tabel harus memiliki PRIMARY KEY atau not-null UNIQUE kendala.
+ Versi ekstensi harus sama untuk klien dan server.
+ Pastikan bahwa instance RDS memiliki `FreeStorageSpace` lebih dari ukuran total tabel tanpa kembung. Sebagai contoh, pertimbangkan ukuran total tabel termasuk TOAST dan indeks sebagai 2TB, dan total kembung dalam tabel sebagai 1TB. Yang dibutuhkan `FreeStorageSpace` harus lebih dari nilai yang dikembalikan oleh perhitungan berikut:
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
Anda dapat menggunakan kueri berikut untuk memeriksa ukuran total tabel dan gunakan `pgstattuple` untuk mendapatkan kembung. Untuk informasi selengkapnya, lihat [Mendiagnosis tabel dan indeks kembung di Panduan](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) Pengguna Amazon Aurora
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
Ruang ini direklamasi setelah selesainya kegiatan.
+ Pastikan instans RDS memiliki kapasitas komputasi dan IO yang cukup untuk menangani operasi pengemasan ulang. Anda dapat mempertimbangkan untuk meningkatkan kelas instance untuk keseimbangan kinerja yang optimal.
**Untuk menggunakan `pg_repack` ekstensi**
1. Instal `pg_repack` ekstensi pada RDS Anda untuk PostgreSQL DB instance dengan menjalankan perintah berikut.
```
CREATE EXTENSION pg_repack;
```
1. Jalankan perintah berikut untuk memberikan akses tulis ke tabel log sementara yang dibuat oleh`pg_repack`.
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. Connect ke database menggunakan utilitas `pg_repack` klien. Gunakan akun yang memiliki hak istimewa `rds_superuser`. Sebagai contoh, asumsikan bahwa peran `rds_test` memiliki hak istimewa `rds_superuser`. Sintaks berikut melakukan `pg_repack` untuk tabel lengkap termasuk semua indeks tabel dalam database. `postgres`
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**catatan**
Anda harus terhubung menggunakan opsi -k. Opsi -a tidak didukung.
Respons dari `pg_repack` klien memberikan informasi pada tabel pada instance DB yang dikemas ulang.
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. Sintaks berikut menampilkan ulang tabel tunggal `orders` termasuk indeks dalam database. `postgres`
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
Sintaks berikut hanya menampilkan indeks untuk `orders` tabel dalam database. `postgres`
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## Memantau tabel baru selama pengemasan ulang
+ Ukuran database ditingkatkan dengan ukuran total tabel dikurangi kembung, hingga swap-and-drop fase repack. Anda dapat memantau laju pertumbuhan ukuran database, menghitung kecepatan pengemasan ulang, dan memperkirakan secara kasar waktu yang diperlukan untuk menyelesaikan transfer data awal.
Sebagai contoh, pertimbangkan ukuran total tabel sebagai 2TB, ukuran database sebagai 4TB, dan total kembung dalam tabel sebagai 1TB. Nilai ukuran total database yang dikembalikan oleh perhitungan pada akhir operasi repack adalah sebagai berikut:
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
Anda dapat memperkirakan secara kasar kecepatan operasi pengemasan ulang dengan mengambil sampel laju pertumbuhan dalam byte antara dua titik waktu. Jika tingkat pertumbuhan 1GB per menit, dibutuhkan 1000 menit atau 16,6 jam kira-kira untuk menyelesaikan operasi pembuatan tabel awal. Selain pembuatan tabel awal, `pg_repack` juga perlu menerapkan perubahan yang masih harus dibayar. Waktu yang dibutuhkan tergantung pada tingkat penerapan perubahan yang sedang berlangsung ditambah perubahan yang masih harus dibayar.
**catatan**
Anda dapat menggunakan `pgstattuple` ekstensi untuk menghitung kembung dalam tabel. Untuk informasi selengkapnya, lihat [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html).
+ Jumlah baris dalam tabel `pg_repack's` log, di bawah skema repack mewakili volume perubahan yang menunggu untuk diterapkan ke tabel baru setelah pemuatan awal.
Anda dapat memeriksa tabel `pg_repack's` log `pg_stat_all_tables` untuk memantau perubahan yang diterapkan pada tabel baru. `pg_stat_all_tables.n_live_tup`menunjukkan jumlah catatan yang tertunda untuk diterapkan ke tabel baru. Untuk informasi selengkapnya, lihat [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW).
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ Anda dapat menggunakan `pg_stat_statements` ekstensi untuk mengetahui waktu yang dibutuhkan oleh setiap langkah dalam operasi pengemasan ulang. Ini sangat membantu dalam persiapan untuk menerapkan operasi pengemasan ulang yang sama di lingkungan produksi. Anda dapat menyesuaikan `LIMIT` klausa untuk memperluas output lebih lanjut.
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
Pengepakan ulang sepenuhnya merupakan out-of-place operasi sehingga tabel asli tidak terpengaruh dan kami tidak mengantisipasi tantangan tak terduga yang memerlukan pemulihan tabel asli. Jika repack gagal secara tak terduga, Anda harus memeriksa penyebab kesalahan dan menyelesaikannya.
Setelah masalah teratasi, jatuhkan dan buat ulang `pg_repack` ekstensi di database tempat tabel ada, dan coba lagi langkahnya. `pg_repack` Selain itu, ketersediaan sumber daya komputasi dan aksesibilitas tabel secara bersamaan memainkan peran penting dalam penyelesaian operasi pengemasan ulang secara tepat waktu.
# Memutakhirkan dan menggunakan ekstensi PLV8
PLV8 adalah ekstensi bahasa Javascript tepercaya untuk PostgreSQL. Anda dapat menggunakannya untuk prosedur tersimpan, pemicu, dan kode prosedural lainnya yang dapat dipanggil dari SQL. Ekstensi bahasa ini didukung oleh semua rilis PostgreSQL saat ini.
Jika Anda menggunakan [PLV8](https://plv8.github.io/)dan meningkatkan PostgreSQL ke versi PLV8 baru, Anda segera memanfaatkan ekstensi baru. Ambil langkah-langkah berikut untuk menyinkronkan metadata katalog Anda dengan versi baru. PLV8 Langkah-langkah ini opsional, tetapi kami sangat menyarankan Anda menyelesaikannya untuk menghindari peringatan ketidakcocokan metadata.
Proses pemutakhiran menjatuhkan semua PLV8 fungsi Anda yang ada. Oleh karena itu, kami menyarankan Anda membuat snapshot dari instans DB RDS for PostgreSQL Anda sebelum meningkatkan. Untuk informasi selengkapnya, lihat [Membuat snapshot DB untuk instans DB AZ tunggal untuk Amazon RDS](USER_CreateSnapshot.md).
**penting**
Dimulai dengan PostgreSQL versi 18, Amazon RDS for PostgreSQL akan menghentikan ekstensi dan PostgreSQL. `plcoffee` `plls` Kami menyarankan Anda berhenti menggunakan CoffeeScript dan LiveScript dalam aplikasi Anda untuk memastikan Anda memiliki jalur peningkatan untuk upgrade versi engine masa depan.
**Untuk menyinkronkan metadata katalog Anda dengan versi baru PLV8**
1. Verifikasi bahwa Anda perlu memperbarui. Untuk melakukannya, jalankan perintah berikut saat terhubung dengan instans Anda.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Jika hasil Anda berisi nilai untuk versi terinstal yang lebih rendah dari versi default, lanjutkan dengan prosedur ini untuk memperbarui ekstensi Anda. Misalnya, kumpulan hasil berikut menunjukkan bahwa Anda harus memperbarui.
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. Buat snapshot instans DB RDS for PostgreSQL Anda jika Anda belum melakukannya. Anda dapat melanjutkan dengan langkah-langkah berikut saat snapshot sedang dibuat.
1. Dapatkan hitungan jumlah PLV8 fungsi dalam instans DB Anda sehingga Anda dapat memvalidasi bahwa semuanya ada setelah peningkatan. Misalnya, kueri SQL berikut mengembalikan jumlah fungsi yang ditulis dalam plv8, plcoffee, and plls.
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. Gunakan pg\$1dump untuk membuat file dump hanya untuk skema. Misalnya, buat file di mesin klien Anda di direktori `/tmp`.
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
Contoh ini menggunakan hal berikut:
+ `-Fc` – Format kustom
+ --schema-only – Buang perintah yang diperlukan untuk membuat skema (fungsi dalam kasus ini)
+ `-U` – Nama pengguna utama RDS
+ `database` – Nama untuk basis data di instans DB Anda
Untuk informasi selengkapnya, lihat [pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html ) dalam dokumentasi PostgreSQL.
1. Ekstrak pernyataan DDL "CREATE FUNCTION" yang ada di berkas dump. Contoh berikut menggunakan perintah `grep` untuk mengekstrak pernyataan DDL yang menciptakan fungsi dan menyimpannya ke file. Anda menggunakan ini dalam langkah-langkah berikutnya untuk membuat ulang fungsi.
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
Untuk informasi selengkapnya pada pg\$1restore, lihat [pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html) dalam dokumentasi PostgreSQL.
1. Hapus sementara fungsi dan ekstensi. Contoh berikut menjatuhkan objek PLV8 berbasis apa pun. Opsi kaskade memastikan bahwa ketergantungan apa pun dapat dihapus sementara.
```
DROP EXTENSION plv8 CASCADE;
```
Jika instans PostgreSQL Anda berisi objek berdasarkan plcoffee atau plls, ulangi langkah ini untuk ekstensi tersebut.
1. Buat ekstensi. Contoh berikut untuk membuat ekstensi plv8, plcoffee, dan plls.
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. Buat fungsi menggunakan file dump dan file "driver".
Contoh berikut membuat ulang fungsi yang Anda ekstrak sebelumnya.
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. Verifikasi bahwa semua fungsi Anda telah dibuat ulang dengan menggunakan kueri berikut.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
PLV8 Versi 2 menambahkan baris tambahan berikut ke set hasil Anda:
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# Menggunakan PL/Rust untuk menulis fungsi PostgreSQL dalam bahasa Rust
PL/Rust is a trusted Rust language extension for PostgreSQL. You can use it for stored procedures, functions, and other procedural code that's callable from SQL. The PL/Rustekstensi bahasa tersedia dalam versi berikut:
+ RDS untuk PostgreSQL 17.1 dan versi 17 yang lebih tinggi
+ RDS untuk PostgreSQL 16.1 dan versi 16 yang lebih tinggi
+ RDS for PostgreSQL 15.2-R2 dan versi 15 yang lebih tinggi
+ RDS for PostgreSQL 14.9 dan versi 14 yang lebih tinggi
+ RDS for PostgreSQL 13.12 dan versi 13 yang lebih tinggi
Untuk informasi lebih lanjut, lihat [PL/Rust](https://github.com/tcdi/plrust#readme) on. GitHub
**Topics**
+ [Menyiapkan PL/Rust](#PL_Rust-setting-up)
+ [Membuat fungsi dengan PL/Rust](#PL_Rust-create-function)
+ [Menggunakan crate dengan PL/Rust](#PL_Rust-crates)
+ [Batasan PL/Rust](#PL_Rust-limitations)
## Menyiapkan PL/Rust
Untuk menginstal ekstensi plrust pada instans DB Anda, tambahkan plrust ke parameter `shared_preload_libraries` dalam grup parameter DB yang terkait dengan instans DB Anda. Dengan ekstensi plrust yang terinstal, Anda dapat membuat fungsi.
Untuk mengubah parameter `shared_preload_libraries`, instans DB Anda harus berkaitan dengan grup parameter kustom. Untuk informasi tentang cara membuat grup parameter DB kustom, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Anda dapat menginstal ekstensi plrust menggunakan Konsol Manajemen AWS atau. AWS CLI
Langkah-langkah berikut mengasumsikan bahwa instans Anda dikaitkan dengan grup parameter DB kustom.
### Konsol
**Instal ekstensi plrust di parameter `shared_preload_libraries`**
Lakukan langkah-langkah berikut menggunakan akun yang merupakan anggota grup `rds_superuser` (peran).
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Basis data**.
1. Pilih nama instans DB Anda untuk menampilkan detailnya.
1. Buka tab **Konfigurasi** untuk instans DB Anda dan temukan tautan grup parameter instans DB.
1. Pilih tautan untuk membuka parameter kustom yang terkait dengan instans DB.
1. Di bidang pencarian **Parameter**, ketik `shared_pre` untuk menemukan parameter **`shared_preload_libraries`**.
1. Pilih **Edit parameter** untuk mengakses nilai properti.
1. Tambahkan plrust ke daftar di bidang **Nilai**. Gunakan koma untuk memisahkan item dalam daftar nilai.
1. Boot ulang instans DB sehingga perubahan Anda pada parameter`shared_preload_libraries` akan berlaku. Boot ulang awal mungkin memerlukan waktu tambahan untuk menyelesaikannya.
1. Ketika instans tersedia, verifikasi bahwa plrust telah diinisialisasi. Gunakan `psql` untuk terhubung ke instans DB, kemudian jalankan perintah berikut.
```
SHOW shared_preload_libraries;
```
Output-nya semestinya mirip dengan yang berikut:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**Instal ekstensi plrust di parameter shared\$1preload\$1libraries**
Lakukan langkah-langkah berikut menggunakan akun yang merupakan anggota grup `rds_superuser` (peran).
1. Gunakan [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI perintah untuk menambahkan plrust ke `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI perintah untuk me-reboot instance DB dan menginisialisasi pustaka plrust. Boot ulang awal mungkin memerlukan waktu tambahan untuk menyelesaikannya.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Ketika instans tersedia, Anda dapat memverifikasi bahwa plrust telah diinisialisasi. Gunakan `psql` untuk terhubung ke instans DB, kemudian jalankan perintah berikut.
```
SHOW shared_preload_libraries;
```
Output-nya semestinya mirip dengan yang berikut:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## Membuat fungsi dengan PL/Rust
PL/Rust akan mengompilasi fungsi sebagai pustaka dinamis, memuatnya, dan menjalankannya.
Fungsi Rust berikut menyaring kelipatan dari array.
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## Menggunakan crate dengan PL/Rust
Dalam RDS untuk PostgreSQL versi 16.3-R2 dan lebih tinggi, 15.7-R2 dan versi 15 yang lebih tinggi, 14.12-R2 dan versi 14 yang lebih tinggi, dan 13.15-R2 dan versi 13 yang lebih tinggi, mendukung peti tambahan: PL/Rust
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
Dalam RDS untuk PostgreSQL versi 15.5-R2 dan lebih tinggi, 14.10-R2 dan versi 14 yang lebih tinggi, dan 13.13-R2 dan versi 13 yang lebih tinggi, mendukung dua peti tambahan: PL/Rust
+ `croaring-rs`
+ `num-bigint`
Dimulai dengan Amazon RDS untuk PostgreSQL versi 15.4, 14.9, dan 13.12, mendukung peti berikut: PL/Rust
+ `aes`
+ `ctr`
+ `rand`
Hanya fitur default yang didukung untuk crate ini. Versi RDS for PostgreSQL baru mungkin berisi versi crate terbaru, dan crate versi lama yang mungkin tidak lagi didukung lagi.
Ikuti praktik terbaik untuk melakukan peningkatan versi utama untuk menguji apakah PL/Rust fungsi Anda kompatibel dengan versi utama yang baru. Untuk informasi selengkapnya, lihat blog [Best practices for upgrading Amazon RDS to major and minor versions of PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/) serta [Upgrading the PostgreSQL DB engine for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html) di Panduan Pengguna Amazon RDS.
Contoh penggunaan dependensi saat membuat PL/Rust fungsi tersedia di [Gunakan](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies) dependensi.
## Batasan PL/Rust
Secara default, pengguna database tidak dapat menggunakanPL/Rust. To provide access to PL/Rust, terhubung sebagai pengguna dengan hak istimewa rds\$1superuser, dan menjalankan perintah berikut:
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# Mengelola data spasial dengan ekstensi PostGIS
PostGIS adalah ekstensi dari PostgreSQL untuk menyimpan dan mengelola informasi spasial. Untuk mempelajari selengkapnya tentang PostGIS, lihat [PostGIS.net](https://postgis.net/).
Mulai dari versi 10.5, PostgreSQL mendukung pustaka libprotobuf 1.3.0 yang digunakan oleh PostGIS agar berfungsi dengan data petak vektor map box.
Menyiapkan ekstensi PostGIS membutuhkan hak akses `rds_superuser`. Sebaiknya Anda membuat (peran) pengguna untuk mengelola ekstensi PostGIS dan data spasial. Ekstensi PostGIS dan komponen terkaitnya menambahkan ribuan fungsi ke PostgreSQL. Anda juga dapat membuat ekstensi PostGIS dalam skema tersendiri jika sesuai untuk kasus penggunaan Anda. Contoh berikut menunjukkan cara menginstal ekstensi dalam basis data tersendiri, tetapi ini tidak wajib dilakukan.
**Topics**
+ [Langkah 1: Membuat (peran) pengguna untuk mengelola ekstensi PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [Langkah 2: Memuat ekstensi PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [Langkah 3: Transfer kepemilikan skema ekstensi](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [Langkah 4: Transfer kepemilikan tabel PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [Langkah 5: Menguji ekstensi](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [Langkah 6: Meningkatkan ekstensi PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [Versi ekstensi PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Meningkatkan PostGIS 2 ke PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Langkah 1: Membuat (peran) pengguna untuk mengelola ekstensi PostGIS
Pertama, hubungkan ke instans DB RDS for PostgreSQL sebagai pengguna yang memiliki hak akses `rds_superuser`. Jika tidak mengubah nama default saat menyiapkan instans, Anda akan terhubung sebagai `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Buat peran (pengguna) terpisah untuk mengelola ekstensi PostGIS.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Berikan hak akses `rds_superuser` kepada peran ini agar dapat menginstal ekstensi.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Buat basis data agar dapat digunakan untuk artefak PostGIS. Langkah ini bersifat opsional. Atau, Anda dapat membuat skema di basis data pengguna untuk ekstensi PostGIS, tetapi ini juga tidak wajib dilakukan.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Berikan semua hak akses `gis_admin` pada basis data `lab_gis`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Keluar dari sesi, lalu sambungkan kembali ke instans DB RDS for PostgreSQL Anda sebagai `gis_admin`.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Lanjutkan menyiapkan ekstensi seperti yang dijelaskan pada langkah berikutnya.
## Langkah 2: Memuat ekstensi PostGIS
Ekstensi PostGIS mencakup beberapa ekstensi terkait yang berfungsi bersama untuk menyediakan fungsionalitas geospasial. Tergantung pada kasus penggunaannya, Anda mungkin tidak memerlukan semua ekstensi yang dibuat pada langkah ini.
Gunakan pernyataan `CREATE EXTENSION` untuk memuat ekstensi PostGIS.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
Anda dapat memverifikasi hasilnya dengan menjalankan kueri SQL yang ditunjukkan dalam contoh berikut, yang mencantumkan ekstensi dan pemiliknya.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Langkah 3: Transfer kepemilikan skema ekstensi
Gunakan pernyataan ALTER SCHEMA untuk mentransfer kepemilikan skema ke peran `gis_admin`.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Anda dapat mengonfirmasi perubahan kepemilikan dengan menjalankan kueri SQL berikut. Bisa juga dengan menggunakan metacommand `\dn` dari baris perintah psql.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Langkah 4: Transfer kepemilikan tabel PostGIS
**catatan**
Jangan mengubah kepemilikan fungsi PostGIS. Operasi yang tepat dan peningkatan PostGIS di masa mendatang memerlukan fungsi-fungsi ini untuk mempertahankan kepemilikan asli. [Untuk informasi selengkapnya tentang izin PostGIS, lihat PostgreSQL Security.](https://postgis.net/workshops/postgis-intro/security.html)
Gunakan fungsi berikut untuk mentransfer kepemilikan tabel PostGIS ke peran. `gis_admin` Jalankan pernyataan berikut dari perintah psql untuk membuat fungsinya.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
Selanjutnya, jalankan kueri berikut untuk menjalankan fungsi `exec` yang nantinya akan menjalankan pernyataan dan mengubah izin.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Langkah 5: Menguji ekstensi
Agar Anda tidak harus menentukan nama skema, tambahkan skema `tiger` ke jalur pencarian menggunakan perintah berikut.
```
SET search_path=public,tiger;
SET
```
Uji skema `tiger` menggunakan pernyataan SELECT berikut.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Untuk mempelajari selengkapnya tentang ekstensi ini, lihat [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) dalam dokumentasi PostGIS.
Uji akses ke skema `topology` menggunakan pernyataan `SELECT` berikut. Tindakan ini akan memanggil fungsi `createtopology` untuk mendaftarkan objek topologi baru (my\$1new\$1topo) dengan pengidentifikasi referensi spasial (26986) dan toleransi default (0,5) yang ditentukan. Untuk mempelajari lebih lanjut, lihat [CreateTopology](https://postgis.net/docs/CreateTopology.html)di dokumentasi PostGIS.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Langkah 6: Meningkatkan ekstensi PostGIS
Setiap rilis baru PostgreSQL mendukung satu atau beberapa versi ekstensi PostGIS yang kompatibel dengan rilis tersebut. Meningkatkan mesin PostgreSQL ke versi baru tidak secara otomatis meningkatkan ekstensi PostGIS. Sebelum meningkatkan mesin PostgreSQL, Anda biasanya meningkatkan PostGIS ke versi terbaru yang tersedia untuk versi PostgreSQL saat ini. Untuk mengetahui detailnya, lihat [Versi ekstensi PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS).
Setelah peningkatan mesin PostgreSQL, selanjutnya tingkatkan ekstensi PostGIS lagi, ke versi yang didukung untuk versi mesin PostgreSQL yang baru ditingkatkan. Untuk informasi selengkapnya tentang cara meningkatkan mesin PostgreSQL, lihat [Cara melakukan upgrade versi utama untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Anda dapat memeriksa pembaruan versi ekstensi PostGIS yang tersedia di instans DB RDS for PostgreSQL kapan saja. Untuk melakukannya, jalankan perintah berikut. Fungsi ini tersedia untuk PostGIS 2.5.0 dan versi yang lebih baru.
```
SELECT postGIS_extensions_upgrade();
```
Jika aplikasi Anda tidak mendukung versi PostGIS terbaru, Anda dapat menginstal versi PostGIS lama yang tersedia di versi utama Anda sebagai berikut.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Jika ingin meningkatkan ke versi PostGIS tertentu dari versi lama, Anda juga dapat menggunakan perintah berikut.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Tergantung pada versi sebelum peningkatan, Anda mungkin perlu menggunakan fungsi ini lagi. Hasil dari menjalankan fungsi pertama akan menentukan perlu atau tidaknya fungsi peningkatan lain. Misalnya, ini adalah kasus peningkatan dari PostGIS 2 ke PostGIS 3. Untuk informasi selengkapnya, lihat [Meningkatkan PostGIS 2 ke PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Jika meningkatkan ekstensi ini untuk mempersiapkan peningkatan versi utama mesin PostgreSQL, Anda dapat melanjutkan tugas awal lainnya. Untuk informasi selengkapnya, lihat [Cara melakukan upgrade versi utama untuk RDS untuk PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
## Versi ekstensi PostGIS
Sebaiknya, Anda menginstal versi semua ekstensi seperti PostGIS sebagaimana tercantum di [Versi ekstensi untuk Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) dalam *Catatan Rilis Amazon RDS for PostgreSQL*. Untuk mendapatkan daftar versi yang tersedia dalam rilis Anda, gunakan perintah berikut.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Anda dapat menemukan informasi versi di bagian berikut dalam *Catatan Rilis Amazon RDS for PostgreSQL*:
+ [Ekstensi PostgreSQL versi 16 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [Ekstensi PostgreSQL versi 15 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [Ekstensi PostgreSQL versi 14 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [Ekstensi PostgreSQL versi 13 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [Ekstensi PostgreSQL versi 12 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [Ekstensi PostgreSQL versi 11 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [Ekstensi PostgreSQL versi 10 didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [Ekstensi PostgreSQL versi 9.6.x yang didukung di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## Meningkatkan PostGIS 2 ke PostGIS 3
Mulai dari versi 3.0, fungsi raster PostGIS kini menjadi ekstensi terpisah, `postgis_raster`. Ekstensi ini memiliki jalur instalasi dan peningkatan tersendiri. Ekstensi ini menghapus berbagai fungsi, tipe data, dan artefak lain yang diperlukan untuk pemrosesan gambar raster dari ekstensi `postgis` inti. Artinya, jika kasus penggunaan Anda tidak memerlukan pemrosesan raster, Anda tidak perlu menginstal ekstensi `postgis_raster`.
Dalam contoh peningkatan berikut, perintah peningkatan pertama mengekstrak fungsionalitas raster ke dalam ekstensi `postgis_raster`. Selanjutnya, perintah peningkatan kedua diperlukan untuk meningkatkan `postgis_raster` ke versi baru.
**Untuk meningkatkan dari PostGIS 2 ke PostGIS 3**
1. Identifikasi versi default PostGIS yang tersedia untuk versi PostgreSQL di instans DB RDS for PostgreSQL. Untuk melakukannya, jalankan kueri berikut.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifikasi versi PostGIS yang diinstal di setiap basis data pada instans DB RDS for PostgreSQL. Dengan kata lain, buat kueri setiap basis data pengguna sebagai berikut.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Ketidakcocokan antara versi default (PostGIS 3.1.4) dan versi yang diinstal (PostGIS 2.3.7) ini mengindikasikan bahwa Anda perlu meningkatkan ekstensi PostGIS.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Jalankan kueri berikut untuk memverifikasi bahwa fungsi raster kini telah berada dalam paketnya tersendiri.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
Output-nya menunjukkan bahwa masih ada perbedaan antarversi. Fungsi PostGIS adalah versi 3 (postgis-3), sedangkan fungsi raster (rtpostgis) adalah versi 2 (rtpostgis-2.3). Untuk menyelesaikan peningkatan, Anda dapat menjalankan perintah peningkatan lagi sebagai berikut.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Anda dapat dengan aman mengabaikan pesan peringatan. Jalankan lagi kueri berikut untuk memverifikasi bahwa peningkatan telah selesai. Peningkatan selesai saat PostGIS dan semua ekstensi terkait tidak ditandai sebagai perlu peningkatan.
```
SELECT postgis_full_version();
```
1. Gunakan kueri berikut untuk melihat proses peningkatan yang telah selesai dan ekstensi yang dikemas secara terpisah, lalu verifikasi bahwa versinya telah sesuai.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
Output menunjukkan bahwa ekstensi PostGIS 2 telah ditingkatkan ke PostGIS 3, serta ekstensi `postgis` dan ekstensi `postgis_raster` yang sekarang terpisah adalah versi 3.1.5.
Setelah peningkatan ini selesai, Anda dapat menghapus ekstensi seperti berikut jika tidak berencana menggunakan fungsionalitas raster.
```
DROP EXTENSION postgis_raster;
```
# Bekerja dengan pembungkus data asing yang didukung untuk Amazon RDS for PostgreSQL
Pembungkus data asing (FDW) adalah jenis ekstensi tertentu yang memberikan akses ke data eksternal. Misalnya, ekstensi `oracle_fdw` memungkinkan klaster DB RDS for PostgreSQL bekerja dengan basis data Oracle. Sebagai contoh lain, dengan menggunakan ekstensi `postgres_fdw` asli PostgreSQL, Anda dapat mengakses data yang disimpan pada instans DB PostgreSQL di luar instans DB RDS for PostgreSQL Anda.
Selanjutnya, Anda dapat menemukan informasi tentang beberapa pembungkus data asing PostgreSQL yang didukung.
**Topics**
+ [Menggunakan ekstensi log\$1fdw untuk mengakses log DB dengan SQL](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [Menggunakan ekstensi postgres\$1fdw untuk mengakses data eksternal](postgresql-commondbatasks-fdw.md)
+ [Bekerja dengan basis data MySQL menggunakan ekstensi mysql\$1fdw](postgresql-mysql-fdw.md)
+ [Bekerja dengan basis data Oracle menggunakan ekstensi oracle\$1fdw](postgresql-oracle-fdw.md)
+ [Bekerja dengan database SQL Server dengan menggunakan ekstensi tds\$1fdw](postgresql-tds-fdw.md)
# Menggunakan ekstensi log\$1fdw untuk mengakses log DB dengan SQL
Instans DB RDS for PostgreSQL mendukung ekstensi `log_fdw` yang dapat Anda gunakan untuk mengakses log mesin basis data menggunakan antarmuka SQL. Ekstensi `log_fdw` ini memberikan dua fungsi yang memudahkan pembuatan tabel asing untuk log basis data:
+ `list_postgres_log_files` – Mencantumkan file di direktori log basis data dan ukuran file dalam byte.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` – Membangun tabel asing untuk file yang ditentukan dalam basis data saat ini.
Semua fungsi yang dibuat oleh `log_fdw` dimiliki oleh `rds_superuser`. Anggota dengan peran `rds_superuser` dapat memberikan akses ke fungsi ini kepada pengguna basis data lain.
Secara default, file log dibuat oleh Amazon RDS dalam format `stderr` (kesalahan standar), seperti yang ditentukan pada parameter `log_destination`. Hanya ada dua opsi untuk parameter ini, yaitu `stderr` dan `csvlog` (nilai yang dipisahkan koma, CSV). Jika Anda menambahkan opsi `csvlog` ke parameter, Amazon RDS akan membuat log `stderr` dan `csvlog`. Hal ini dapat memengaruhi kapasitas penyimpanan pada klaster DB sehingga Anda perlu mengetahui parameter lain yang memengaruhi penanganan log. Untuk informasi selengkapnya, lihat [Mengatur tujuan log (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
Salah satu manfaat pembuatan log `csvlog` adalah ekstensi `log_fdw` memungkinkan Anda membangun tabel asing dengan data yang terbagi dengan rapi menjadi beberapa kolom. Untuk melakukannya, instans Anda harus terkait dengan grup parameter DB kustom sehingga Anda dapat mengubah pengaturan `log_destination`. Untuk informasi selengkapnya tentang cara melakukannya, lihat [Bekerja dengan parameter pada instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Contoh berikut mengasumsikan bahwa parameter `log_destination` mencakup `cvslog`.
**Untuk menggunakan ekstensi log\$1fdw**
1. Instal ekstensi `log_fdw`.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Buat server log sebagai pembungkus data asing.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Pilih semua dari daftar file log.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
Respons sampel sebagai berikut.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Membuat tabel dengan satu kolom 'log\$1entry' untuk file yang dipilih.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
Respons tersebut tidak memberikan detail selain memberitahukan bahwa tabel telah ada.
```
-----------------------------------
(1 row)
```
1. Pilih sampel file log. Kode berikut mengambil waktu log dan deskripsi pesan kesalahan.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
Respons sampel sebagai berikut.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Menggunakan ekstensi postgres\$1fdw untuk mengakses data eksternal
Anda dapat mengakses data dalam tabel di server basis data jarak jauh dengan ekstensi [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html). Jika Anda mengatur koneksi jarak jauh dari instans DB PostgreSQL, akses juga tersedia untuk replika baca Anda.
**Untuk menggunakan postgres\$1fdw agar dapat mengakses server basis data jarak jauh**
1. Instal ekstensi postgres\$1fdw.
```
CREATE EXTENSION postgres_fdw;
```
1. Buat server data asing menggunakan CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Buat pemetaan pengguna untuk mengidentifikasi peran yang akan digunakan pada server jarak jauh.
**penting**
Untuk menyunting kata sandi sehingga tidak muncul di log, atur `log_statement=none` pada tingkat sesi. Pengaturan pada tingkat parameter tidak menyunting kata sandi.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Buat tabel yang memetakan ke tabel pada server jarak jauh.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Bekerja dengan basis data MySQL menggunakan ekstensi mysql\$1fdw
Untuk mengakses basis data yang kompatibel dengan MySQL dari instans DB RDS for PostgreSQL, Anda dapat menginstal dan menggunakan ekstensi `mysql_fdw`. Pembungkus data asing ini memungkinkan Anda bekerja dengan basis data RDS for MySQL, Aurora MySQL, MariaDB, dan basis data MySQL lainnya yang kompatibel. Koneksi dari instans DB RDS for PostgreSQL ke basis data MySQL dienkripsi secara optimal, tergantung pada konfigurasi klien dan server. Namun, Anda dapat menerapkan enkripsi jika diinginkan. Untuk informasi selengkapnya, lihat [Menggunakan enkripsi bergerak dengan ekstensi](#postgresql-mysql-fdw.encryption-in-transit).
Ekstensi `mysql_fdw` didukung di Amazon RDS for PostgreSQL versi 14.2, 13.6, dan rilis yang lebih baru. Ekstensi ini mendukung untuk memilih, menyisipkan, memperbarui, dan menghapus dari DB RDS for PostgreSQL ke tabel pada instans basis data yang kompatibel dengan MySQL.
**Topics**
+ [Mengatur basis data RDS for PostgreSQL untuk menggunakan ekstensi mysql\$1fdw](#postgresql-mysql-fdw.setting-up)
+ [Contoh: Bekerja dengan basis data RDS for MySQL dari RDS for PostgreSQL](#postgresql-mysql-fdw.using-mysql_fdw)
+ [Menggunakan enkripsi bergerak dengan ekstensi](#postgresql-mysql-fdw.encryption-in-transit)
## Mengatur basis data RDS for PostgreSQL untuk menggunakan ekstensi mysql\$1fdw
Mengatur ekstensi `mysql_fdw` pada instans DB RDS for PostgreSQL melibatkan pemuatan ekstensi pada instans DB, lalu membuat koneksi yang mengarah ke instans DB MySQL. Untuk tugas tersebut, Anda harus memiliki detail instans DB MySQL berikut:
+ Nama host atau titik akhir. Untuk instans DB RDS for MySQL, Anda dapat menemukan titik akhir menggunakan Konsol. Pilih tab Konektivitas & keamanan, lalu lihat di bagian "Titik akhir dan port".
+ Nomor port. Nomor port default untuk MySQL adalah 3306.
+ Nama basis data. Pengidentifikasi DB.
Anda juga perlu memberikan akses di grup keamanan atau daftar kontrol akses (ACL) untuk port MySQL, 3306. Baik instans DB RDS for PostgreSQL dan instans DB RDS for MySQL memerlukan akses ke port 3306. Jika akses tidak dikonfigurasi dengan benar, Anda akan melihat pesan kesalahan yang serupa dengan berikut ini saat mencoba menghubungkan ke tabel yang kompatibel dengan MySQL:
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
Dalam prosedur berikut, Anda (sebagai akun `rds_superuser`) akan membuat server asing. Kemudian, Anda akan memberikan akses ke server asing untuk pengguna tertentu. Pengguna ini akan membuat pemetaan mereka sendiri ke akun pengguna MySQL yang sesuai untuk bekerja dengan instans DB MySQL.
**Untuk menggunakan mysql\$1fdw agar dapat mengakses server basis data MySQL**
1. Hubungkan ke instans DB PostgreSQL Anda menggunakan akun yang memiliki peran `rds_superuser`. Jika Anda menerima default saat membuat instans DB RDS for PostgreSQL, nama pengguna adalah `postgres`, dan Anda dapat terhubung menggunakan alat baris perintah `psql` sebagai berikut:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Instal ekstensi `mysql_fdw` sebagai berikut:
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
Setelah ekstensi diinstal pada instans DB RDS for PostgreSQL, Anda dapat mengatur server asing yang memberikan koneksi ke basis data MySQL.
**Untuk membuat server asing**
Lakukan tugas-tugas ini pada instans DB RDS for PostgreSQL. Langkah-langkah ini mengasumsikan bahwa Anda terhubung sebagai pengguna dengan hak istimewa `rds_superuser`, seperti `postgres`.
1. Membuat server asing pada instans DB RDS for PostgreSQL:
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Berikan akses pengguna yang sesuai ke server asing. Pengguna yang diberi akses harus pengguna non-administrator, yaitu pengguna tanpa peran `rds_superuser`.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
Pengguna PostgreSQL membuat dan mengelola koneksi mereka ke basis data MySQL melalui server asing.
## Contoh: Bekerja dengan basis data RDS for MySQL dari RDS for PostgreSQL
Misalnya, Anda memiliki tabel sederhana pada instans DB RDS for PostgreSQL. Pengguna RDS for PostgreSQL Anda ingin membuat kueri item (`SELECT`), `INSERT`, `UPDATE`, dan `DELETE` pada tabel tersebut. Asumsikan bahwa ekstensi `mysql_fdw` dibuat di instans DB RDS for PostgreSQL, seperti yang dijelaskan dalam prosedur sebelumnya. Setelah terhubung ke instans DB RDS for PostgreSQL sebagai pengguna yang memiliki hak istimewa `rds_superuser`, Anda dapat melanjutkan langkah-langkah berikut.
1. Pada instans DB RDS for PostgreSQL, buat server asing:
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Izinkan penggunaan kepada pengguna yang tidak memiliki izin `rds_superuser`, misalnya `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Connect as*user1*, lalu buat pemetaan ke pengguna MySQL:
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Buat tabel asing yang dihubungkan ke tabel MySQL:
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Jalankan kueri sederhana pada tabel asing:
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. Anda dapat menambahkan, mengubah, dan menghapus data dari tabel MySQL. Sebagai contoh:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Jalankan lagi kueri `SELECT` untuk melihat hasilnya:
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Menggunakan enkripsi bergerak dengan ekstensi
Koneksi ke MySQL dari RDS for PostgreSQL menggunakan enkripsi bergerak (TLS/SSL) secara default. Namun, koneksi akan kembali ke non-enkripsi saat konfigurasi klien dan server berbeda. Anda dapat menerapkan enkripsi untuk semua koneksi yang keluar dengan menentukan opsi `REQUIRE SSL` pada akun pengguna RDS for MySQL. Pendekatan yang sama juga bekerja untuk akun pengguna MariaDB dan Aurora MySQL.
Untuk akun pengguna MySQL yang dikonfigurasi ke `REQUIRE SSL`, upaya koneksi akan gagal jika koneksi tidak aman.
Untuk menerapkan enkripsi akun pengguna basis data MySQL yang ada, Anda dapat menggunakan perintah `ALTER USER`. Sintaksis dapat berbeda-beda, bergantung pada versi MySQL, seperti yang ditunjukkan pada tabel berikut. Untuk informasi selengkapnya, lihat [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) pada *Panduan Referensi MySQL*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
Untuk informasi selengkapnya tentang ekstensi `mysql_fdw`, lihat dokumentasi [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw).
# Bekerja dengan basis data Oracle menggunakan ekstensi oracle\$1fdw
Untuk mengakses basis data Oracle dari instans DB RDS for PostgreSQL, Anda dapat menginstal dan menggunakan ekstensi `oracle_fdw`. Ekstensi ini adalah pembungkus data asing untuk basis data Oracle. Untuk mempelajari selengkapnya tentang ekstensi ini, lihat dokumentasi [oracle\$1fdw](https://github.com/laurenz/oracle_fdw).
Ekstensi `oracle_fdw` didukung pada RDS for PostgreSQL 12.7, 13.3, dan versi yang lebih baru.
**Topics**
+ [Mengaktifkan ekstensi oracle\$1fdw](#postgresql-oracle-fdw.enabling)
+ [Contoh: Menggunakan server asing yang terhubung ke basis data Amazon RDS for Oracle](#postgresql-oracle-fdw.example)
+ [Bekerja dengan enkripsi bergerak](#postgresql-oracle-fdw.encryption)
+ [Memahami tampilan dan izin pg\$1user\$1mappings](#postgresql-oracle-fdw.permissions)
## Mengaktifkan ekstensi oracle\$1fdw
Untuk menggunakan ekstensi oracle\$1fdw, lakukan prosedur berikut.
**Untuk mengaktifkan ekstensi oracle\$1fdw**
+ Jalankan perintah berikut menggunakan akun yang memiliki izin `rds_superuser`.
```
CREATE EXTENSION oracle_fdw;
```
## Contoh: Menggunakan server asing yang terhubung ke basis data Amazon RDS for Oracle
Contoh berikut ini menunjukkan penggunaan server asing yang terhubung ke basis data Amazon RDS for Oracle.
**Untuk membuat server asing yang terhubung ke basis data RDS for Oracle**
1. Perhatikan hal-hal berikut ini pada instans DB RDS for Oracle:
+ Titik Akhir
+ Port
+ Nama basis data
1. Membuat server asing.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Izinkan penggunaan kepada pengguna yang tidak memiliki hak istimewa `rds_superuser`, misalnya `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Hubungkan sebagai `user1`, lalu buat pemetaan kepada pengguna Oracle.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Buat tabel asing yang dihubungkan ke tabel Oracle.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Buat kueri tabel asing.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Jika kueri melaporkan kesalahan berikut, periksa grup keamanan dan daftar kontrol akses (ACL) untuk memastikan bahwa kedua instans dapat berkomunikasi.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Bekerja dengan enkripsi bergerak
PostgreSQL-to-Oracle enkripsi dalam perjalanan didasarkan pada kombinasi parameter konfigurasi klien dan server. Untuk contoh menggunakan Oracle 21c, lihat [Tentang Nilai untuk Melakukan Negosiasi Enkripsi dan Integritas](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) pada dokumentasi Oracle. Klien yang digunakan untuk oracle\$1fdw di Amazon RDS dikonfigurasi `ACCEPTED` dengan, artinya enkripsi bergantung pada konfigurasi server database Oracle dan menggunakan Oracle Security Library (libnnz) untuk enkripsi.
Jika basis data Anda menggunakan RDS for Oracle, lihat [Enkripsi jaringan asli Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) untuk mengonfigurasi enkripsi.
## Memahami tampilan dan izin pg\$1user\$1mappings
Katalog PostgreSQL `pg_user_mapping` menyimpan pemetaan dari pengguna RDS for PostgreSQL ke pengguna di server data asing (jarak jauh). Akses ke katalog dibatasi, tetapi Anda menggunakan tampilan `pg_user_mappings` untuk melihat pemetaan. Berikut ini Anda dapat menemukan contoh yang menunjukkan bagaimana izin berlaku dengan contoh basis data Oracle, tetapi informasi ini biasanya berlaku untuk pembungkus data asing apa pun.
Pada output berikut, Anda dapat menemukan peran dan izin yang dipetakan kepada tiga pengguna contoh yang berbeda. Pengguna `rdssu1` dan `rdssu2` adalah anggota dengan peran `rds_superuser`, sedangkan `user1` tidak. Contoh menggunakan metacommand `psql` `\du` untuk daftar peran yang ada.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Semua pengguna, termasuk pengguna yang memiliki hak istimewa `rds_superuser`, diizinkan untuk melihat pemetaan pengguna (`umoptions`) mereka sendiri di tabel `pg_user_mappings`. Seperti yang ditunjukkan pada contoh berikut, saat `rdssu1` mencoba untuk mendapatkan semua pemetaan pengguna, kesalahan ditampilkan meskipun hak istimewa `rdssu1` `rds_superuser`:
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
Berikut adalah beberapa contoh.
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
Karena perbedaan implementasi antara `information_schema._pg_user_mappings` dan `pg_catalog.pg_user_mappings`, maka `rds_superuser` yang dibuat secara manual memerlukan izin tambahan untuk dapat melihat kata sandi di `pg_catalog.pg_user_mappings`.
`rds_superuser` tidak memerlukan izin tambahan untuk dapat melihat kata sandi di `information_schema._pg_user_mappings`.
Pengguna yang tidak memiliki peran `rds_superuser` dapat melihat kata sandi `pg_user_mappings` hanya dalam kondisi berikut:
+ Pengguna saat ini adalah pengguna yang dipetakan dan memiliki server atau memegang hak istimewa `USAGE` atas server tersebut.
+ Pengguna saat ini adalah pemilik server dan pemetaannya untuk `PUBLIC`.
# Bekerja dengan database SQL Server dengan menggunakan ekstensi tds\$1fdw
Anda dapat menggunakan SQL `tds_fdw` ekstensi Postgre untuk mengakses database yang mendukung protokol aliran data tabular (TDS), seperti database Sybase dan Microsoft Server. SQL Pembungkus data asing ini memungkinkan Anda terhubung dari ke database yang menggunakan protokol, TDS termasuk Amazon untuk Microsoft Server. RDS RDS SQL Untuk informasi selengkapnya, lihat dokumentasi [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) di. GitHub
`tds_fdw`Ekstensi ini didukung di Amazon RDS untuk Postgre SQL versi 14.2, 13.6, dan rilis yang lebih tinggi.
## Menyiapkan Aurora Postgre SQL DB Anda untuk menggunakan ekstensi tds\$1fdw
Dalam prosedur berikut, Anda dapat menemukan contoh pengaturan dan penggunaan `tds_fdw` dengan RDSuntuk Postgre SQL DB instance Postgre DB cluster. SQL Sebelum Anda dapat terhubung ke database SQL Server menggunakan`tds_fdw`, Anda perlu mendapatkan rincian berikut untuk contoh:
+ Nama host atau titik akhir. Untuk instans RDS for SQL Server DB, Anda dapat menemukan titik akhir dengan menggunakan Console. Pilih tab Konektivitas & keamanan, lalu lihat di bagian "Titik akhir dan port".
+ Nomor port. Nomor port default untuk Microsoft SQL Server adalah 1433.
+ Nama basis data. Pengidentifikasi DB.
Anda juga perlu menyediakan akses pada grup keamanan atau daftar kontrol akses (ACL) untuk port SQL Server, 1433. Baik untuk instance Postgre SQL DB dan instance RDS untuk SQL Server DB memerlukan akses ke port 1433. Jika akses tidak dikonfigurasi dengan benar, ketika Anda mencoba untuk query Microsoft SQL Server Anda melihat pesan galat berikut:
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**Untuk menggunakan tds\$1fdw untuk terhubung ke database Server SQL**
1. Connect ke instans Postgre SQL DB instans Aurora menggunakan akun yang memiliki peran: `rds_superuser`
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Instal ekstensi `tds_fdw`:
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
Setelah ekstensi diinstal pada Anda RDSuntuk instance Postgre SQL DB, Anda mengatur server asing.
**Untuk membuat server asing**
Lakukan tugas-tugas ini di untuk instans Postgre SQL DB menggunakan akun yang memiliki hak istimewa. `rds_superuser`
1. Buat server asing di : SQL
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
Untuk mengakses ASCII non-data di SQLServer samping, buat tautan server dengan opsi character\$1set di cluster : RDS SQL
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Berikan izin kepada pengguna yang tidak memiliki hak istimewa peran `rds_superuser`, misalnya `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Connect as user1 dan buat pemetaan ke pengguna SQL Server:
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Buat tabel asing yang ditautkan ke tabel SQL Server:
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Buat kueri tabel asing:
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Gunakan enkripsi bergerak untuk koneksi
Koneksi dari untuk Postgre SQL ke SQL Server menggunakan enkripsi dalam transit (TLS/SSL) tergantung pada konfigurasi database Server. SQL Jika SQL Server tidak dikonfigurasi untuk enkripsi, SQL klien Postgre RDS untuk membuat permintaan ke database SQL Server akan kembali ke tidak terenkripsi.
Anda dapat menerapkan enkripsi untuk koneksi ke RDS instans SQL Server DB dengan menyetel parameter. `rds.force_ssl` Untuk mempelajari caranya, lihat [Memaksa koneksi ke instans DB Anda untuk digunakan SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). Untuk informasi selengkapnya tentangSSL/TLSkonfigurasi RDS untuk SQL Server, lihat [Menggunakan SSL dengan instans Microsoft SQL Server DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).
# Bekerja dengan Ekstensi Bahasa Tepercaya untuk PostgreSQL
Ekstensi Bahasa Tepercaya untuk PostgreSQL adalah kit pengembangan sumber terbuka untuk mendesain ekstensi PostgreSQL. Ini memungkinkan Anda untuk membangun ekstensi PostgreSQL performa tinggi dan menjalankannya dengan aman di instans DB RDS for PostgreSQL. Dengan menggunakan Ekstensi Bahasa Tepercaya (TLE) untuk PostgreSQL, Anda dapat membuat ekstensi PostgreSQL yang mengikuti pendekatan terdokumentasi untuk memperluas fungsionalitas PostgreSQL. Lihat informasi selengkapnya, lihat [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) dalam dokumentasi PostgreSQL.
Salah satu manfaat utama TLE adalah Anda dapat menggunakannya di lingkungan yang tidak menyediakan akses ke sistem file yang mendasari instans PostgreSQL. Sebelumnya, penginstalan ekstensi baru memerlukan akses ke sistem file. TLE menghilangkan batasan ini. Ini menyediakan lingkungan pengembangan untuk membuat ekstensi baru untuk basis data PostgreSQL apa pun, termasuk yang berjalan di instans DB RDS for PostgreSQL.
TLE dirancang untuk mencegah akses ke sumber daya yang tidak aman untuk ekstensi yang Anda buat menggunakan TLE. Lingkungan runtime-nya membatasi dampak kerusakan ekstensi apa pun ke koneksi basis data tunggal. TLE juga memberi administrator basis data kontrol terperinci atas siapa saja yang dapat menginstal ekstensi, dan memberikan model izin untuk menjalankannya.
TLE didukung pada versi RDS for PostgreSQL berikut:
+ Versi 18.1 dan versi 18 yang lebih tinggi
+ Versi 17.1 dan versi 17 yang lebih tinggi
+ Versi 16.1 dan versi 16 yang lebih tinggi
+ Versi 15.2 dan versi 15 yang lebih tinggi
+ Versi 14.5 dan versi 14 yang lebih tinggi
+ Versi 13.12 dan versi 13 yang lebih tinggi
Lingkungan pengembangan dan runtime Ekstensi Bahasa Tepercaya dikemas sebagai ekstensi PostgreSQL `pg_tle`, versi 1.0.1. Ini mendukung pembuatan ekstensi di JavaScript, Perl, Tcl, PL/PGSQL, dan SQL. Anda menginstal ekstensi `pg_tle` di instans RDS for PostgreSQL dengan cara yang sama seperti Anda menginstal ekstensi PostgreSQL lainnya. Setelah `pg_tle` disiapkan, developer dapat menggunakannya untuk membuat ekstensi PostgreSQL baru, yang dikenal sebagai *ekstensi TLE*.
Dalam topik berikut, Anda dapat menemukan informasi tentang cara mengatur Ekstensi Bahasa Tepercaya dan cara memulai membuat ekstensi TLE Anda sendiri.
**Topics**
+ [Terminologi](PostgreSQL_trusted_language_extension-terminology.md)
+ [Persyaratan untuk menggunakan Ekstensi Bahasa Tepercaya untuk PostgreSQL](PostgreSQL_trusted_language_extension-requirements.md)
+ [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md)
+ [Ikhtisar Ekstensi Bahasa Tepercaya untuk Postgre SQL](PostgreSQL_trusted_language_extension.overview.md)
+ [Membuat ekstensi TLE untuk RDS for PostgreSQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [Menjatuhkan TLE ekstensi Anda dari database](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [Menghapus Instalasi Ekstensi Bahasa Tepercaya untuk Postgre SQL](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [Menggunakan hook PostgreSQL dengan ekstensi TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [Menggunakan Tipe Data Kustom di TLE](PostgreSQL_trusted_language_extension-custom-data-type.md)
+ [Referensi fungsi untuk Ekstensi Bahasa Tepercaya untuk Postgre SQL](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [Referensi hook untuk Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md)
# Terminologi
Untuk membantu Anda lebih memahami Ekstensi Bahasa Tepercaya, lihat glosarium berikut untuk istilah yang digunakan dalam topik ini.
**Ekstensi Bahasa Tepercaya untuk Postgre SQL**
*Ekstensi Bahasa Tepercaya untuk Postgre SQL* adalah nama resmi kit pengembangan open source yang dikemas sebagai ekstensi. `pg_tle` Ini tersedia untuk digunakan pada sistem Postgre SQL apa pun. Untuk informasi selengkapnya, lihat [aws/pg\$1tle](https://github.com/aws/pg_tle) di. GitHub
**Ekstensi Bahasa Terpercaya**
*Trusted Language Extensions* adalah singkatan dari Trusted Language Extensions for PostgreSQL. Nama singkat ini dan singkatannya (TLE) juga digunakan dalam dokumentasi ini.
**bahasa tepercaya**
*Bahasa tepercaya* adalah bahasa pemrograman atau skrip yang memiliki atribut keamanan tertentu. Misalnya, bahasa tepercaya biasanya membatasi akses ke sistem file, dan membatasi penggunaan properti jaringan tertentu. Kit TLE pengembangan dirancang untuk mendukung bahasa tepercaya. Postgre SQL mendukung beberapa bahasa berbeda yang digunakan untuk membuat ekstensi tepercaya atau tidak tepercaya. Sebagai contoh, lihat [PL/Perl Tepercaya dan Tidak Tepercaya](https://www.postgresql.org/docs/current/plperl-trusted.html) di dokumentasi Postgre. SQL Saat Anda membuat ekstensi menggunakan Ekstensi Bahasa Tepercaya, ekstensi tersebut akan menggunakan mekanisme bahasa tepercaya secara inheren.
**TLEekstensi**
*TLEEkstensi adalah ekstensi* Postgre SQL yang dibuat dengan menggunakan kit pengembangan Trusted Language Extensions (TLE).
# Persyaratan untuk menggunakan Ekstensi Bahasa Tepercaya untuk PostgreSQL
Berikut ini adalah persyaratan untuk menyiapkan dan menggunakan kit pengembangan TLE.
+ ** Versi RDS for PostgreSQL** – Ekstensi Bahasa Tepercaya didukung pada RDS for PostgreSQL versi 13.12 dan versi 13 yang lebih tinggi, 14.5 dan versi 14 yang lebih tinggi, dan 15.2 dan versi yang lebih tinggi saja.
+ Jika Anda perlu meningkatkan instans RDS for PostgreSQL, lihat [Upgrade RDS untuk mesin PostgreSQL DB](USER_UpgradeDBInstance.PostgreSQL.md).
+ Jika belum memiliki instans DB Amazon RDS yang menjalankan PostgreSQL, Anda dapat membuatnya. Untuk informasi selengkapnya, lihat Instans DB RDS for PostgreSQL, lihat [Membuat dan menghubungkan ke instans DB PostgreSQL](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md).
+ **Memerlukan hak istimewa `rds_superuser`** – Untuk menyiapkan dan mengonfigurasi ekstensi `pg_tle`, peran pengguna basis data Anda harus memiliki izin peran `rds_superuser`. Secara default, peran ini diberikan kepada `postgres` pengguna yang membuat Instans DB RDS for PostgreSQL.
+ **Memerlukan grup parameter DB kustom** - instans DB RDS for PostgreSQL Anda harus dikonfigurasi dengan grup parameter DB kustom.
+ Jika instans DB RDS for PostgreSQL Anda tidak dikonfigurasi dengan grup parameter DB kustom, Anda harus membuatnya dan mengaitkannya dengan instans DB RDS for PostgreSQL Anda. Untuk ringkasan langkah-langkahnya, lihat [Membuat dan menerapkan grup parameter DB kustom](#PostgreSQL_trusted_language_extension-requirements-create-custom-params).
+ Jika instans DB RDS for PostgreSQL Anda sudah dikonfigurasi menggunakan grup parameter DB kustom, Anda dapat menyiapkan Ekstensi Bahasa Tepercaya. Untuk detailnya, lihat [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md).
## Membuat dan menerapkan grup parameter DB kustom
Gunakan langkah-langkah berikut untuk membuat grup parameter DB kustom dan mengonfigurasi instans DB RDS for PostgreSQL untuk menggunakannya.
### Konsol
**Untuk membuat grup parameter DB kustom dan menggunakannya dengan**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih grup Parameter dari menu Amazon RDS.
1. Pilih **Buat grup parameter**.
1. Di halaman **Detail grup parameter**, masukkan informasi berikut.
+ Untuk **Keluarga grup Parameter**, pilih postgres14.
+ Untuk **Jenis**, pilih Grup Parameter DB.
+ Untuk **Nama grup**, berikan grup parameter Anda nama yang bermakna dalam konteks operasi Anda.
+ Untuk **Deskripsi**, masukkan deskripsi yang berguna sehingga orang lain di tim Anda dapat dengan mudah menemukannya.
1. Pilih **Buat**. Grup parameter DB kustom Anda dibuat di Wilayah AWS. Anda sekarang dapat mengubah instans DB RDS for PostgreSQL untuk menggunakannya dengan mengikuti langkah selanjutnya.
1. Pilih **Basis data** dari menu Amazon RDS.
1. Pilih instans DB RDS for PostgreSQL yang ingin digunakan dengan TLE dari yang tercantum tersebut, lalu pilih **Ubah.**
1. Di halaman Halaman Ubah pengaturan instans DB, cari **Opsi Basis Data** di bagian Konfigurasi tambahan dan pilih grup parameter DB kustom Anda dari pemilih.
1. Pilih **Lanjutkan** untuk menyimpan perubahan.
1. Pilih **Terapkan langsung** sehingga Anda dapat melanjutkan penyiapan instans DB RDS for PostgreSQL untuk menggunakan TLE.
Untuk melanjutkan penyiapan sistem untuk Ekstensi Bahasa Tepercaya, lihat [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md).
Untuk informasi selengkapnya tentang cara menggunakan Grup parameter DB, lihat [Grup parameter DB untuk instans Amazon RDS Aurora DB](USER_WorkingWithDBInstanceParamGroups.md).
### AWS CLI
Anda dapat menghindari penentuan argumen `--region` saat menggunakan perintah CLI dengan mengonfigurasi AWS CLI dengan Wilayah AWS default. Untuk informasi selengkapnya, lihat [Dasar-dasar konfigurasi](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna AWS Command Line Interface *.
**Untuk membuat grup parameter DB kustom dan menggunakannya dengan**
1. Gunakan [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI perintah untuk membuat grup parameter DB kustom berdasarkan untuk Anda. Wilayah AWS
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family postgres14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
Untuk Windows:
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family postgres14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
Grup parameter DB kustom Anda tersedia di Wilayah AWS Anda, sehingga Anda dapat mengubah instans DB RDS for PostgreSQL untuk menggunakannya.
1. Gunakan [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI perintah untuk menerapkan grup parameter DB kustom Anda ke . RDS Anda untuk instance PostgreSQL DB. Perintah ini langsung mem-boot ulang instans yang aktif.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
Untuk Windows:
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
Untuk melanjutkan penyiapan sistem untuk Ekstensi Bahasa Tepercaya, lihat [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md).
Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
# Menyiapkan Ekstensi Bahasa Tepercaya di SQL
Anda dapat menggunakan Konsol Manajemen AWS atau AWS CLI untuk langkah-langkah ini.
Saat menyiapkan Ekstensi Bahasa Tepercaya di untuk instans Postgre SQL DB, Anda menginstalnya di database tertentu untuk digunakan oleh pengguna database yang memiliki izin pada database tersebut.
## Konsol
**Untuk menyiapkan Ekstensi Bahasa Tepercaya**
Lakukan langkah-langkah berikut menggunakan akun yang merupakan anggota grup `rds_superuser` (peran).
1. Masuk ke Konsol Manajemen AWS dan buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih instance . SQL
1. Buka tab **Konfigurasi** untuk instance penulis cluster Anda. RDSuntuk contoh Postgre SQL DB. Di antara detail Instans, temukan tautan **Grup parameter**.
1. Pilih tautan untuk membuka parameter khusus yang terkait dengan cluster DB Anda. RDSuntuk contoh Postgre SQL DB.
1. Di kolom pencarian **Parameter**, ketik `shared_pre` untuk menemukan parameter `shared_preload_libraries`.
1. Pilih **Edit parameter** untuk mengakses nilai properti.
1. Tambahkan `pg_tle` ke daftar di kolom **Nilai**. Gunakan koma untuk memisahkan item dalam daftar nilai.
![\[Gambar parameter shared_preload_libraries dengan pg_tle ditambahkan.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. Reboot untuk instance Postgre SQL DB sehingga perubahan Anda pada parameter berlaku. `shared_preload_libraries`
1. Ketika instans tersedia, verifikasi bahwa `pg_tle` telah diinisialisasi. Gunakan `psql` untuk terhubung ke dan kemudian jalankan perintah berikut.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. Dengan ekstensi `pg_tle` yang diinisialisasi, Anda kini dapat membuat ekstensi.
```
CREATE EXTENSION pg_tle;
```
Anda dapat memverifikasi bahwa ekstensi diinstal dengan menggunakan metacommand `psql` berikut.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. Berikan `pgtle_admin` peran ke nama pengguna utama yang Anda buat untuk saat Anda SQL mengaturnya. Jika Anda menerima opsi default-nya, berarti nilainya `postgres`.
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
Anda dapat memverifikasi bahwa pemberian telah terjadi dengan menggunakan metacommand `psql` seperti yang ditunjukkan pada contoh berikut. Hanya peran `pgtle_admin` dan `postgres` yang ditampilkan dalam output. Untuk informasi selengkapnya, lihat [Memahami peran rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. Tutup sesi `psql` menggunakan metacommand `\q`.
```
\q
```
Untuk mulai membuat TLE ekstensi, lihat[Contoh: Membuat ekstensi bahasa tepercaya menggunakan SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
## AWS CLI
Anda dapat menghindari menentukan `--region` argumen ketika Anda menggunakan CLI perintah dengan mengkonfigurasi AWS CLI dengan default Anda Wilayah AWS. Untuk informasi selengkapnya, lihat [Dasar-dasar konfigurasi](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *AWS Command Line Interface Panduan Pengguna*.
**Untuk menyiapkan Ekstensi Bahasa Tepercaya**
1. Gunakan [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI perintah untuk `pg_tle` menambah `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Gunakan [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI perintah untuk me-reboot dan menginisialisasi SQL perpustakaan. `pg_tle`
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Saat instans tersedia, verifikasikan bahwa `pg_tle` telah diinisialisasi. Gunakan `psql` untuk terhubung ke dan kemudian jalankan perintah berikut.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
Dengan `pg_tle` diinisialisasi, Anda sekarang dapat membuat ekstensi.
```
CREATE EXTENSION pg_tle;
```
1. Berikan `pgtle_admin` peran ke nama pengguna utama yang Anda buat untuk saat Anda SQL mengaturnya. Jika Anda menerima opsi default-nya, berarti nilainya `postgres`.
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. Tutup sesi `psql` seperti berikut.
```
labdb=> \q
```
Untuk mulai membuat TLE ekstensi, lihat[Contoh: Membuat ekstensi bahasa tepercaya menggunakan SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
# Ikhtisar Ekstensi Bahasa Tepercaya untuk Postgre SQL
Ekstensi Bahasa Tepercaya untuk Postgre SQL adalah ekstensi Postgre yang Anda instal di dengan cara yang sama seperti Anda mengatur SQL ekstensi Postgre SQL lainnya. SQL Pada gambar berikut dari database contoh di alat pgAdmin klien, Anda dapat melihat beberapa komponen yang terdiri dari `pg_tle` ekstensi.
![\[Gambar menunjukkan beberapa komponen yang membentuk kit TLE pengembangan.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
Anda dapat melihat detail berikut.
1. Kit SQL pengembangan Trusted Language Extensions (TLE) untuk Postgre dikemas sebagai ekstensi. `pg_tle` Dengan demikian, `pg_tle` ditambahkan ke ekstensi yang tersedia untuk basis data tempat kit ini diinstal.
1. TLEmemiliki skema sendiri,`pgtle`. Skema ini berisi fungsi pembantu (3) untuk menginstal dan mengelola ekstensi yang Anda buat.
1. TLEmenyediakan lebih dari selusin fungsi pembantu untuk menginstal, mendaftar, dan mengelola ekstensi Anda. Untuk mempelajari selengkapnya tentang fungsi ini, lihat [Referensi fungsi untuk Ekstensi Bahasa Tepercaya untuk Postgre SQL](PostgreSQL_trusted_language_extension-functions-reference.md).
Komponen lain dari ekstensi `pg_tle` meliputi:
+ **Peran `pgtle_admin`** – Peran `pgtle_admin` dibuat jika ekstensi `pg_tle` diinstal. Peran ini diistimewakan dan harus diperlakukan semestinya. Sebaiknya Anda mengikuti prinsip *hak akses paling rendah* saat memberikan peran `pgtle_admin` kepada pengguna basis data. Dengan kata lain, berikan `pgtle_admin` peran hanya kepada pengguna database yang diizinkan untuk membuat, menginstal, dan mengelola TLE ekstensi baru, seperti`postgres`.
+ **`pgtle.feature_info`Tabel** — `pgtle.feature_info` Tabel adalah tabel yang dilindungi yang berisi informasi tentang AndaTLEs, kait, dan prosedur dan fungsi tersimpan khusus yang mereka gunakan. Jika Anda memiliki hak istimewa `pgtle_admin`, gunakan fungsi Ekstensi Bahasa Tepercaya berikut untuk menambahkan dan memperbarui informasi tersebut dalam tabel.
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# Membuat ekstensi TLE untuk RDS for PostgreSQL
Anda dapat menginstal ekstensi apa pun yang Anda buat dengan TLE di setiap instans DB RDS for PostgreSQL yang ekstensi `pg_tle`-nya telah diinstal. Ekstensi `pg_tle` dicakup ke basis data PostgreSQL tempat ekstensi diinstal. Ekstensi yang Anda buat menggunakan TLE dicakup ke basis data yang sama.
Gunakan berbagai fungsi `pgtle` untuk menginstal kode yang membentuk ekstensi TLE Anda. Semua fungsi Ekstensi Bahasa Tepercaya berikut memerlukan peran `pgtle_admin`.
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(nama)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension (nama, versi)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## Contoh: Membuat ekstensi bahasa tepercaya menggunakan SQL
Contoh berikut menunjukkan cara membuat ekstensi TLE bernama `pg_distance` yang berisi beberapa fungsi SQL untuk menghitung jarak menggunakan berbagai formula. Dalam daftar, Anda dapat menemukan fungsi untuk menghitung jarak Manhattan dan fungsi untuk menghitung jarak Euclidean. Untuk informasi selengkapnya tentang perbedaan antara formula ini, lihat [Geometri taksi](https://en.wikipedia.org/wiki/Taxicab_geometry) dan [Geometri Euclidean](https://en.wikipedia.org/wiki/Euclidean_geometry) di Wikipedia.
Anda dapat menggunakan contoh ini di instans DB RDS for PostgreSQL Anda sendiri jika Anda memiliki ekstensi `pg_tle` yang diatur seperti yang dijelaskan [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md).
**catatan**
Untuk mengikuti prosedur ini, Anda harus memiliki hak istimewa peran `pgtle_admin`.
**Untuk membuat contoh ekstensi TLE**
Langkah-langkah berikut menggunakan contoh basis data bernama `labdb`. Basis data ini milik pengguna utama `postgres`. Peran `postgres` juga memiliki izin peran `pgtle_admin`.
1. Gunakan `psql` untuk terhubung ke . Instans DB RDS for PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Buat ekstensi TLE bernama `pg_distance` dengan menyalin kode berikut dan menempelkannya ke konsol sesi `psql` Anda.
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
Anda akan melihat output seperti berikut.
```
install_extension
---------------
t
(1 row)
```
Artefak yang membentuk ekstensi `pg_distance` sekarang diinstal di basis data Anda. Artefak ini mencakup file kontrol dan kode untuk ekstensi, yang merupakan item yang harus ada sehingga ekstensi dapat dibuat menggunakan perintah `CREATE EXTENSION`. Dengan kata lain, Anda masih perlu membuat ekstensi agar fungsinya tersedia bagi pengguna basis data.
1. Untuk membuat ekstensi, gunakan perintah `CREATE EXTENSION` seperti yang Anda lakukan untuk ekstensi lainnya. Seperti ekstensi lainnya, pengguna basis data harus memiliki izin `CREATE` dalam basis data.
```
CREATE EXTENSION pg_distance;
```
1. Untuk menguji ekstensi TLE `pg_distance`, Anda dapat menggunakannya untuk menghitung [Jarak Manhattan](https://en.wikipedia.org/wiki/Taxicab_geometry) antara empat titik.
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
Untuk menghitung [Jarak Euclidean](https://en.wikipedia.org/wiki/Euclidean_geometry) antara kumpulan titik yang sama, Anda dapat menggunakan berikut.
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
Ekstensi `pg_distance` memuat fungsi dalam basis data dan membuatnya tersedia bagi setiap pengguna dengan izin pada basis data.
## Mengubah ekstensi TLE
Untuk meningkatkan performa kueri untuk fungsi yang dikemas dalam ekstensi TLE ini, tambahkan dua atribut PostgreSQL berikut ke spesifikasinya.
+ `IMMUTABLE` – Atribut `IMMUTABLE` memastikan bahwa pengoptimal kueri dapat menggunakan pengoptimalan untuk meningkatkan waktu respons kueri. Untuk informasi selengkapnya, lihat [Function Volatility Categories](https://www.postgresql.org/docs/current/xfunc-volatility.html) dalam dokumentasi PostgreSQL.
+ `PARALLEL SAFE` – Atribut `PARALLEL SAFE` adalah atribut lain yang memungkinkan PostgreSQL menjalankan fungsi dalam mode paralel. Untuk informasi selengkapnya, lihat [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) dalam dokumentasi PostgreSQL.
Dalam contoh berikut, Anda dapat melihat bagaimana fungsi `pgtle.install_update_path` digunakan untuk menambahkan atribut ini ke setiap fungsi guna membuat ekstensi TLE `pg_distance` versi `0.2`. Untuk informasi selengkapnya tentang fungsi ini, lihat [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path). Anda harus memiliki peran `pgtle_admin` untuk melakukan tugas ini.
**Untuk memperbarui ekstensi TLE yang ada dan menentukan versi default**
1. Hubungkan ke instans DB RDS for PostgreSQL Anda menggunakan `psql` atau alat klien lainnya, seperti pgAdmin.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Buat ekstensi TLE yang ada dengan menyalin kode berikut dan menempelkannya ke konsol sesi `psql` Anda.
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
Anda akan melihat hasil yang mirip dengan berikut ini.
```
install_update_path
---------------------
t
(1 row)
```
Anda dapat menjadikan versi ekstensi ini sebagai versi default, sehingga pengguna basis data tidak perlu menentukan versi saat mereka membuat atau memperbarui ekstensi di basis data mereka.
1. Untuk menentukan bahwa versi modifikasi (versi 0.2) ekstensi TLE Anda adalah versi default, gunakan fungsi `pgtle.set_default_version` seperti yang ditunjukkan pada contoh berikut.
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
Untuk informasi selengkapnya tentang fungsi ini, lihat [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version).
1. Dengan kode yang diterapkan, Anda dapat memperbarui ekstensi TLE yang diinstal seperti biasa, dengan menggunakan perintah `ALTER EXTENSION ... UPDATE`, seperti yang ditunjukkan di sini:
```
ALTER EXTENSION pg_distance UPDATE;
```
# Menjatuhkan TLE ekstensi Anda dari database
Anda dapat menjatuhkan TLE ekstensi Anda dengan menggunakan `DROP EXTENSION` perintah dengan cara yang sama seperti yang Anda lakukan untuk ekstensi Postgre SQL lainnya. Menghapus ekstensi tidak menghapus file penginstalan yang membentuk ekstensi, yang memungkinkan pengguna membuat ulang ekstensi. Untuk menghapus ekstensi dan file penginstalannya, lakukan proses dua langkah berikut.
**Untuk menjatuhkan TLE ekstensi dan menghapus file instalasinya**
1. Gunakan `psql` atau alat klien lain untuk terhubung ke . RDSuntuk contoh Postgre SQL DB.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Jatuhkan ekstensi seperti yang Anda lakukan pada ekstensi Postgre SQL apa pun.
```
DROP EXTENSION your-TLE-extension
```
Misalnya, jika Anda membuat ekstensi `pg_distance` seperti yang dijelaskan dalam[Contoh: Membuat ekstensi bahasa tepercaya menggunakan SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example), Anda dapat menghilangkan ekstensi sebagai berikut.
```
DROP EXTENSION pg_distance;
```
Anda melihat output yang mengonfirmasi bahwa ekstensi telah dihilangkan, sebagai berikut.
```
DROP EXTENSION
```
Pada titik ini, ekstensi tidak lagi aktif dalam basis data. Namun, file penginstalan dan file kontrolnya masih tersedia di basis data, sehingga pengguna basis data dapat membuat ekstensi lagi jika ingin.
+ Jika Anda ingin membiarkan file ekstensi utuh sehingga pengguna database dapat membuat TLE ekstensi Anda, Anda dapat berhenti di sini.
+ Jika Anda ingin menghapus semua file yang membentuk ekstensi, lanjutkan ke langkah berikutnya.
1. Untuk menghapus semua file penginstalan untuk ekstensi Anda, gunakan fungsi `pgtle.uninstall_extension`. Fungsi ini menghapus semua kode dan file kontrol untuk ekstensi Anda.
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
Misalnya, untuk menghapus semua file penginstalan `pg_distance`, gunakan perintah berikut.
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Menghapus Instalasi Ekstensi Bahasa Tepercaya untuk Postgre SQL
Jika Anda tidak lagi ingin membuat TLE ekstensi Anda sendiri menggunakanTLE, Anda dapat menjatuhkan `pg_tle` ekstensi dan menghapus semua artefak. Tindakan ini termasuk menjatuhkan TLE ekstensi apa pun dalam database dan menjatuhkan skema. `pgtle`
**Untuk menghilangkan ekstensi `pg_tle` dan skema dari basis data**
1. Gunakan `psql` atau alat klien lain untuk terhubung ke . RDSuntuk contoh Postgre SQL DB.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Hilangkan ekstensi `pg_tle` dari basis data. Jika database memiliki TLE ekstensi Anda sendiri yang masih berjalan di database, Anda juga harus menghapus ekstensi tersebut. Untuk melakukannya, Anda dapat menggunakan kata kunci `CASCADE`, seperti yang ditunjukkan berikut ini.
```
DROP EXTENSION pg_tle CASCADE;
```
Jika ekstensi `pg_tle` masih tidak aktif dalam basis data, Anda tidak perlu menggunakan kata kunci `CASCADE`.
1. Hilangkan skema `pgtle`. Tindakan ini akan menghapus semua fungsi manajemen dari basis data.
```
DROP SCHEMA pgtle CASCADE;
```
Perintah ini menampilkan hasil berikut setelah proses selesai.
```
DROP SCHEMA
```
Ekstensi `pg_tle`, skema dan fungsinya, serta semua artefak dihapus. Untuk membuat ekstensi baru menggunakanTLE, melalui proses pengaturan lagi. Untuk informasi selengkapnya, lihat [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md).
# Menggunakan hook PostgreSQL dengan ekstensi TLE
*Hook* adalah mekanisme callback yang tersedia di PostgreSQL yang memungkinkan developer memanggil fungsi kustom atau rutinitas lainnya selama operasi basis data reguler. Kit pengembangan TLE mendukung hook PostgreSQL sehingga Anda dapat mengintegrasikan fungsi kustom dengan perilaku PostgreSQL saat runtime. Misalnya, Anda dapat menggunakan hook untuk mengaitkan proses autentikasi dengan kode kustom Anda sendiri, atau mengubah proses perencanaan dan eksekusi kueri untuk kebutuhan spesifik Anda.
Ekstensi TLE Anda dapat menggunakan hook. Jika hook cakupannya global, ini berlaku di semua basis data. Oleh karena itu, jika ekstensi TLE Anda menggunakan hook global, Anda perlu membuat ekstensi TLE di semua basis data yang dapat diakses pengguna.
Saat menggunakan ekstensi `pg_tle` untuk membuat Ekstensi Bahasa Tepercaya Anda sendiri, Anda dapat menggunakan hook yang tersedia dari SQL API untuk membangun fungsi ekstensi. Anda harus mendaftarkan hook apa pun di `pg_tle`. Untuk beberapa hook, Anda mungkin juga perlu mengatur berbagai parameter konfigurasi. Misalnya, hook pemeriksaan `passcode` dapat diatur ke aktif, nonaktif, wajib. Untuk informasi selengkapnya tentang persyaratan khusus untuk hook `pg_tle` yang tersedia, lihat [Referensi hook untuk Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md).
## Contoh: Membuat ekstensi yang menggunakan hook PostgreSQL
Contoh yang dibahas di bagian ini menggunakan hook PostgreSQL untuk memeriksa kata sandi yang diberikan selama operasi SQL tertentu dan mencegah pengguna basis data mengatur kata sandi mereka ke salah satu basis data yang tercantum dalam tabel `password_check.bad_passwords`. Tabel berisi sepuluh besar pilihan kata sandi yang paling umum digunakan, tetapi mudah dipecahkan.
Untuk menyiapkan contoh ini di instans DB RDS for PostgreSQL, Anda harus sudah menginstal Ekstensi Bahasa Tepercaya. Untuk detailnya, lihat [Menyiapkan Ekstensi Bahasa Tepercaya di SQL](PostgreSQL_trusted_language_extension-setting-up.md).
**Untuk menyiapkan contoh hook pemeriksaan kata sandi**
1. Gunakan `psql` untuk terhubung ke . Instans DB RDS for PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Salin kode dari [Daftar kode hook pemeriksaan kata sandi](#PostgreSQL_trusted_language_extension-example-hook_code_listing) dan tempel ke basis data Anda.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
Setelah ekstensi dimuat ke basis data, Anda akan melihat output seperti berikut.
```
install_extension
-------------------
t
(1 row)
```
1. Jika masih terhubung ke basis data, Anda kini dapat membuat ekstensi.
```
CREATE EXTENSION my_password_check_rules;
```
1. Anda dapat mengonfirmasi bahwa ekstensi telah dibuat dalam basis data dengan menggunakan metacommand `psql` berikut.
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. Buka sesi terminal lain untuk bekerja dengan AWS CLI. Anda perlu mengubah grup parameter DB kustom untuk mengaktifkan hook pemeriksaan kata sandi. Untuk melakukannya, gunakan perintah [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)CLI seperti yang ditunjukkan pada contoh berikut.
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Jika parameter berhasil dihidupkan, Anda akan melihat output seperti berikut.
```
(
"DBParameterGroupName": "docs-lab-parameters-for-tle"
}
```
Mungkin diperlukan waktu beberapa menit agar perubahan pada pengaturan grup parameter diterapkan. Akan tetapi, parameter ini bersifat dinamis, jadi Anda tidak perlu memulai ulang instans DB RDS for PostgreSQL DB untuk menerapkan pengaturan.
1. Buka sesi `psql` dan kirim kueri ke basis data untuk memverifikasi bahwa hook password\$1check telah diaktifkan.
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
Hook password\$1check kini aktif. Anda dapat mengujinya dengan membuat peran baru dan menggunakan salah satu kata sandi yang buruk, seperti pada contoh berikut.
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
Output ini telah diformat agar mudah dibaca.
Contoh berikut menunjukkan bahwa perilaku `\password` metacommand interaktif `pgsql` juga dipengaruhi oleh hook password\$1check.
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
Anda dapat menghilangkan ekstensi TLE ini dan menghapus instalan file sumbernya jika ingin. Untuk informasi selengkapnya, lihat [Menjatuhkan TLE ekstensi Anda dari databaseMenjatuhkan TLE ekstensi Anda dari database](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md).
### Daftar kode hook pemeriksaan kata sandi
Kode contoh yang ditampilkan di sini menentukan spesifikasi untuk ekstensi TLE `my_password_check_rules`. Jika kode ini disalin dan ditempelkan ke basis data, kode untuk ekstensi `my_password_check_rules` akan dimuat ke dalam basis data, dan hook `password_check` akan didaftarkan untuk digunakan oleh ekstensi.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# Menggunakan Tipe Data Kustom di TLE
Postgre SQL mendukung perintah untuk mendaftarkan tipe dasar baru (juga dikenal sebagai tipe skalar) untuk menangani struktur data yang kompleks secara efisien dalam database Anda. Jenis dasar memungkinkan Anda menyesuaikan bagaimana data disimpan secara internal, dan cara mengonversinya ke dan dari representasi tekstual eksternal. Tipe data khusus ini sangat membantu saat memperluas Postgre SQL untuk mendukung domain fungsional di mana tipe bawaan seperti angka atau teks tidak dapat memberikan semantik pencarian yang memadai.
RDSuntuk Postgre SQL memungkinkan Anda membuat tipe data khusus dalam ekstensi bahasa tepercaya Anda dan menentukan fungsi yang mendukung SQL dan mengindeks operasi untuk tipe data baru ini. Jenis data kustom tersedia untuk versi berikut:
+ RDSuntuk Postgre SQL 15.4 dan versi 15 yang lebih tinggi
+ RDSuntuk Postgre SQL 14.9 dan versi 14 yang lebih tinggi
+ RDSuntuk Postgre SQL 13.12 dan versi 13 yang lebih tinggi
Untuk informasi selengkapnya, lihat [Jenis Dasar Bahasa Tepercaya](https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md).
# Referensi fungsi untuk Ekstensi Bahasa Tepercaya untuk Postgre SQL
Lihat dokumentasi referensi berikut tentang fungsi yang tersedia di Ekstensi Bahasa Tepercaya untuk PostgreSQL. Gunakan fungsi-fungsi ini untuk menginstal, mendaftar, memperbarui, dan mengelola *TLEekstensi* Anda, yaitu SQL ekstensi Postgre yang Anda kembangkan menggunakan kit pengembangan Ekstensi Bahasa Tepercaya.
**Topics**
+ [pgtle.available\$1extensions](#pgtle.available_extensions)
+ [pgtle.available\$1extension\$1versions](#pgtle.available_extension_versions)
+ [pgtle.extension\$1update\$1paths](#pgtle.extension_update_paths)
+ [pgtle.install\$1extension](#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](#pgtle.install_update_path)
+ [pgtle.register\$1feature](#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(nama)](#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension (nama, versi)](#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
Fungsi `pgtle.available_extensions` adalah fungsi pengembalian set. Ia mengembalikan semua TLE ekstensi yang tersedia dalam database. Setiap baris yang dikembalikan berisi informasi tentang TLE ekstensi tunggal.
### Prototipe fungsi
```
pgtle.available_extensions()
```
### Peran
Tidak ada.
### Argumen
Tidak ada.
### Output
+ `name`— Nama TLE ekstensi.
+ `default_version`— Versi TLE ekstensi yang akan digunakan saat `CREATE EXTENSION` dipanggil tanpa versi yang ditentukan.
+ `description`— Penjelasan yang lebih rinci tentang TLE ekstensi.
### Contoh penggunaan
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
Fungsi `available_extension_versions` adalah fungsi pengembalian set. Ini mengembalikan daftar semua TLE ekstensi yang tersedia dan versinya. Setiap baris berisi informasi tentang versi tertentu dari TLE ekstensi yang diberikan, termasuk apakah itu memerlukan peran tertentu.
### Prototipe fungsi
```
pgtle.available_extension_versions()
```
### Peran
Tidak ada.
### Argumen
Tidak ada.
### Output
+ `name`— Nama TLE ekstensi.
+ `version`— Versi TLE ekstensi.
+ `superuser`— Nilai ini selalu `false` untuk TLE ekstensi Anda. Izin yang diperlukan untuk membuat TLE ekstensi atau memperbaruinya sama dengan membuat objek lain dalam database yang diberikan.
+ `trusted`— Nilai ini selalu `false` untuk TLE ekstensi.
+ `relocatable`— Nilai ini selalu `false` untuk TLE ekstensi.
+ `schema`— Menentukan nama skema di mana TLE ekstensi diinstal.
+ `requires`— Array yang berisi nama-nama ekstensi lain yang dibutuhkan oleh TLE ekstensi ini.
+ `description`— Penjelasan rinci tentang TLE ekstensi.
Untuk informasi selengkapnya tentang nilai keluaran, lihat [Mengemas Objek Terkait ke dalam Ekstensi > File Ekstensi](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) dalam dokumentasi PostgreSQL.
### Contoh penggunaan
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
Fungsi `extension_update_paths` adalah fungsi pengembalian set. Ini mengembalikan daftar semua jalur pembaruan yang mungkin untuk TLE ekstensi. Setiap baris menyertakan peningkatan atau penurunan versi yang tersedia untuk ekstensi itu. TLE
### Prototipe fungsi
```
pgtle.extension_update_paths(name)
```
### Peran
Tidak ada.
### Argumen
`name`— Nama TLE ekstensi dari mana untuk mendapatkan jalur upgrade.
### Output
+ `source` – Versi sumber untuk pembaruan.
+ `target` – Versi target untuk pembaruan.
+ `path`— Jalur pemutakhiran yang digunakan untuk memperbarui TLE ekstensi dari `source` `target` versi ke versi, misalnya,`0.1--0.2`.
### Contoh penggunaan
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
`install_extension`Fungsi ini memungkinkan Anda menginstal artefak yang membentuk TLE ekstensi Anda di database, setelah itu dapat dibuat menggunakan `CREATE EXTENSION` perintah.
### Prototipe fungsi
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### Peran
Tidak ada.
### Argumen
+ `name`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
+ `version`— Versi TLE ekstensi.
+ `description`— Penjelasan rinci tentang TLE ekstensi. Deskripsi ini ditampilkan di kolom `comment` pada `pgtle.available_extensions()`.
+ `ext`— Isi TLE ekstensi. Nilai ini berisi objek seperti fungsi.
+ `requires`— Parameter opsional yang menentukan dependensi untuk ekstensi ini. TLE Ekstensi `pg_tle` secara otomatis ditambahkan sebagai dependensi.
Banyak dari argumen ini sama dengan yang disertakan dalam file kontrol ekstensi untuk menginstal ekstensi Postgre SQL pada sistem file instance SQL Postgre. Untuk informasi selengkapnya, lihat [File Ekstensi](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) dalam [Kemasan Objek Terkait ke Ekstensi](https://www.postgresql.org/docs/current/extend-extensions.html) dalam dokumentasi PostgreSQL.
### Output
Fungsi ini akan mengembalikan `OK` jika berhasil, dan `NULL` jika terjadi kesalahan.
+ `OK`— TLE Ekstensi telah berhasil dipasang di database.
+ `NULL`— TLE Ekstensi belum berhasil dipasang di database.
### Contoh penggunaan
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
`install_update_path`Fungsi ini menyediakan jalur pembaruan antara dua versi TLE ekstensi yang berbeda. Fungsi ini memungkinkan pengguna TLE ekstensi Anda untuk memperbarui versinya dengan menggunakan `ALTER EXTENSION ... UPDATE` sintaks.
### Prototipe fungsi
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### Peran
`pgtle_admin`
### Argumen
+ `name`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
+ `fromvers`— Versi sumber TLE ekstensi untuk peningkatan.
+ `tovers`— Versi tujuan TLE ekstensi untuk peningkatan.
+ `ext` – Konten pembaruan. Nilai ini berisi objek seperti fungsi.
### Output
Tidak ada.
### Contoh penggunaan
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
`register_feature`Fungsi menambahkan SQL fitur Postgre internal yang ditentukan ke tabel. `pgtle.feature_info` Postgre SQL hook adalah contoh fitur Postgre internal. SQL Kit pengembangan Ekstensi Bahasa Tepercaya mendukung penggunaan kait PostgreSQL. Saat ini, fungsi ini mendukung fitur berikut.
+ `passcheck`— Mendaftarkan hook pemeriksaan kata sandi dengan prosedur atau fungsi Anda yang menyesuaikan perilaku pemeriksaan kata sandi Postgre. SQL
### Prototipe fungsi
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### Peran
`pgtle_admin`
### Argumen
+ `proc` – Nama prosedur atau fungsi yang disimpan untuk digunakan dengan fitur tersebut.
+ `feature` – Nama fitur `pg_tle` (seperti `passcheck`) untuk mendaftar dengan fungsi.
### Output
Tidak ada.
### Contoh penggunaan
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
`pgtle.register_feature_if_not_exists`Fungsi menambahkan SQL fitur Postgre yang ditentukan ke `pgtle.feature_info` tabel dan mengidentifikasi TLE ekstensi atau prosedur atau fungsi lain yang menggunakan fitur tersebut. Untuk informasi selengkapnya tentang hook dan Trusted Language Extensions, lihat [Menggunakan hook PostgreSQL dengan ekstensi TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md).
### Prototipe fungsi
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### Peran
`pgtle_admin`
### Argumen
+ `proc`— Nama prosedur atau fungsi tersimpan yang berisi logika (kode) untuk digunakan sebagai fitur untuk TLE ekstensi Anda. Misalnya, kode `pw_hook`.
+ `feature`— Nama SQL fitur Postgre untuk mendaftar untuk fungsi tersebut. TLE Saat ini, satu-satunya fitur yang tersedia adalah hook `passcheck`. Untuk informasi selengkapnya, lihat [Hook pemeriksaan kata sandi (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Output
Mengembalikan `true` setelah mendaftarkan fitur untuk ekstensi yang ditentukan. Mengembalikan `false` jika fitur sudah terdaftar.
### Contoh penggunaan
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
`set_default_version`Fungsi ini memungkinkan Anda menentukan `default_version` untuk TLE ekstensi Anda. Anda dapat menggunakan fungsi ini untuk menentukan jalur pemutakhiran dan menetapkan versi sebagai default untuk TLE ekstensi Anda. Ketika pengguna database menentukan TLE ekstensi Anda dalam `ALTER EXTENSION ... UPDATE` perintah `CREATE EXTENSION` dan, versi TLE ekstensi Anda dibuat dalam database untuk pengguna tersebut.
Fungsi ini mengembalikan `true` jika berhasil. Jika TLE ekstensi yang ditentukan dalam `name` argumen tidak ada, fungsi mengembalikan kesalahan. Demikian pula, jika TLE ekstensi tidak ada, ia mengembalikan kesalahan. `version`
### Prototipe fungsi
```
pgtle.set_default_version(name text, version text)
```
### Peran
`pgtle_admin`
### Argumen
+ `name`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
+ `version`— Versi TLE ekstensi untuk mengatur default.
### Output
+ `true` – Saat pengaturan versi default berhasil, fungsi mengembalikan `true`.
+ `ERROR`— Mengembalikan pesan kesalahan jika TLE ekstensi dengan nama atau versi tertentu tidak ada.
### Contoh penggunaan
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension(nama)
`uninstall_extension`Fungsi ini menghapus semua versi TLE ekstensi dari database. Fungsi ini mencegah panggilan future `CREATE EXTENSION` dari menginstal TLE ekstensi. Jika TLE ekstensi tidak ada dalam database, kesalahan muncul.
`uninstall_extension`Fungsi tidak akan menjatuhkan TLE ekstensi yang saat ini aktif dalam database. Untuk menghapus TLE ekstensi yang saat ini aktif, Anda perlu memanggil secara eksplisit `DROP EXTENSION` untuk menghapusnya.
### Prototipe fungsi
```
pgtle.uninstall_extension(extname text)
```
### Peran
`pgtle_admin`
### Argumen
+ `extname`— Nama TLE ekstensi yang akan dihapus. Nama ini sama dengan yang digunakan `CREATE EXTENSION` untuk memuat TLE ekstensi untuk digunakan dalam database tertentu.
### Output
Tidak ada.
### Contoh penggunaan
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension (nama, versi)
`uninstall_extension(name, version)`Fungsi ini menghapus versi TLE ekstensi yang ditentukan dari database. Fungsi ini mencegah `CREATE EXTENSION` dan `ALTER EXTENSION` dari menginstal atau memperbarui TLE ekstensi ke versi yang ditentukan. Fungsi ini juga menghapus semua jalur pembaruan untuk versi TLE ekstensi yang ditentukan. Fungsi ini tidak akan menghapus instalasi TLE ekstensi jika saat ini aktif dalam database. Anda harus secara eksplisit memanggil `DROP EXTENSION` untuk menghapus ekstensi. TLE Untuk menghapus semua versi TLE ekstensi, lihat[pgtle.uninstall\$1extension(nama)](#pgtle.uninstall_extension-name).
### Prototipe fungsi
```
pgtle.uninstall_extension(extname text, version text)
```
### Peran
`pgtle_admin`
### Argumen
+ `extname`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
+ `version`— Versi TLE ekstensi untuk menghapus instalasi dari database.
### Output
Tidak ada.
### Contoh penggunaan
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
`uninstall_extension_if_exists`Fungsi ini menghapus semua versi TLE ekstensi dari database yang diberikan. Jika TLE ekstensi tidak ada, fungsi kembali diam-diam (tidak ada pesan kesalahan yang muncul). Jika ekstensi yang ditentukan sedang aktif dalam basis data, fungsi ini tidak akan menghapusnya. Anda harus secara eksplisit memanggil `DROP EXTENSION` untuk menghapus TLE ekstensi sebelum menggunakan fungsi ini untuk menghapus artefaknya.
### Prototipe fungsi
```
pgtle.uninstall_extension_if_exists(extname text)
```
### Peran
`pgtle_admin`
### Argumen
+ `extname`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
### Output
Fungsi `uninstall_extension_if_exists` mengembalikan `true` setelah menghapus instalasi ekstensi yang ditentukan. Jika ekstensi yang ditentukan tidak ada, fungsi akan mengembalikan `false`.
+ `true`— Kembali `true` setelah mencopot pemasangan TLE ekstensi.
+ `false`— Kembali `false` ketika TLE ekstensi tidak ada dalam database.
### Contoh penggunaan
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
`uninstall_update_path`Fungsi menghapus jalur pembaruan tertentu dari TLE ekstensi. Fungsi ini membuat `ALTER EXTENSION ... UPDATE TO` tidak dapat menggunakan ekstensi ini sebagai jalur pembaruan.
Jika TLE ekstensi saat ini digunakan oleh salah satu versi di jalur pembaruan ini, ekstensi tetap ada di database.
Jika jalur pembaruan yang ditentukan tidak ada, fungsi akan memunculkan kesalahan.
### Prototipe fungsi
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### Peran
`pgtle_admin`
### Argumen
+ `extname`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
+ `fromvers`— Versi sumber TLE ekstensi yang digunakan pada jalur pembaruan.
+ `tovers`— Versi tujuan TLE ekstensi yang digunakan pada jalur pembaruan.
### Output
Tidak ada.
### Contoh penggunaan
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
`uninstall_update_path_if_exists`Fungsinya mirip `uninstall_update_path` dengan menghapus jalur pembaruan yang ditentukan dari TLE ekstensi. Namun, jika jalur pembaruan tidak ada, fungsi ini tidak memunculkan pesan kesalahan. Sebaliknya, fungsi mengembalikan `false`.
### Prototipe fungsi
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### Peran
`pgtle_admin`
### Argumen
+ `extname`— Nama TLE ekstensi. Nilai ini digunakan saat memanggil `CREATE EXTENSION`.
+ `fromvers`— Versi sumber TLE ekstensi yang digunakan pada jalur pembaruan.
+ `tovers`— Versi tujuan TLE ekstensi yang digunakan pada jalur pembaruan.
### Output
+ `true`— Fungsi telah berhasil memperbarui jalur untuk TLE ekstensi.
+ `false`— Fungsi tidak dapat memperbarui jalur untuk TLE ekstensi.
### Contoh penggunaan
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
Fungsi `unregister_feature` menyediakan cara untuk menghapus fungsi yang terdaftar untuk menggunakan fitur `pg_tle`, seperti hook. Untuk informasi tentang pendaftaran fitur, lihat [pgtle.register\$1feature](#pgtle.register_feature).
### Prototipe fungsi
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### Peran
`pgtle_admin`
### Argumen
+ `proc` – Nama fungsi tersimpan untuk mendaftar dengan fitur `pg_tle`.
+ `feature` – Nama fitur `pg_tle` untuk mendaftar dengan fungsi. Misalnya, `passcheck` adalah fitur yang dapat didaftarkan untuk digunakan oleh ekstensi bahasa tepercaya yang Anda kembangkan. Untuk informasi selengkapnya, lihat [Hook pemeriksaan kata sandi (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Output
Tidak ada.
### Contoh penggunaan
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
Fungsi `unregister_feature` menyediakan cara untuk menghapus fungsi yang terdaftar untuk menggunakan fitur `pg_tle`, seperti hook. Untuk informasi selengkapnya, lihat [Menggunakan hook PostgreSQL dengan ekstensi TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md). Mengembalikan `true` setelah berhasil membatalkan pendaftaran fitur. Mengembalikan `false` jika fitur tidak terdaftar.
Untuk informasi tentang mendaftarkan `pg_tle` fitur untuk TLE ekstensi Anda, lihat[pgtle.register\$1feature](#pgtle.register_feature).
### Prototipe fungsi
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### Peran
`pgtle_admin`
### Argumen
+ `proc` – Nama fungsi tersimpan yang terdaftar untuk menyertakan fitur `pg_tle`.
+ `feature` – Nama fitur `pg_tle` yang terdaftar dengan ekstensi bahasa tepercaya.
### Output
Mengembalikan `true` atau `false`, sebagai berikut.
+ `true` – Fungsi telah berhasil membatalkan pendaftaran fitur dari ekstensi.
+ `false`— Fungsi tidak dapat membatalkan pendaftaran fitur dari TLE ekstensi.
### Contoh penggunaan
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Referensi hook untuk Trusted Language Extensions for PostgreSQL
Trusted Language Extensions for PostgreSQL mendukung hook PostgreSQL. *Hook* adalah mekanisme panggilan balik internal yang tersedia bagi developer untuk memperluas fungsionalitas inti PostgreSQL. Dengan hook, developer dapat mengimplementasikan fungsi atau prosedurnya sendiri untuk digunakan dalam berbagai operasi basis data, sehingga mengubah perilaku PostgreSQL dalam beberapa cara. Misalnya, Anda dapat menggunakan hook `passcheck` untuk menyesuaikan cara PostgreSQL menangani kata sandi yang diberikan saat membuat atau mengubah kata sandi untuk pengguna (peran).
Lihat dokumentasi berikut untuk mempelajari kait passcheck yang tersedia untuk ekstensi TLE Anda. Untuk mempelajari lebih lanjut tentang kait yang tersedia termasuk hook autentikasi klien, lihat kait [Ekstensi Bahasa Tepercaya](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md).
## Hook pemeriksaan kata sandi (passcheck)
Hook `passcheck` digunakan untuk menyesuaikan perilaku PostgreSQL selama proses pemeriksaan kata sandi untuk perintah SQL dan metacommand `psql` berikut.
+ `CREATE ROLE username ...PASSWORD` – Untuk informasi selengkapnya, lihat [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) dalam dokumentasi PostgreSQL.
+ `ALTER ROLE username...PASSWORD` – Untuk informasi selengkapnya, lihat [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) dalam dokumentasi PostgreSQL.
+ `\password username` – Metacommand `psql` interaktif ini secara aman mengubah kata sandi untuk pengguna yang ditentukan dengan hashing kata sandi sebelum menggunakan sintaks `ALTER ROLE ... PASSWORD` secara transparan. Metacommand adalah pembungkus aman untuk perintah `ALTER ROLE ... PASSWORD`, sehingga hook diterapkan untuk perilaku metacommand `psql`.
Untuk contohnya, lihat [Daftar kode hook pemeriksaan kata sandi](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing).
**Contents**
+ [Prototipe fungsi](#passcheck_hook-prototype)
+ [Pendapat](#passcheck_hook-arguments)
+ [Konfigurasi](#passcheck_hook-configuration)
+ [Catatan penggunaan](#passcheck_hook-usage)
### Prototipe fungsi
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### Pendapat
Fungsi hook `passcheck` memiliki argumen berikut.
+ `username` – Nama (sebagai teks) dari peran (nama pengguna) yang mengatur kata sandi.
+ `password` – Kata sandi yang di-hash atau teks biasa. Kata sandi yang dimasukkan harus sesuai dengan jenis yang ditentukan dalam `password_type`.
+ `password_type` – Menentukan format `pgtle.password_type` kata sandi. Format ini dapat berupa salah satu opsi berikut.
+ `PASSWORD_TYPE_PLAINTEXT` – Kata sandi teks biasa.
+ `PASSWORD_TYPE_MD5`— Kata sandi yang telah di-hash menggunakan algoritma MD5 (message digest 5).
+ `PASSWORD_TYPE_SCRAM_SHA_256` – Kata sandi yang telah di-hash menggunakan algoritma SCRAM-SHA-256.
+ `valid_until` – Menentukan waktu ketika kata sandi menjadi tidak valid. Argumen ini opsional. Jika Anda menggunakan argumen ini, tentukan waktu sebagai nilai `timestamptz`.
+ `valid_null` – Jika Boolean ini diatur ke `true`, opsi `valid_until` diatur ke `NULL`.
### Konfigurasi
Fungsi `pgtle.enable_password_check` mengontrol apakah hook passcheck aktif. Hook passcheck memiliki tiga pengaturan yang memungkinkan.
+ `off` – Menonaktifkan hook pemeriksaan kata sandi `passcheck`. Ini adalah nilai default.
+ `on` – Mengaktifkan hook pemeriksaan kata sandi `passcode` sehingga kata sandi diperiksa di tabel.
+ `require` – Memerlukan hook pemeriksaan kata sandi untuk didefinisikan.
### Catatan penggunaan
Untuk mengaktifkan atau menonaktifkan hook `passcheck`, Anda perlu memodifikasi grup parameter DB kustom untuk instans DB RDS for PostgreSQL Anda.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Untuk Windows:
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```