Memecahkan masalah replikasi

AlloyDB memiliki arsitektur yang memisahkan komputasi dan penyimpanan, sehingga masing-masing dapat diskalakan secara independen. Meskipun instance utama dan 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 primer ke replika. Replika kemudian langsung mempertahankan WAL ke disk.
  • Penerapan (atau pemutaran ulang) WAL: WAL yang dipertahankan diputar ulang di replika, yang berarti perubahan diterapkan ke cache replika.

Penundaan di salah satu langkah ini berkontribusi pada apa yang dikenal sebagai jeda replikasi. Namun, istilah ini mungkin ambigu. Agar lebih presisi, kita dapat membagi keterlambatan replikasi menjadi dua komponen berikut:

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

Apakah Anda harus lebih mengkhawatirkan jeda flush atau jeda pemutaran ulang bergantung pada kasus penggunaan Anda:

  • Jika Anda khawatir tentang kehilangan data, misalnya, dengan cluster sekunder, Anda harus memperhatikan jeda flush. Jika WAL belum dipertahankan di replika dan instance utama mengalami error, perubahan akan hilang dari perspektif replika.
  • Jika Anda khawatir tentang keaktualan data di replika baca, Anda harus memperhatikan dengan cermat jeda flush dan jeda pemutaran ulang. Penundaan di salah satu langkah — baik dalam mengirimkan WAL atau menerapkannya — akan menghasilkan data usang pada 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.

Persaingan resource

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

  • Tekanan CPU dan memori: workload baca yang berat pada instance kumpulan baca dapat bersaing dengan proses replikasi untuk mendapatkan 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 melakukan penskalaan ke atas atau penskalaan ke luar instance kumpulan baca.
  • Ukuran node kumpulan baca: jika instance utama Anda jauh lebih besar daripada node kumpulan baca, instance tersebut dapat 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 pada replika.

Konflik replikasi

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

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

Untuk mengurangi konflik replikasi, Anda dapat melakukan hal berikut:

  • Kurangi max_standby_streaming_delay: parameter ini menentukan durasi proses pemutaran ulang menunggu 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 di kumpulan baca dapat meningkatkan kemungkinan konflik replikasi. Pertimbangkan untuk memindahkan kueri yang berjalan lama ke kumpulan baca lain yang tidak terlalu memerlukan latensi replikasi rendah.

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

Throttling kueri baca berbasis jeda

AlloyDB juga memberi Anda kontrol untuk mengaktifkan atau tidak pembatasan berbasis jeda kueri baca pada node baca menggunakan flag google_storage.log_replay_throttle_read_transactions. Jika parameter disetel ke nilai defaultnya, yaitu on, kueri baca akan di-throttle dengan menjeda kueri baru agar tidak dimulai serta membaca buffer baru hingga satu menit saat jeda replikasi melebihi satu detik. Fitur ini membuat trade-off yang meningkatkan jeda replikasi dengan memberikan lebih banyak resource untuk pemutaran ulang agar dapat mengejar ketinggalan lebih cepat, dengan biaya yang berpotensi meningkatkan latensi kueri baca. Jika aplikasi Anda tidak sensitif terhadap jeda replikasi, Anda dapat memprioritaskan peningkatan latensi kueri baca dengan menyetel google_storage.log_replay_throttle_read_transactions ke off.

Anda dapat memantau dampak pembatasan 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 keterlambatan replika.

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

  • Insight kueri: di dasbor Insight kueri, tampilan Kueri aktif menampilkan peristiwa tunggu HighLagThrottle di kolom Peristiwa tunggu saat kueri di-throttle karena keterlambatan replikasi. Untuk mengetahui detail selengkapnya, lihat Memantau kueri aktif.

Beban kerja berat

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

Transaksi besar

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

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

Memecahkan masalah yang mencegah replikasi

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

Instance kumpulan baca mengalami error

Di PostgreSQL 14, transaksi yang berjalan lama pada instance utama yang memiliki daftar panjang kunci eksklusif dapat menyebabkan penggunaan memori replika baca meningkat, yang pada akhirnya dapat menyebabkan instance kumpulan baca mengalami 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 flush pool 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 siap saat operasi selesai. Artinya, pemutaran ulang atau pemrosesan data yang belum di-cache akan lebih lambat. Dalam hal ini, hal ini mungkin berarti jeda pemutaran ulang meningkat untuk sementara.