Memecahkan masalah replikasi

AlloyDB memiliki arsitektur yang memisahkan komputasi dan penyimpanan, sehingga masing-masing dapat diskalakan secara independen. Meskipun instance utama dan instance kumpulan baca menggunakan penyimpanan pokok yang sama, replikasi tetap merupakan proses penting untuk menjaga konsistensi dan keaktualan data di seluruh replika baca. Dalam cluster AlloyDB, operasi tulis dilakukan pada instance utama, lalu dicatat dalam Write-Ahead Log (WAL). Perubahan ini kemudian direplikasi ke node pool baca. Memahami dua langkah utama proses replikasi ini adalah kunci untuk memecahkan masalah apa pun:

• Pengosongan WAL: Write-Ahead Log (WAL), yang berisi perubahan pada database, dikirim dari instance utama ke replika. Replika kemudian segera mempertahankan WAL ke disk.
• Penerapan (atau pemutaran ulang) WAL: WAL yang dipertahankan diputar ulang pada replika, yang berarti perubahan diterapkan ke cache replika.

Penundaan dalam salah satu langkah ini berkontribusi pada apa yang dikenal sebagai jeda replikasi. Namun, istilah ini mungkin ambigu. Lebih tepatnya, kita dapat menguraikan jeda replikasi menjadi dua komponen berikut:

• Flush atau jeda jaringan: ini adalah penundaan pada langkah flush WAL. Ini adalah waktu yang diperlukan agar WAL dikirim dari instance utama dan dipertahankan di replika.
• Jeda pemutaran ulang: ini adalah penundaan dalam langkah penerapan WAL. Ini adalah waktu yang diperlukan replika untuk menerapkan perubahan dari WAL.

Apakah Anda harus lebih memperhatikan jeda flush atau jeda replay bergantung pada kasus penggunaan Anda:

• Jika Anda khawatir akan kehilangan data, misalnya, dengan cluster sekunder, Anda harus memperhatikan jeda flush dengan cermat. Jika WAL belum dipertahankan di replika dan instance utama mengalami error, perubahan akan hilang dari perspektif replika.
• Jika Anda mengkhawatirkan keaktualan data pada replika baca, Anda harus memperhatikan jeda flush dan jeda replay. Penundaan di salah satu langkah — baik dalam mengirimkan WAL atau menerapkannya — akan menghasilkan data yang tidak berlaku di replika baca Anda.

Memeriksa jeda replikasi

Anda dapat memantau jeda replikasi instance kumpulan baca di konsol Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Memantau instance. Anda juga dapat memantau jeda replikasi kumpulan baca dan menerima pemberitahuan pada batas yang ditentukan menggunakan Membuat kebijakan pemberitahuan batas metrik.

Penyebab umum kelambatan replikasi

Berikut beberapa penyebab umum kelambatan replikasi dan cara mengatasinya.

Pertentangan resource

Replikasi juga dapat diperlambat oleh perebutan resource sistem, seperti CPU dan memori.

• Tekanan CPU dan memori: workload baca yang berat pada instance kumpulan baca dapat bersaing dengan proses replikasi untuk resource CPU dan memori. Anda dapat memeriksa penggunaan CPU dan memori instance di konsol Google Cloud . Jika melihat pemakaian resource yang tinggi, Anda mungkin perlu meningkatkan skala atau menyebarkan skala instance kumpulan baca.
• Ukuran node kumpulan baca: jika instance utama Anda jauh lebih besar daripada node kumpulan baca, instance utama mungkin menghasilkan log replikasi lebih cepat daripada yang dapat diproses oleh node baca. Dalam kasus seperti ini, sebaiknya gunakan node baca berukuran lebih besar untuk memberikan lebih banyak resource kepada replika.

Konflik replikasi

Kueri baca terkadang dapat memblokir proses replikasi karena kueri tersebut mempertahankan resource yang ditunggu oleh proses replikasi. Jika kueri baca mengunci objek database yang perlu diupdate oleh proses replay, hal ini akan menyebabkan konflik kunci. Jika kueri menahan pin pada buffer data yang perlu diubah oleh replay, hal ini akan menyebabkan konflik pin buffer. Dalam kedua kasus tersebut, replay akan diblokir hingga kueri merilis resource.

Anda dapat mengidentifikasi konflik ini dengan mencari pesan canceling statement due to conflict with recovery di file postgres.log di Logs Explorer.

Untuk mengurangi konflik replikasi, Anda dapat melakukan hal berikut:

• Reduce max_standby_streaming_delay: parameter ini menentukan durasi tunggu proses replay sebelum membatalkan kueri yang memblokirnya. Nilai default-nya adalah 30 detik. Mengurangi nilai ini dapat membantu mengurangi jeda replikasi, tetapi juga dapat menyebabkan lebih banyak kueri baca dibatalkan. Anda dapat menyesuaikan parameter ini untuk menemukan keseimbangan terbaik bagi aplikasi Anda.

• Hindari kueri yang berjalan lama: kueri yang berjalan lama pada kumpulan baca dapat meningkatkan kemungkinan konflik replikasi. Pertimbangkan untuk memindahkan kueri yang berjalan lama ke kumpulan baca yang berbeda, yang tidak terlalu mementingkan jeda replikasi yang rendah.

• Verifikasi bahwa alloydb.promote_cancel_to_terminate aktif: flag ini, yang aktif secara default, memungkinkan AlloyDB menghentikan paksa backend kueri yang tidak responsif terhadap permintaan pembatalan. Hal ini dapat membantu mencegah backend yang tidak responsif memblokir replikasi dalam waktu lama.

