Menggunakan replika baca untuk Amazon RDS for PostgreSQL - Layanan Basis Data Relasional Amazon
Pendekodean logis pada replika bacaBatasan replika baca dengan PostgreSQLKonfigurasi replika baca dengan PostgreSQLMenggunakan replika baca kaskadeMembuat replika baca cascading lintas wilayahCara kerja replikasi untuk berbagai versi PostgreSQLMemantau dan menyetel proses replikasiPemecahan masalah untuk RDS untuk PostgreSQL baca replika

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.

Di bagian berikut ini, Anda dapat menemukan informasi spesifik untuk menggunakan replika baca dengan RDS for PostgreSQL.

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.

    • 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 Mengaitkan grup parameter DB dengan instans DB di Amazon RDS Aurora.

    • 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 Memodifikasi parameter dalam grup parameter DB di Amazon RDS Aurora.

    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)

  2. 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.

    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

  3. 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)

  4. 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. 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)

  5. 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)

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.

  • 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.

  • 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.

  • 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.

  • 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 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 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. 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.

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. 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.

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 termasukoracle_fdw,postgres_fdw, dantds_fdw. Untuk informasi selengkapnya, lihat Bekerja dengan pembungkus data asing yang didukung untuk Amazon RDS SQL.

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.

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.

  • 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. Untuk mempelajari selengkapnya tentang cara kerja replika baca dalam deployment Multi-AZ, lihat Menggunakan replika baca instans DB.

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. Pembuatan replika baca Anda sebagai instans DB Multi-AZ tidak tergantung pada apakah basis data sumber merupakan instans DB Multi-AZ.

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.

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.

    • Replika ini sekarang menjadi instans DB baca/tulis 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.

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

  2. Menggunakan Cross-region pertama read-replica-1 (US-WEST-2), buat replika baca kedua dalam rantai, (US-WEST-2). read-replica-2

  3. Menggunakanread-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).

  2. Menggunakan read-replica-1 (US-EAST-1), buat replika baca Lintas wilayah pertama dalam rantai, (US-WEST-2). read-replica-2

  3. 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, 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

  • Slot replikasi

  • Arsip Amazon S3

  • Slot replikasi
PostgreSQL 13 dan versi yang lebih rendah

  • Arsip Amazon S3

  • Slot replikasi

Untuk informasi selengkapnya, lihat Memantau dan menyetel proses replikasi.

Memahami parameter yang mengontrol replikasi PostgreSQL

Parameter berikut memengaruhi proses replikasi dan menentukan seberapa baik replika baca dalam mengikuti instans DB sumber:

max_wal_senders

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_wal_senders dalam dokumentasi PostgreSQL.

catatan

max_wal_sendersadalah parameter statis yang memerlukan reboot instance DB agar perubahan diterapkan.

wal_keep_segments

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 replikasi.

catatan

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_keep_segments dan wal_keep_size dalam dokumentasi PostgreSQL.

max_slot_wal_keep_size

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.

Untuk informasi selengkapnya tentang parameter ini, lihat 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_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

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.

  • 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 Untuk informasi selengkapnya tentang memantau replikasi streaming pada instans DB RDS for PostgreSQL Anda, lihat Praktik terbaik untuk replikasi Amazon RDS PostgreSQL di Blog Basis Data AWS .

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);