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 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.

Memastikan replika disediakan dengan memadai

Instance replika yang lebih kecil dari instance utama (misalnya, dengan lebih sedikit vCPU dan memori) dapat mengalami jeda replikasi. Replika yang lebih kecil mungkin juga memiliki tanda konfigurasi default yang berbeda dibandingkan dengan instance utama yang lebih besar. Sebaiknya instance replika setidaknya sebesar instance utama agar memiliki cukup resource 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 instance utama dan replika 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 keterlambatan atau pemblokiran replikasi yang disebabkan oleh transaksi yang berjalan lama, sebaiknya lakukan hal berikut:

  • Menyesuaikan tanda penundaan siaga. 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.
  • Aktifkan tanda hot_standby_feedback. Menyetel flag hot_standby_feedback ke on di replika dapat membantu dengan menunda operasi vacuum di replika utama. Namun, hal ini dapat menyebabkan pembengkakan tabel di primer, jadi ada pertukaran.

Tinjau dokumentasi PostgreSQL untuk mengetahui informasi selengkapnya.

Lag jaringan tinggi

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

  • Replikasi lintas-region. Mereplikasi antar-region yang berbeda dapat menimbulkan latensi jaringan yang lebih tinggi.
  • Penggunaan CPU utama yang tinggi. Jika CPU primer lebih dari 90%, proses pengirim WAL mungkin tidak mendapatkan waktu CPU yang cukup. Pertimbangkan untuk mengurangi beban pada primer 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 hambatan 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 hal byte yang ditunjukkan oleh label replica_lag_type-nya.

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 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)

Langkah selanjutnya: