Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# 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);
```