Halaman ini menjelaskan cara memecahkan masalah dan memperbaiki jeda replikasi untuk replika baca Cloud SQL.
Ringkasan
Replika baca Cloud SQL menggunakan Grup Ketersediaan SQL Server Always-On untuk replikasi. Perubahan ditulis pada log transaksi di instance utama. Instance utama meneruskan transaksi ke instance replika sekunder, tempat perubahan diterapkan. Mode ketersediaan yang digunakan adalah Mode commit asinkron.Jeda replikasi dapat terjadi dalam beberapa skenario, seperti:
- Instance utama tidak dapat mengirimkan perubahan dengan cukup cepat ke replika.
- Replika tidak dapat menerima perubahan dengan cukup cepat.
- Replika tidak dapat menerapkan perubahan dengan cukup cepat.
network_lag
metric
. Alasan ketiga dapat diamati melalui metrik seconds_behind_master
. Metrik
seconds_behind_master
yang tinggi berarti replika tidak dapat menerapkan
perubahan replikasi dengan cukup cepat. Metrik ini dijelaskan di
bagian Memantau jeda replikasi di bawah.
Mengoptimalkan kueri dan skema
Bagian ini menyarankan beberapa pengoptimalan kueri dan skema umum yang dapat Anda lakukan untuk meningkatkan performa replikasi.
Kueri yang berjalan lama dalam replika baca
Kueri yang berjalan lama dalam replika mungkin memblokir replikasi untuk Cloud SQL. Anda mungkin ingin memiliki replika terpisah untuk tujuan pemrosesan transaksi online (OLTP) dan pemrosesan analisis online (OLAP), serta hanya mengirim kueri yang berjalan lama ke replika OLAP.
Penguncian eksklusif karena DDL
Perintah bahasa definisi data (DDL), seperti ALTER TABLE
dan
CREATE INDEX
, dapat menyebabkan jeda replikasi dalam replika karena
kunci eksklusif. Untuk menghindari pertentangan kunci, pertimbangkan untuk menjadwalkan eksekusi DDL
saat beban kueri lebih rendah pada replika.
CREATE INDEX
, ALTER INDEX
, dan INDEX
MAINTENANCE
dapat menyebabkan jeda replikasi karena banyaknya data log
transaksi yang dapat dihasilkan oleh pernyataan ini.
Replika kelebihan beban
Jika replika baca menerima terlalu banyak kueri, replikasi dapat diblokir. Pertimbangkan untuk membagi pembacaan di antara beberapa replika untuk mengurangi beban pada setiap replika.
Untuk menghindari lonjakan kueri, pertimbangkan untuk melakukan throttling replika baca kueri baca di logika aplikasi Anda atau di lapisan proxy jika Anda menggunakannya.
Jika ada lonjakan aktivitas pada instance utama, pertimbangkan untuk menyebarkan update.
Database primer monolitik
Sebaiknya lakukan sharding database utama secara vertikal (atau horizontal) untuk mencegah satu atau beberapa tabel yang terjeda menahan semua tabel lainnya.
Memantau jeda replikasi
Anda dapat menggunakan metrik replica_lag
dan network_lag
untuk memantau jeda
replikasi dan mengidentifikasi apakah penyebab jeda berada pada database utama,
jaringan, atau replika.
Metrik | Deskripsi |
---|---|
Jeda replikasi ( cloudsql.googleapis.com/database/replication/seconds_behind_master ) |
Jumlah detik di mana status replika terjeda di belakang status instance utama. Ini adalah perbedaan antara stempel waktu data log yang terakhir dikirim ulang di sekunder dan stempel waktu data log yang terakhir dikirim di log utama. |
Jeda jaringan ( cloudsql.googleapis.com ) |
Perbedaan antara stempel waktu entri log yang terakhir diterima di dan entri log yang terakhir dikirim di entri utama. |
Memverifikasi replikasi
Untuk memverifikasi bahwa replikasi berfungsi, periksa nilai metrikcloudsql.googleapis.com/database/replication/state
pada instance
utama. Jika statusnya Running
, replikasi berarti responsif.