Cara kerja replikasi streaming untuk berbagai versi RDS for PostgreSQL - Layanan Basis Data Relasional Amazon
Memahami parameter yang mengontrol replikasiMengatur parameter yang mengontrol memori bersama

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

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.