Bekerja dengan replika baca untuk Amazon RDS untuk Postgre SQL - Layanan Basis Data Relasional Amazon
Pendekodean logis pada replika bacaBaca batasan replika dengan Postgre SQLBaca konfigurasi replika dengan Postgre SQLMenggunakan Replika baca kaskadeMembuat replika baca cascading lintas wilayahBagaimana replikasi bekerja untuk versi RDS SQL Postgre yang berbedaMemantau dan menyetel proses replikasiPemecahan masalah RDS untuk replika baca Postgre SQL

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Bekerja dengan replika baca untuk Amazon RDS untuk Postgre SQL

Anda dapat menskalakan pembacaan untuk Amazon RDS untuk instans SQL DB Postgre dengan menambahkan replika baca ke instans. Seperti mesin RDS database Amazon lainnya, RDS untuk Postgre SQL menggunakan mekanisme replikasi asli Postgre SQL untuk menjaga replika baca tetap up to date dengan perubahan pada sumber DB. Untuk informasi umum tentang replika baca dan AmazonRDS, lihatMenggunakan replika baca instans DB.

Berikut ini, Anda dapat menemukan informasi khusus untuk bekerja dengan replika baca dengan RDS untuk SQL Postgre.

Pendekodean logis pada replika baca

RDSuntuk Postgre SQL mendukung replikasi logis dari standbys dengan Postgre 16.1. SQL 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 Baca konfigurasi replika dengan Postgre SQL.

    • Untuk mengaktifkan replikasi logis untuk instance Postgre SQL DB yang baru dibuat RDS - Buat grup parameter kustom DB baru dan atur parameter statis ke. rds.logical_replication 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 Postgre SQL DB yang sudah ada RDS — Ubah grup parameter kustom DB dari instans DB sumber dan replika baca fisiknya untuk mengatur parameter statis ke. rds.logical_replication 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 instance DB yang menjalankan mesin database Postgre SQL.

    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 SELECT kueri untuk memverifikasi detail publikasi yang dibuat pada instans DB sumber dan instance 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 instance replika logis - Buat yang lain RDS untuk instance Postgre SQL DB sebagai contoh replika logis. Pastikan itu VPC diatur dengan benar untuk memastikan bahwa instance replika logis ini dapat mengakses instance 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 SELECT kueri untuk memverifikasi detail langganan pada contoh 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)

Baca batasan replika dengan Postgre SQL

Berikut ini adalah batasan untuk replika SQL baca Postgre:

catatan

