AlloyDB memiliki arsitektur yang memisahkan komputasi dan penyimpanan, sehingga masing-masing dapat diskalakan secara independen. Meskipun instance utama dan kumpulan baca berbagi 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) di penyimpanan bersama. Perubahan ini kemudian direplikasi ke cache dalam memori instance pool baca. Memahami dua langkah utama proses replikasi ini adalah kunci untuk memecahkan masalah apa pun:
Flush WAL: Write-Ahead Log (WAL), yang berisi perubahan pada database, dikirim dari database utama ke replika. Replika kemudian langsung mempertahankan WAL ke disk. 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. Ini adalah waktu yang diperlukan agar WAL 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 replika lintas region, 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 keterlambatan pemutaran ulang. Jeda pemutaran ulang yang tinggi berarti data pada replika baca Anda sudah tidak berlaku.
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 persaingan untuk mendapatkan resource sistem, seperti CPU dan memori.
- Tekanan CPU dan memori: workload baca 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 vertikal atau penskalaan horizontal pada 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 itu, 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. Misalnya, jika kueri baca memiliki kunci pada objek database yang perlu diupdate oleh proses replikasi, replikasi akan diblokir hingga kunci dilepaskan. Hal ini dikenal sebagai konflik pin buffer.
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 replikasi 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.
Aktifkan
alloydb.promote_cancel_to_terminate: 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 sementara
AlloyDB juga memberi Anda kontrol untuk mengaktifkan atau tidak throttling berbasis jeda kueri baca pada node baca menggunakan tanda 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 pertukaran yang meningkatkan jeda replikasi dengan memberikan lebih banyak resource untuk pemutaran ulang agar dapat mengejar ketinggalan lebih cepat, dengan potensi peningkatan latensi 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 lagdalam filepostgres.logdi Logs Explorer untuk mengidentifikasi kapan kueri tertunda karena keterlambatan replika.Cloud Monitoring: gunakan metrik
alloydb.googleapis.com/instance/postgresql/wait_countuntuk melihat jumlah kueri yang telah di-throttle. Untuk melakukannya, filter metrik menurutwait_event_namedan cariHighLagThrottle. Untuk melihat total waktu kueri di-throttle, Anda dapat menggunakan metrikalloydb.googleapis.com/instance/postgresql/wait_timedengan filter yang sama. Untuk mengetahui informasi selengkapnya, lihat Referensi metrik insight sistem.Insight kueri: di dasbor Insight kueri, tampilan Kueri aktif menampilkan peristiwa tunggu
HighLagThrottledi 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 besar, seperti COMMIT atau ABORT yang memengaruhi sejumlah besar baris, dapat memerlukan waktu lama untuk direplikasi ke instance kumpulan baca. Di PostgreSQL 14, transaksi yang berjalan lama yang menyimpan 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.
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.
Masalah pembuatan kumpulan baca
Jika pembuatan pool baca gagal, Anda mungkin melihat pesan Failed to create read pool di log AlloyDB di Cloud Logging. Hal ini dapat terjadi jika cluster telah mencapai batas penyimpanan maksimumnya, sehingga mencegah instance utama mengalokasikan lebih banyak ruang. Meskipun AlloyDB menskalakan penyimpanan secara otomatis, Anda mungkin perlu menyelidiki apa yang menggunakan penyimpanan dan menghapus data yang tidak diperlukan, atau menghubungi dukungan untuk meminta peningkatan kuota penyimpanan Anda.
Error instance kumpulan baca
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.