Halaman ini menjelaskan cara memecahkan masalah dan memperbaiki jeda replikasi untuk replika baca Cloud SQL.
Ringkasan
Replika baca Cloud SQL menggunakan replikasi berbasis baris MySQL menggunakan ID transaksi global (GTID). Perubahan ditulis ke log biner instance utama dan dikirim ke replika, tempat perubahan tersebut diterima, lalu diterapkan ke database.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 metrik untuk memantau dua skenario pertama saat
instance utama tidak dapat mengirim perubahan dengan cukup cepat atau replika tidak dapat menerima perubahan
dengan cukup cepat.
Jeda total diamati dengan metrik replica_lag.
Perbedaan antara replica_lag dan network_lag dapat menunjukkan
alasan ketiga ketika replika tidak dapat menerapkan perubahan replikasi dengan cukup cepat.
Metrik ini dijelaskan di bagian Memantau jeda replikasi di bawah.
Konfigurasi replika yang lebih cepat
Kami memiliki dua cara untuk membuat replika MySQL menerapkan perubahan lebih cepat. Pengguna dapat mengonfigurasi replika mereka dengan opsi berikut:
- Replikasi paralel
- Pembersihan berperforma tinggi
Replikasi paralel
Replikasi paralel dapat membantu jeda replikasi dengan mengonfigurasi replika agar menggunakan beberapa thread yang bertindak secara paralel untuk menerapkan perubahan pada replika. Untuk mengetahui informasi tentang cara menggunakan replikasi paralel, lihat Mengonfigurasi replikasi paralel.
Pembersihan berperforma tinggi
Secara default, Cloud SQL untuk MySQL mengosongkan log pengulangan ke disk setelah setiap transaksi. Pembersihan berperforma tinggi mengurangi frekuensi pembersihan log pengulangan ke disk menjadi satu kali per detik, sehingga meningkatkan performa penulisan.
Tetapkan flag innodb_flush_log_at_trx_commit
pada replika baca ke 2. Anda juga harus menetapkan flag sync_binlog ke
nilai yang lebih tinggi agar flag innodb_flush_log_at_trx_commit berlaku.
Lihat Tips untuk menggunakan flag untuk mengetahui informasi selengkapnya tentang flag ini.
Jika flag innodb_flush_log_at_trx_commit ditetapkan pada replika baca dan Cloud SQL mendeteksi bahwa mungkin terjadi error, Cloud SQL akan otomatis membuat ulang replika.
Mengoptimalkan kueri dan skema
Bagian ini menyarankan beberapa pengoptimalan skema dan kueri umum yang dapat Anda lakukan untuk meningkatkan performa replikasi.
Tingkat isolasi kueri dalam replika baca
Tingkat isolasi transaksi REPEATABLE READ dan SERIALIZABLE
memperoleh kunci yang mungkin memblokir perubahan replikasi. Sebaiknya kurangi
tingkat isolasi untuk kueri Anda di replika. Tingkat isolasi transaksi READ COMMITTED
mungkin akan berperforma lebih baik.
Transaksi yang berjalan lama di database utama
Jika sejumlah besar baris diperbarui dalam satu transaksi, hal ini dapat menyebabkan lonjakan tiba-tiba dalam jumlah perubahan yang perlu diterapkan ke instance utama, lalu dikirim ke replika. Hal ini berlaku untuk pembaruan atau penghapusan pernyataan tunggal yang memengaruhi banyak baris sekaligus. Perubahan dikirim ke replika setelah di-commit. Menerapkan lonjakan perubahan tiba-tiba pada replika dapat meningkatkan kemungkinan pertentangan kunci dalam replika jika beban kueri pada replika juga tinggi, yang menyebabkan jeda replikasi.
Pertimbangkan untuk membagi transaksi besar menjadi beberapa transaksi yang lebih kecil.
Kunci utama tidak ada
Replika baca Cloud SQL menggunakan replikasi berbasis baris, yang berperforma buruk jika tabel MySQL yang direplikasi tidak memiliki kunci utama. Kami merekomendasikan agar semua tabel yang direplikasi memiliki kunci utama.
Untuk MySQL 8 atau yang lebih baru, sebaiknya tetapkan flag sql_require_primary_key ke ON untuk mewajibkan tabel dalam database Anda agar memiliki kunci utama.
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.
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 |
|---|---|
| Jeda replikasi ( cloudsql.googleapis.com) |
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, penulisan mungkin dianggap tertinggal meskipun telah diterima oleh replika, jika replika belum menerapkan penulisan ke database. Metrik ini melaporkan nilai |
| Nomor error thread I/O terakhir ( cloudsql.googleapis.com) |
Menunjukkan error terakhir yang menyebabkan thread I/O gagal. Jika nilainya bukan nol,
ini berarti replikasi rusak. Hal ini jarang terjadi, tetapi bisa saja terjadi. Periksa
dokumentasi MySQL untuk memahami apa yang ditunjukkan oleh kode error. Misalnya,
file binlog dalam instance utama mungkin telah dihapus
sebelum replika menerimanya.
Cloud SQL biasanya akan otomatis membuat ulang replika jika replikasi rusak.
Metrik |
| Nomor error thread SQL terakhir ( cloudsql.googleapis.com) |
Menunjukkan error terakhir yang menyebabkan thread SQL gagal. Jika nilainya bukan nol,
ini berarti replikasi rusak. Hal ini jarang terjadi, tetapi bisa saja terjadi. Periksa
dokumentasi MySQL untuk memahami apa yang ditunjukkan oleh kode error.
Cloud SQL biasanya akan otomatis membuat ulang replika jika replikasi rusak.
Metrik |
| Latensi jaringan ( cloudsql.googleapis.com) |
Durasi waktu, dalam detik yang diperlukan dari penulisan binlog di database utama untuk mencapai thread IO di replika. Jika |
Memverifikasi replikasi
Untuk memverifikasi bahwa replikasi berfungsi, jalankan pernyataan berikut terhadap replika tersebut:
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Queueing master event to the relay log
Master_Host: xx.xxx.xxx.xxx
Master_User: cloudsqlreplica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.199927
Read_Master_Log_Pos: 83711956
Relay_Log_File: relay-log.000025
Relay_Log_Pos: 24214376
Relay_Master_Log_File: mysql-bin.199898
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 24214163
Relay_Log_Space: 3128686571
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: master_server_ca.pem
Master_SSL_CA_Path: /mysql/datadir
Master_SSL_Cert: replica_cert.pem
Master_SSL_Cipher:
Master_SSL_Key: replica_pkey.pem
Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 321071839
Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Jika replikasi terjadi, Slave_IO_State (kolom pertama) akan menampilkan Waiting
for master to send event atau pesan serupa. Selain itu, kolom Last_IO_Error kosong.
Jika replikasi tidak terjadi, kolom Slave_IO_State akan menampilkan status
Connecting to master dan kolom Last_IO_Error akan menampilkan status
error connecting to master cloudsqlreplica@x.x.x.x:3306.
Menurut dokumentasi MySQL, beberapa kolom menarik lainnya yang terkait dengan jeda replikasi adalah:
| Kolom | Deskripsi |
|---|---|
Master_Log_File |
Nama file log biner sumber yang saat ini dibaca oleh thread I/O |
Read_Master_Log_Pos |
Posisi dalam file log biner sumber saat ini yang telah dibaca oleh thread I/O. |
Relay_Log_File |
Nama file log relai yang saat ini dibaca dan dijalankan oleh thread SQL. |
Relay_Log_Pos |
Posisi dalam file log relai saat ini yang telah dibaca dan dijalankan oleh thread SQL. |
Relay_Master_Log_File |
Nama file log biner source yang berisi peristiwa terbaru yang dijalankan oleh thread SQL. |
Pada contoh di atas, Relay_Master_Log_File memiliki nilai mysql-bin.199898.
Master_Log_Filememiliki nilaimysql-bin.199927 Akhiran numerik 199898
kurang dari 199927. Artinya, meskipun replika telah menerima
file log mysql-bin.199927 yang lebih baru, replika tersebut masih menerapkan mysql-bin.199898 lama.
Dalam hal ini, thread SQL tertinggal dalam replika.
Anda juga dapat terhubung ke database utama dan menjalankan:
SHOW MASTER STATUS;
Perintah ini menunjukkan file binlog mana yang sedang ditulis di database utama.
Jika file log biner database utama lebih baru daripada Master_Log_File yang berada dalam replika,
artinya thread I/O mengalami ketertinggalan. Replika masih membaca file log biner
lama dari database utama.
Saat thread I/O tertinggal, metrik network_lag juga tinggi. Jika thread SQL
tertinggal, tetapi thread I/O tidak, berarti metrik network_lag tidak terlalu tinggi, tetapi
replica_lag tinggi.
Perintah sebelumnya memungkinkan Anda mengamati detail jeda saat jeda terjadi,
tetapi metrik network_lag dan replica_lag memberi Anda cara untuk
melihat kemunculan jeda di masa lalu.