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, kolom pertama, Slave_IO_State, 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 mencakup hal berikut:
| 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 sebelumnya, 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.
Membuat ulang replika yang tertinggal
Buat ulang replika yang tertinggal saat replikasi tertinggal dari durasi yang dapat diterima.
Dengan Cloud SQL, Anda dapat mengonfigurasi replika baca untuk membuat ulang replika itu sendiri jika replikasi tertinggal (atau tertunda) melebihi jangka waktu yang dapat diterima, dan penundaan tersebut berlangsung setidaknya selama lima menit.
Jika Anda menentukan penundaan replikasi yang dapat diterima sebagai kurang dari 360 detik (enam menit), dan penundaan replikasi minimal 361 detik berlangsung selama lebih dari lima menit, maka setelah lima menit, instance utama akan membuat snapshot baru dari dirinya sendiri dan replika baca dibuat ulang menggunakan snapshot ini.
Membuat ulang replika baca yang tertinggal memberikan manfaat berikut:
- Anda mengontrol rentang yang dianggap dapat diterima untuk penundaan replikasi.
- Anda dapat mengurangi waktu yang dihabiskan untuk memecahkan masalah penundaan replikasi selama berjam-jam atau bahkan berhari-hari.
Detail fitur tambahan berlaku:
- Kompatibel dengan versi berikut:
- MySQL 5.7
- MySQL 8.0
- MySQL 8.4
- Rentang yang dapat diterima untuk jeda atau penundaan replikasi harus ditentukan dalam detik.
- Nilai minimum yang dapat diterima adalah 300 detik atau lima menit.
- Nilai maksimum yang dapat diterima adalah 31.536.000 detik atau satu tahun.
- Jika Anda mengaktifkan pembuatan ulang replika yang tertinggal untuk instance, tetapi tidak menetapkan keterlambatan replikasi maksimum yang dapat diterima, Cloud SQL akan menggunakan nilai default satu tahun.
- Jenis instance yang didukung:
- Replika baca
- Replika baca lintas region
- Replika beruntun
- Nilai yang ditetapkan untuk kolom
replicationLagMaxSecondsbersifat khusus untuk setiap instance replika. Jika instance utama memiliki beberapa instance replika, Anda dapat menetapkan setiap replika dengan nilai yang berbeda. - Saat replika dibuat ulang, pengguna dapat mengalami beberapa periode nonaktif saat operasi
berikut selesai:
- Replikasi dihentikan.
- Replika dihapus.
- Snapshot instance utama dibuat.
- Replika dibuat ulang dari snapshot terbaru ini. Replika baru menggunakan nama dan alamat IP yang sama dengan replika sebelumnya. Akibatnya, MySQL harus berhenti dan dimulai ulang.
- Replika baru mulai mereplikasi data.
replicationLagMaxSecondsadalah kolom tingkat instance. Setiap instance memiliki nilainya sendiri.Jika memiliki beberapa replika baca untuk instance utama yang sama, Anda dapat menetapkan nilai unik untuk kolom
replicationLagMaxSecondsuntuk setiap replika.Menentukan nilai minimum waktu yang berbeda untuk replika yang berbeda dapat membantu Anda menghindari skenario saat semua replika mengalami error secara bersamaan.
Mengaktifkan pembuatan ulang replika yang tertinggal
Fitur membuat ulang replika yang tertinggal dinonaktifkan secara default. Untuk mengaktifkannya saat Anda membuat instance, gunakan salah satu metode berikut:
gcloud
Gunakan perintah gcloud sql instances create
untuk membuat instance replika baca baru dengan flag
--replication-lag-max-seconds-for-recreate:
gcloud beta sql instances create REPLICA_INSTANCE_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME \ --database-version=DATABASE_VERSION \ --tier=TIER \ --edition=EDITION \ --region=REGION \ --root-password=PASSWORD \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
Dengan keterangan:
REPLICA_INSTANCE_NAMEadalah nama instance replika.PRIMARY_INSTANCE_NAMEadalah nama instance utama.DATABASE_VERSIONadalah versi database dari instance. Contoh,MYSQL_8_0_31.TIERadalah jenis mesin yang ingin Anda gunakan untuk instance replika. Contoh,db-perf-optimized-N-4. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi instance kustom.EDITIONadalah edisi yang ingin Anda gunakan untuk instance replika. Contoh,ENTERPRISE_PLUS. Untuk mengetahui informasi selengkapnya, lihat Membuat instance.REGIONadalah region yang ingin Anda gunakan untuk instance replika. Contoh,us-central1.PASSWORDadalah sandi root untuk instance.REPLICATION_LAG_MAX_SECONDSadalah latensi atau penundaan replika maksimum yang dapat diterima dalam hitungan detik. Contoh,600. Nilai minimum yang dapat diterima adalah 300 detik atau lima menit. Nilai maksimum yang dapat diterima adalah 31.536.000 detik atau satu tahun.
REST API
Kolom replicationLagMaxSeconds terletak di resource
DatabaseInstance. Tambahkan kolom ini ke isi permintaan:
{ "settings": { "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS, } ... }
Dengan keterangan:
REPLICATION_LAG_MAX_SECONDSadalah jeda atau penundaan replika maksimum yang dapat diterima dalam hitungan detik. Contoh,600.
Memperbarui jangka waktu pembuatan ulang untuk jeda replikasi
Untuk melihat setelan instance, gunakan salah satu metode yang dijelaskan dalam artikel Melihat informasi ringkasan instance.
Dengan informasi ini, Anda dapat memilih apakah akan memperbarui jangka waktu jeda replika yang Anda tentukan sebagai dapat diterima atau tidak sebelum replika dibuat ulang.
gcloud
Gunakan perintah gcloud sql instances patch
untuk memperbarui jangka waktu pembuatan ulang instance berdasarkan
lag replikasi:
gcloud beta sql instances patch INSTANCE_NAME \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
Dengan keterangan:
INSTANCE_NAMEadalah nama instance.REPLICATION_LAG_MAX_SECONDSadalah latensi atau penundaan replika maksimum yang dapat diterima dalam hitungan detik. Contoh,700. Jika Anda ingin kembali ke nilai default satu tahun, masukkan31536000. Nilai minimum yang dapat diterima adalah 300 detik atau lima menit. Nilai maksimum yang dapat diterima adalah 31.536.000 detik atau satu tahun.
REST API
Kebijakan dapat diperbarui menggunakan instances.patch
dan instance.insert.
Untuk melihat contoh cara memperbarui setelan menggunakan REST API, lihat Mengedit instance.
Batasan
Batasan berikut berlaku untuk membuat ulang replika yang tertinggal:
- Nilai untuk
replicationLagMaxSecondshanya dapat ditetapkan dalam detik. - Indeks yang dibuat pada replika baca sebelum dilakukannya operasi pembuatan ulang tidak akan disimpan. Jika indeks sudah ada, buat indeks sekunder setelah replika dibuat ulang.
- Untuk menghindari downtime yang sering terjadi pada replika baca, pembuatan ulang dibatasi hingga satu per hari per instance.
- Replika baca dengan ketersediaan tinggi dan replika server eksternal tidak didukung dengan fitur ini.
- Jika Anda mengaktifkan pembuatan ulang replika yang tertinggal pada replika bertingkat, Cloud SQL akan membuat ulang replika daun terlebih dahulu untuk mempertahankan konsistensi replikasi.
- Membuat ulang replika lintas region akan menimbulkan biaya tambahan.
- Anda tidak dapat mengaktifkan pembuatan ulang replika yang tertinggal di konsol Google Cloud.