Throttling kueri baca berbasis jeda

AlloyDB juga memberi Anda kontrol untuk mengaktifkan throttling berbasis jeda pada kueri baca di node baca menggunakan flag google_storage.log_replay_throttle_read_transactions. Jika parameter ditetapkan ke nilai defaultnya, yaitu on, kueri baca akan dibatasi dengan menjeda kueri baru agar tidak dimulai serta membaca buffer baru hingga satu menit saat jeda replikasi melebihi satu detik. Fitur ini melakukan kompromi yang meningkatkan jeda replikasi dengan memberikan lebih banyak resource kepada replay untuk mengejar ketertinggalan lebih cepat, dengan konsekuensi potensi peningkatan latensi kueri baca. Jika aplikasi Anda tidak sensitif terhadap jeda replikasi, Anda dapat memprioritaskan peningkatan latensi kueri baca dengan menetapkan google_storage.log_replay_throttle_read_transactions ke off.

Anda dapat memantau dampak throttling kueri menggunakan metode berikut:

• Log: telusuri pesan Delayed.*due to replica lag dalam file postgres.log di Logs Explorer untuk mengidentifikasi kapan kueri tertunda karena jeda replika.

• Cloud Monitoring: gunakan metrik alloydb.googleapis.com/instance/postgresql/wait_count untuk melihat jumlah kueri yang telah dibatasi. Untuk melakukannya, filter metrik menurut wait_event_name dan cari HighLagThrottle. Untuk melihat total waktu kueri dibatasi, Anda dapat menggunakan metrik alloydb.googleapis.com/instance/postgresql/wait_time dengan filter yang sama. Untuk mengetahui informasi selengkapnya, lihat Referensi metrik insight sistem.

• Query Insights: di dasbor Query Insights, tampilan Active queries menampilkan peristiwa tunggu HighLagThrottle di kolom Wait event saat kueri sedang dibatasi karena jeda replikasi. Untuk mengetahui detail selengkapnya, lihat Memantau kueri aktif.

Workload berat

Peningkatan mendadak pada workload tulis di instance utama dapat menghasilkan log replikasi dalam jumlah besar, yang dapat membebani instance kumpulan baca dan menyebabkan jeda replikasi. Anda dapat memantau traffic tulis pada instance utama di konsol Google Cloud .

Volume Write-Ahead-Log yang besar karena pembuatan indeks ScaNN

Membangun indeks ScaNN dapat menghasilkan sejumlah besar data WAL penulisan halaman penuh. Hal ini dapat menyebabkan keterlambatan dalam mengirim data WAL dari instance utama ke instance baca. Jika jeda replikasi terkait dengan pembuatan indeks ScaNN pada sejumlah besar embedding, Anda dapat mengaktifkan wal_compression pada instance utama untuk menghemat IO jaringan dan disk serta mengurangi jeda replikasi. Hal ini dapat menimbulkan sedikit overhead CPU tambahan.

wal_compression hanya mengompresi data penulisan halaman penuh dan tidak berpengaruh pada sebagian besar data WAL. Mengubah flag ini tidak memerlukan mulai ulang dan tidak memiliki periode nonaktif.

Transaksi besar

Transaksi yang mengubah banyak baris — misalnya, dengan menghapus beberapa tabel atau tabel besar — menghasilkan data COMMIT atau ABORT yang sangat besar di Write-Ahead Log (WAL). Data ini dapat memerlukan waktu yang lama untuk diputar ulang di node kumpulan baca, sehingga menyebabkan peningkatan sementara pada jeda replikasi.

Untuk mengurangi risiko ini, hindari melakukan operasi batch yang sangat besar, seperti penghapusan, dalam satu transaksi. Sebagai gantinya, bagi operasi ini menjadi transaksi yang lebih kecil dan lebih sering. Hal ini mengurangi ukuran setiap data COMMIT dan ABORT, sehingga aliran replikasi tetap lebih lancar dan mengurangi jeda replikasi puncak.

Memecahkan masalah yang mencegah replikasi

Sebelum dapat mengalami jeda replikasi, Anda harus memiliki kumpulan baca yang berfungsi. Masalah berikut dapat mencegah terjadinya replikasi sama sekali, baik dengan mencegah pembuatan kumpulan baca maupun dengan menyebabkan replika baca error.

Instance read pool error

Di PostgreSQL 14, transaksi yang berjalan lama pada instance utama yang menyimpan daftar panjang kunci eksklusif dapat menyebabkan penggunaan memori replika baca meningkat, yang pada akhirnya dapat menyebabkan instance kumpulan baca error.

Untuk mengurangi masalah ini, Anda dapat menghentikan transaksi yang berjalan lama di instance utama.

Dampak pengubahan ukuran instance terhadap jeda replikasi

Arsitektur penyimpanan AlloyDB memastikan bahwa jeda pengosongan kumpulan baca tidak terpengaruh oleh pengubahan ukuran instance. Namun, hal yang sama tidak berlaku untuk replay. Kemampuan replika untuk memutar ulang bergantung pada beban yang dimilikinya. Jika Anda memperbarui konfigurasi instance, misalnya, dengan mengubah ukurannya, bergantung pada workload, replika mungkin tidak memiliki cache yang sepenuhnya dihangatkan saat operasi selesai. Artinya, proses pemutaran ulang atau pemrosesan data yang belum di-cache akan lebih lambat. Dalam hal ini, jeda replay mungkin akan meningkat untuk sementara.