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 replikasi streaming PostgreSQL. Perubahan ditulis ke Write-Ahead Log (WAL) di instance utama. Pengirim WAL mengirimkan WAL ke penerima WAL dalam replika, tempat kode tersebut diterapkan.

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 metrik network_lag. Yang ketiga diamati melalui metrik replica_lag. replica_lag yang tinggi berarti replika tidak dapat menerapkan perubahan replikasi dengan cukup cepat. Jeda total dapat diamati melalui metrik replica_byte_lag, yang memiliki label untuk menunjukkan detail lebih lanjut. 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.

Sebaiknya sesuaikan flag max_standby_archive_delay dan max_standby_streaming_delay untuk replika Anda.

Jika Anda mencurigai VACUUM adalah penyebabnya, dan pembatalan kueri tidak dapat diterima, pertimbangkan untuk menyetel flag hot_standby_feedback dalam replika.

Tinjau Dokumentasi Hot Standby PostgreSQL untuk informasi selengkapnya.

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.

Tinjau Dokumentasi Hot Standby PostgreSQL untuk informasi selengkapnya.

Replika kelebihan muatan

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

Metrik	Deskripsi
Jeda replikasi (`cloudsql.googleapis.com/database/replication/replica_lag`)	Jumlah detik saat status replika terjeda dibandingkan status instance utama. Ini adalah perbedaan antara waktu saat ini dan stempel waktu asli saat database utama meng-commit transaksi yang saat ini diterapkan pada replika. Secara khusus, operasi tulis mungkin dianggap terjeda meskipun telah diterima oleh replika, jika replika belum menerapkan penulisan ke database. Metrik ini dihitung menggunakan `now() - pg_last_xact_replay_timestamp()` dalam replika. Ini adalah perkiraan. Jika replikasi rusak, replika tidak akan mengetahui seberapa jauh database utama berada dan metrik ini tidak akan menunjukkan total jeda.
Byte jeda (`cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag`)	Jumlah byte yang membuat status replika terjeda di belakang status database utama. `replica_byte_lag` mengekspor 4 deret waktu, dan label `replica_lag_type` dapat menunjukkan salah satu dari hal berikut: sent_location: Menunjukkan jumlah byte WAL yang telah dibuat, tetapi belum dikirim ke replika. write_location: Penulisan dikurangi jeda dikirim menunjukkan byte WAL dalam jaringan yang telah dikirim tetapi belum ditulis dalam replika. flush_location: Pengosongan dikurangi jeda tulis menampilkan byte WAL yang ditulis dalam replika, tetapi belum dikosongkan dalam replika. replay_location: Menampilkan total jeda dalam byte. Putar ulang dikurangi jeda pengosongan menunjukkan penundaan pemutaran ulang.
Jeda jaringan (`cloudsql.googleapis.com/database/replication/network_lag`)	Jumlah waktu dalam, detik yang diperlukan dari commit dalam database utama untuk mencapai penerima WAL dalam replika. Jika `network_lag` nol, atau dapat diabaikan, tetapi `replica_lag` tinggi, ini menunjukkan bahwa penerima WAL tidak dapat menerapkan perubahan replikasi dengan cukup cepat.

Jeda replikasi
(cloudsql.googleapis.com/database/replication/replica_lag)

Jumlah detik saat status replika terjeda dibandingkan status instance utama. Ini adalah perbedaan antara waktu saat ini dan stempel waktu asli saat database utama meng-commit transaksi yang saat ini diterapkan pada replika. Secara khusus, operasi tulis mungkin dianggap terjeda meskipun telah diterima oleh replika, jika replika belum menerapkan penulisan ke database.

Metrik ini dihitung menggunakan now() - pg_last_xact_replay_timestamp() dalam replika. Ini adalah perkiraan. Jika replikasi rusak, replika tidak akan mengetahui seberapa jauh database utama berada dan metrik ini tidak akan menunjukkan total jeda.

Byte jeda
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

Jumlah byte yang membuat status replika terjeda di belakang status database utama. replica_byte_lag mengekspor 4 deret waktu, dan label replica_lag_type dapat menunjukkan salah satu dari hal berikut:

sent_location: Menunjukkan jumlah byte WAL yang telah dibuat, tetapi belum dikirim ke replika.
write_location: Penulisan dikurangi jeda dikirim menunjukkan byte WAL dalam jaringan yang telah dikirim tetapi belum ditulis dalam replika.
flush_location: Pengosongan dikurangi jeda tulis menampilkan byte WAL yang ditulis dalam replika, tetapi belum dikosongkan dalam replika.
replay_location: Menampilkan total jeda dalam byte. Putar ulang dikurangi jeda pengosongan menunjukkan penundaan pemutaran ulang.

Jeda jaringan
(cloudsql.googleapis.com/database/replication/network_lag)

Jumlah waktu dalam, detik yang diperlukan dari commit dalam database utama untuk mencapai penerima WAL dalam replika.

Jika network_lag nol, atau dapat diabaikan, tetapi replica_lag tinggi, ini menunjukkan bahwa penerima WAL tidak dapat menerapkan perubahan replikasi dengan cukup cepat.

Memverifikasi replikasi

Untuk memverifikasi bahwa replikasi berfungsi, jalankan pernyataan berikut terhadap replika tersebut:

select status, last_msg_receipt_time from pg_stat_wal_receiver;

Jika replikasi terjadi, Anda akan melihat status streaming dan last_msg_receipt_time:

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status   |     last_msg_receipt_time
-----------+-------------------------------
 streaming | 2020-01-21 20:19:51.461535+00
(1 row)

Jika replikasi tidak terjadi, hasil kosong akan ditampilkan:

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
 status | last_msg_receipt_time
--------+-----------------------
(0 rows)