Replika baca RDS untuk instans Postgre SQL Multi-AZ dan Single-AZ DB yang menjalankan Postgre SQL versi 12 dan sebelumnya, reboot secara otomatis untuk menerapkan rotasi kata sandi selama jendela pemeliharaan 60 hingga 90 hari. Jika koneksi dari replika ke sumber terputus sebelum reboot terjadwal, instance akan tetap di-boot ulang agar replikasi dapat dilanjutkan.

  • Replika SQL baca postgre hanya bisa dibaca. Meskipun replika baca bukan instance DB yang dapat ditulis, Anda dapat mempromosikannya menjadi mandiri RDS untuk instance SQL Postgre DB. Namun, prosesnya tidak dapat dikembalikan.

  • Anda tidak dapat membuat replika baca dari replika baca lain jika instans Postgre SQL DB Anda RDS menjalankan versi Postgre lebih awal dari 14.1SQL. RDSuntuk Postgre SQL mendukung cascading read replicas on RDS untuk Postgre SQL versi 14.1 dan rilis yang lebih tinggi saja. Untuk informasi selengkapnya, lihat Menggunakan replika baca cascading dengan for Postgre RDS SQL.

  • Jika Anda mempromosikan replika SQL baca Postgre, itu menjadi instance DB yang dapat ditulis. Itu berhenti menerima file log (WAL) write-ahead dari instance DB sumber, dan itu bukan lagi instance hanya-baca. Anda dapat membuat replika baca baru dari instans DB yang dipromosikan seperti yang Anda lakukan untuk instans Postgre SQL DB apa punRDS. Untuk informasi selengkapnya, lihat Mempromosikan replika baca menjadi instans DB mandiri.

  • Jika Anda mempromosikan replika SQL baca Postgre dari dalam rantai replikasi (serangkaian replika baca berjenjang), setiap replika baca hilir yang ada terus menerima file dari instance yang dipromosikan secara otomatis. WAL Untuk informasi selengkapnya, lihat Menggunakan replika baca cascading dengan for Postgre RDS SQL.

  • Jika tidak ada transaksi pengguna yang berjalan pada instans DB sumber, replika SQL baca Postgre terkait melaporkan jeda replikasi hingga lima menit. Replica lag dihitung sebagaicurrentTime - lastCommitedTransactionTimestamp, yang berarti bahwa ketika tidak ada transaksi yang sedang diproses, nilai replica lag meningkat untuk jangka waktu tertentu sampai segmen write-ahead log () WAL beralih. Secara default RDS untuk Postgre SQL mengganti WAL segmen setiap 5 menit, yang menghasilkan catatan transaksi dan penurunan lag yang dilaporkan.

  • Anda tidak dapat mengaktifkan pencadangan otomatis untuk replika SQL baca Postgre untuk versi Postgre lebih awal dari RDS 14.1. SQL Pencadangan otomatis untuk replika baca hanya didukung RDS untuk Postgre SQL 14.1 dan versi yang lebih tinggi. RDSUntuk Postgre SQL 13 dan versi sebelumnya, buat snapshot dari replika baca jika Anda ingin cadangannya.

  • Point-in-time recovery (PITR) tidak didukung untuk replika baca. Anda dapat menggunakan PITR dengan instance utama (penulis) saja, bukan replika baca. Untuk mempelajari selengkapnya, lihat Memulihkan instans DB ke waktu tertentu untuk Amazon RDS.

Baca konfigurasi replika dengan Postgre SQL

RDSuntuk Postgre SQL menggunakan replikasi streaming SQL asli Postgre untuk membuat salinan hanya-baca dari instance DB sumber. Instans DB replika baca ini adalah replika fisik yang dibuat secara asinkron dari instans DB sumber. Ini dibuat oleh koneksi khusus yang mentransmisikan data write ahead log (WAL) dari instance DB sumber ke replika baca. Untuk informasi selengkapnya, lihat Streaming Replikasi dalam dokumentasi SQL Postgre.

Postgre secara SQL asinkron mengalirkan perubahan database ke koneksi aman ini karena dibuat pada instance 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 instance Postgre DB SQL.

Postgre SQL menggunakan peran replikasi untuk melakukan replikasi streaming. Peran ini memiliki hak akses, tetapi Anda tidak dapat menggunakannya untuk mengubah data apa pun. Postgre SQL menggunakan satu proses untuk menangani replikasi.

Anda dapat membuat replika SQL baca Postgre 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. RDSAdapun Postgre SQL 14.1, Anda juga dapat membuat hingga tiga tingkat replika baca dalam rantai (kaskade) dari instance DB sumber. Untuk informasi selengkapnya, lihat Menggunakan replika baca cascading dengan for Postgre RDS SQL. 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 Postgre SQL DB Anda RDS Wilayah AWS 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 In-region dan Cross-region sedikit berbeda tergantung pada versi Postgre SQL seperti yang RDS dijelaskan dalam. Cara kerja replikasi streaming untuk versi RDS SQL Postgre yang berbeda

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 mereka 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 parameter pada replika baca menjadi nilai yang sama seperti pada instance DB sumber.

RDSuntuk Postgre SQL read replika memiliki akses ke database eksternal yang tersedia melalui pembungkus data asing (FDWs) pada instance DB sumber. Misalnya, misalkan instance Postgre SQL DB Anda RDS menggunakan mysql_fdw pembungkus untuk mengakses data dari RDS untuk My. SQL 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 RDS replika SQL baca Postgre 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 dimulai ulang, tergantung pada SQL versi RDS for Postgre, sebagai berikut:

  • Postgre SQL 13 dan versi yang lebih tinggi - Memulai ulang tidak diperlukan. Replika baca secara otomatis disinkronkan dengan replika primer baru. Namun, dalam beberapa kasus, aplikasi klien Anda mungkin menyimpan rincian 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 RDS dasar Amazon.

  • Postgre SQL 12 dan semua versi sebelumnya - Replika baca dimulai ulang secara otomatis setelah gagal ke replika siaga karena siaga (sekarang primer) memiliki alamat IP yang berbeda dan nama instance 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 membuat siaga replika Anda di Availability Zone (AZ) lain. Membuat replika baca Anda sebagai instans DB Multi-AZ tidak tergantung pada apakah basis data sumber adalah instans DB Multi-AZ.

Menggunakan replika baca cascading dengan for Postgre RDS SQL

Pada versi 14.1, RDS untuk Postgre SQL mendukung replika baca berjenjang. Dengan replika baca cascading, Anda dapat menskalakan pembacaan tanpa menambahkan overhead ke sumber RDS Anda untuk instance Postgre DB. SQL Pembaruan pada WAL log tidak dikirim oleh instans DB sumber ke setiap replika baca. Sebagai gantinya, setiap replika baca dalam seri cascading mengirimkan pembaruan WAL log ke replika baca berikutnya dalam seri. Hal ini akan mengurangi beban pada instans DB sumber.

Dengan replika baca cascading, instans Postgre SQL DB Anda RDS mengirimkan WAL data ke replika baca pertama dalam rantai. Replika baca itu kemudian mengirimkan WAL data ke replika kedua dalam rantai, dan seterusnya. Hasil akhirnya adalah bahwa semua replika baca dalam rantai memiliki perubahan dari instance RDS for Postgre SQL DB, tetapi tanpa overhead hanya pada instance DB sumber.

Anda dapat membuat serangkaian hingga tiga replika baca dalam rantai dari sumber RDS untuk instance Postgre SQL DB. Misalnya, Anda memiliki instance RDS untuk Postgre SQL 14.1 DB,. 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. Serangkaian contoh RDS lengkap dari instans DB SQL sumber Postgre hingga akhir serangkaian replika baca berjenjang dapat terdiri dari paling banyak empat instance DB.

Agar replika baca cascading berfungsi, aktifkan pencadangan otomatis untuk Postgre Anda. RDS SQL Buat replika baca terlebih dahulu dan kemudian nyalakan pencadangan otomatis pada instance RDS for SQL Postgre DB. Prosesnya sama dengan mesin Amazon RDS DB 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

Untuk replika baca cascading, RDS untuk Postgre SQL 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 for Postgre RDS SQL

RDSuntuk Postgre SQL 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 instance RDS for Postgre SQL DB dengan versi 14.1 atau lebih tinggi,rpg-db-main, untuk melakukan hal berikut:

  1. Mulailah dengan rpg-db-main (US- EAST -1), buat replika baca lintas wilayah pertama dalam rantai, read-replica-1 (US- WEST -2).

  2. Menggunakan Cross-region pertama read-replica-1 (US- WEST -2), buat replika baca kedua dalam rantai, read-replica-2 (US- WEST -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 instance RDS for Postgre SQL DB dengan versi 14.1 atau lebih tinggi,rpg-db-main, untuk melakukan hal berikut:

  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, read-replica-2 (US- WEST -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.

Untuk informasi selengkapnya tentang keuntungan menggunakan replikasi, lihat Tentang replikasi di Cloud. SQL

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 versi RDS SQL Postgre yang berbeda

Seperti dibahas dalamBaca konfigurasi replika dengan Postgre SQL, RDS untuk Postgre SQL menggunakan protokol replikasi streaming asli Postgre SQL untuk mengirim WAL data dari instance DB sumber. Ini mengirimkan WAL data sumber untuk membaca replika untuk replika baca In-region dan Cross-region. Dengan versi 9.4, Postgre SQL memperkenalkan slot replikasi fisik sebagai mekanisme pendukung untuk proses replikasi.

Slot replikasi fisik mencegah instance DB sumber menghapus WAL data sebelum dikonsumsi oleh semua replika baca. Setiap replika baca memiliki slot fisiknya sendiri pada instans DB sumber. Slot melacak yang tertua WAL (dengan nomor urut logis,LSN) yang mungkin diperlukan oleh replika. Setelah semua slot dan koneksi DB berkembang melampaui given WAL (LSN), yang LSN menjadi kandidat untuk dihapus di pos pemeriksaan berikutnya.

Amazon RDS menggunakan Amazon S3 untuk mengarsipkan WAL data. 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 SQL versi Postgre dan mekanisme pendukung untuk In-region dan Cross-region yang digunakan oleh untuk Postgre. RDS SQL

Versi Dalam Wilayah Lintas Wilayah
Postgre SQL 14.1 dan versi yang lebih tinggi

  • Slot replikasi

  • Arsip Amazon S3

  • Slot replikasi
Postgre SQL 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 Postgre SQL

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. Default RDS untuk Postgre SQL 13 dan rilis yang lebih tinggi adalah 20. 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 di dokumentasi Postgre. SQL

wal_keep_segments

wal_keep_segmentsParameter menentukan jumlah file write-ahead log (WAL) yang disimpan 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 menghasilkan kesalahan replikasi dan memulai pemulihan pada replika baca. Ia melakukannya dengan memutar ulang WAL data arsip instans DB sumber dari Amazon S3. Proses pemulihan ini berlanjut sampai replika baca tersebut dapat melanjutkan replikasi streaming. Anda dapat melihat proses ini beraksi seperti yang ditangkap oleh SQL log masuk Postgre. Contoh: Bagaimana replika baca pulih dari interupsi replikasi

catatan

Dalam Postgre SQL versi 13, wal_keep_segments parameter 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_segment dan wal_keep_size dalam dokumentasi Postgre. SQL

max_slot_wal_keep_size

max_slot_wal_keep_sizeParameter mengontrol jumlah WAL data yang disimpan oleh instans Postgre SQL DB di pg_wal direktori untuk melayani slot. RDS Parameter ini digunakan untuk konfigurasi yang menggunakan slot replikasi. Nilai default untuk parameter ini adalah-1, artinya tidak ada batasan berapa banyak WAL data yang disimpan pada instance DB sumber. Untuk informasi tentang cara memantau slot replikasi Anda, lihat Memantau slot replikasi untuk instans RDS SQL Postgre DB Anda.

Untuk informasi selengkapnya tentang parameter ini, lihat max_slot_wal_keep_size dalam dokumentasi Postgre. SQL

Setiap kali aliran yang menyediakan WAL data ke replika baca terputus, Postgre SQL beralih ke mode pemulihan. Ini mengembalikan replika baca dengan menggunakan WAL data yang diarsipkan dari Amazon S3 atau dengan menggunakan WAL data yang terkait dengan slot replikasi. Ketika proses ini selesai, Postgre SQL membangun kembali 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 instance RDS for Postgre SQL DB yang menjalankan Postgre SQL versi 12.9 Wilayah AWS sama dengan DB sumber, jadi slot replikasi tidak digunakan. Proses pemulihannya sama untuk instans Postgre SQL DB lainnya RDS yang menjalankan Postgre SQL lebih awal dari versi 14.1 dengan replika baca In-region.

Ketika replika baca kehilangan kontak dengan instans DB sumber, Amazon RDS mencatat masalah di log sebagai FATAL: could not receive data from WAL stream pesan, bersama dengan file. ERROR: requested WAL segment ... has already been removed Seperti yang ditunjukkan pada baris tebal, Amazon RDS memulihkan replika dengan memutar ulang file yang diarsipkan. WAL 

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

Ketika Amazon RDS memutar ulang WAL data arsip yang cukup pada replika untuk mengejar ketinggalan, streaming ke replika baca dimulai lagi. Saat streaming dilanjutkan, Amazon RDS menulis entri ke file log yang mirip dengan 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 transaksiIDs, 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 primer, Amazon RDS akan secara otomatis menyesuaikan parameter replika dan me-restart mesin.

Parameter yang terpengaruh adalah:

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

Untuk menghindari RDS reboot replika karena memori yang tidak mencukupi, kami sarankan untuk menerapkan perubahan parameter sebagai reboot bergulir ke 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 Postgre SQL DB Anda RDS dan membaca replika. 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 RDS ReplicaLag metrik Amazon. Untuk mempelajari selengkapnya tentang ReplicaLag dan metrik lainnya untuk AmazonRDS, lihat CloudWatch Metrik Amazon untuk Amazon RDS.

  • Periksa SQL log Postgre untuk informasi yang dapat Anda gunakan untuk menyesuaikan pengaturan Anda. Di setiap pos pemeriksaan, log Postgre menangkap jumlah file SQL log transaksi daur 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, misalkan SQL log Postgre di checkpoint complete menunjukkan 35 recycled untuk 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 SQL log Postgre secara langsung, Anda dapat menggunakan Amazon CloudWatch untuk memeriksa metrik yang telah dikumpulkan. Misalnya, Anda dapat memeriksa nilai TransactionLogsGeneration metrik untuk melihat berapa banyak WAL data yang dihasilkan oleh instans DB sumber. Dalam beberapa kasus, beban kerja pada instans DB Anda mungkin menghasilkan sejumlah besar WAL data. 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 RDS SQL Postgre DB Anda

Semua versi RDS untuk Postgre SQL menggunakan slot replikasi untuk replika baca lintas wilayah. RDSuntuk Postgre SQL 14.1 dan versi yang lebih tinggi gunakan slot replikasi untuk replika baca di wilayah. Replika baca di wilayah juga menggunakan Amazon S3 untuk mengarsipkan data. WAL Dengan kata lain, jika instans DB dan replika baca Anda menjalankan Postgre SQL 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 instance Postgre SQL DB Anda RDS dengan menanyakan tampilan, sebagai pg_replication_slots 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)

reservedNilai berarti bahwa jumlah WAL data yang dipegang oleh slot berada dalam batas-batas max_wal_size parameter. wal_status Dengan kata lain, slot replikasi berukuran sesuai. Kemungkinan nilai lainnya adalah sebagai berikut:

  • extended— Slot melebihi max_wal_size pengaturan, tetapi WAL data dipertahankan.

  • unreserved— Slot tidak lagi memiliki semua WAL data yang diperlukan. Beberapa di antaranya akan dihapus di checkpoint berikutnya.

  • lostBeberapa WAL data 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 – Menampilkan daftar slot yang memiliki lag paling banyak, yaitu yang paling tertinggal dari replika primer. Lag ini dapat dikaitkan dengan replika baca, tetapi juga koneksi.

  • TransactionLogsDiskUsage— Menunjukkan berapa banyak penyimpanan yang digunakan untuk WAL data. Ketika replika baca mengalami lag yang signifikan, nilai metrik ini dapat meningkat secara substansial.

Untuk mempelajari lebih lanjut tentang menggunakan Amazon CloudWatch dan metriknya RDS untuk PostgreSQL, lihat. Memantau metrik RDSAmazon Amazon dengan Amazon CloudWatch Untuk informasi selengkapnya tentang memantau replikasi streaming pada instans Postgre SQL DB AndaRDS, lihat Praktik terbaik untuk replikasi Amazon RDS Postgre SQL di Blog Database.AWS

Pemecahan masalah RDS untuk replika baca Postgre SQL

Berikut ini, Anda dapat menemukan ide pemecahan masalah untuk beberapa hal umum RDS 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 WAL replikasi, sehingga meningkatkan kelambatan replikasi. Oleh karena itu, pastikan untuk memantau runtime transaksi ini dengan tampilan SQL pg_stat_activity Postgre.

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