Jeda replikasi

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 skenario pertama yang tercantum dapat dipantau dengan metrik network_lag. Skenario ketiga diamati menggunakan metrik replica_lag. replica_lag yang tinggi berarti replika tidak dapat menerapkan perubahan replikasi dengan cukup cepat. Total jeda dapat diamati menggunakan metrik replica_byte_lag, yang memiliki label untuk menunjukkan detail lebih lanjut. Untuk mengetahui informasi selengkapnya tentang metrik ini, lihat Memantau jeda replikasi.

Memastikan replika disediakan secara memadai

Instance replika yang lebih kecil dari instance utama (misalnya, dengan vCPU dan memori yang lebih sedikit) dapat mengalami jeda replikasi. Replika yang lebih kecil mungkin juga memiliki flag konfigurasi default yang berbeda dibandingkan dengan instance utama yang lebih besar. Sebaiknya instance replika setidaknya sebesar instance utama agar memiliki resource yang cukup untuk menangani beban replikasi.

Penggunaan CPU yang tinggi pada replika juga dapat menyebabkan jeda replikasi. Jika penggunaan CPU replika tinggi (misalnya, lebih dari 90%), pertimbangkan untuk meningkatkan kapasitas CPU replika.

Anda dapat menggunakan perintah SHOW ALL untuk melihat konfigurasi replika dan instance utama serta membandingkannya untuk melihat perbedaannya.

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. Hal ini dapat terjadi saat replikasi mencoba menerapkan perubahan (seperti dari operasi VACUUM) ke baris yang sedang dibaca oleh kueri pada replika.

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.

Untuk membantu mengatasi penundaan atau pemblokiran replikasi yang disebabkan oleh transaksi yang berjalan lama, sebaiknya lakukan hal berikut:

  • Menyesuaikan flag penundaan standby. Flag max_standby_archive_delay dan max_standby_streaming_delay mengontrol berapa lama replika akan menunggu sebelum membatalkan kueri standby yang bertentangan dengan replikasi. Nilai yang wajar biasanya sekitar 30 hingga 60 detik. Anda dapat memeriksa tampilan pg_stat_database_conflicts untuk mendapatkan insight tentang konflik kueri.
  • Mengaktifkan flag hot_standby_feedback Menetapkan flag hot_standby_feedback ke on di replika dapat membantu dengan menunda operasi vacuum pada replika utama. Namun, hal ini dapat menyebabkan pembengkakan tabel pada replika utama, sehingga ada kompromi.

Tinjau dokumentasi PostgreSQL untuk mengetahui informasi selengkapnya.

Jeda jaringan yang tinggi

Jeda jaringan yang tinggi menunjukkan bahwa data WAL tidak dikirim oleh replika utama atau diterima oleh replika dengan cukup cepat. Hal ini dapat disebabkan oleh hal berikut:

  • Replikasi lintas-region. Mereplikasi antar-region yang berbeda dapat menyebabkan latensi jaringan yang lebih tinggi.
  • Penggunaan CPU utama yang tinggi. Jika CPU utama lebih dari 90%, proses pengirim WAL mungkin tidak mendapatkan waktu CPU yang cukup. Pertimbangkan untuk mengurangi beban pada replika utama atau meningkatkan CPU-nya.
  • Penggunaan CPU replika yang tinggi. Jika CPU replika lebih dari 90%, proses penerima WAL mungkin tidak mendapatkan waktu CPU yang cukup. Pertimbangkan untuk mengurangi beban pada replika atau meningkatkan CPU-nya.
  • Masalah bandwidth jaringan atau bottleneck I/O disk. Region yang lebih dekat atau konfigurasi disk dengan throughput yang lebih tinggi dapat membantu. Pertimbangkan untuk mengubah nilai flag wal_compression di instance utama untuk membantu mengurangi traffic lintas-region.
Anda dapat memantau jeda jaringan dengan metrik cloudsql.googleapis.com/database/replication/network_lag. Metrik ini memiliki batas maksimum 25 detik, meskipun jeda sebenarnya lebih tinggi.

Metrik network_lag ini mirip dengan metrik cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag yang mengukur jeda sent_location dalam byte yang ditunjukkan oleh label replica_lag_type.

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 PostgreSQL untuk mengetahui informasi selengkapnya.

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.

MetrikDeskripsi
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 bernilai nol, atau dapat diabaikan, tetapi replica_lag tinggi, ini menunjukkan bahwa penerima WAL tidak dapat menerapkan perubahan replikasi dengan cukup cepat.

Karena network_lag dibulatkan ke detik terdekat, nilai 1 detik yang dilaporkan dapat mewakili jeda yang mendasarinya dari satu atau dua milidetik hingga satu detik penuh.

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)

Langkah selanjutnya: