Mengkonfigurasi replikasi tertunda dengan RDS untuk PostgreSQL - Layanan Basis Data Relasional Amazon
Ikhtisar dan ManfaatMengaktifkan dan MengkonfigurasiMengelola Pemulihan Replikasi TertundaPertimbangan perencanaanMemahami keterbatasan

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

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.

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

  3. Terapkan grup parameter ke instance replika baca yang ingin Anda konfigurasikan untuk replikasi tertunda.

  4. 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() danpg_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_superuser.

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_target

  • recovery_target_lsn

  • recovery_target_name

  • recovery_target_time

  • recovery_target_xid

  • recovery_target_inclusive

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_delayParameter 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 Disaster Recovery.

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