Jeda replikasi

MySQL   |  PostgreSQL   |  SQL Server

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.

Dua alasan pertama di atas dapat dipantau dengan 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.

Selain itu, pernyataan DDL seperti 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/database/replication/network_lag)	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 metrik cloudsql.googleapis.com/database/replication/state pada instance utama. Jika statusnya Running, replikasi berarti responsif.