Replikasi MySQL setelah VPN putus: baca dulu kedua tahap
Jalur yang terputus bukan transaksi yang hilang. Baca penerima dan pelaksana secara terpisah, lalu periksa apa yang masih disimpan sumber.
Pemantauan replikasi berubah merah saat VPN putus, dan naluri pertama adalah mengatur ulang posisi. Naluri itulah yang mengubah gangguan jaringan menjadi masalah data. Jalur yang putus tidak mengatakan apa pun tentang apa yang telah diterima atau diterapkan replika, dan itu dua tahap dengan dua keadaan. Bacalah keduanya secara terpisah sebelum mengubah apa pun.
Dua tahap, dua jawaban terpisah
Replika asinkron konvensional mengerjakan dua tugas. Penerima terhubung ke sumber, menarik peristiwa, dan menuliskannya ke log relay secara lokal. Pelaksana membaca log relay itu dan menjalankan peristiwa pada replika. Saat jalur terputus, penerima langsung berhenti sementara pelaksana terus mengerjakan tumpukan yang sudah ada di disk. Jadi satu gangguan menghasilkan dua pertanyaan berbeda: apakah koneksi sudah kembali, dan apakah pekerjaan yang menumpuk sudah diterapkan? Memperlakukan keduanya sebagai satu pertanyaan merata-ratakan dua keadaan menjadi jawaban yang menyesatkan.
Pulihnya penerima memberi tahu bahwa jalur sudah hidup. Itu tidak mengatakan seberapa jauh pelaksana tertinggal, atau apakah ia menemui kesalahan saat terputus.
Baca kanal dengan pernyataan yang tepat
Pada MySQL 8.4, SHOW REPLICA STATUS mengembalikan satu baris per kanal yang dikonfigurasi, jadi bacalah baris untuk kanal yang Anda maksud, bukan yang pertama dalam daftar. Replica_IO_Running memisahkan penerima yang terhubung dari yang sedang menghubungkan atau berhenti, dan Replica_SQL_Running menjelaskan pelaksana. Bacalah kolom kesalahan di sampingnya, karena penerima yang menyambung ulang dan langsung gagal meninggalkan pesan yang tidak akan ditunjukkan oleh bendera status mana pun. Rilis lama memakai nama kolom yang berbeda, jadi jangan menerjemahkan resep lama hanya dengan mengganti nama perintah.
Periksa juga identitas sumber dan filter yang dikonfigurasi. Replika yang mengarah ke sumber yang salah, atau difilter lebih sempit dari yang Anda kira, melaporkan sehat sambil mereplikasi sesuatu yang berbeda dari yang Anda harapkan.
Mengapa angka jeda nol bisa berbohong
Nilai jeda membandingkan stempel waktu peristiwa terakhir yang diterapkan dengan waktu saat ini. Ketika penerima berhenti selama satu jam, pelaksana dapat mengerjakan tumpukan dan mencapai akhir dari apa yang diterimanya, lalu angkanya turun ke nol meskipun replika tertinggal satu jam dari sumber. Metrik ini mengukur antrean pelaksana, bukan kemutakhiran replika.
Bandingkan saja transaksi yang dieksekusi dengan apa yang tersedia di sumber. Perbandingan itu bertahan terhadap penerima yang macet.
Retensi menentukan jendela pemulihan yang sebenarnya
Menyusul memerlukan sumber masih menyimpan transaksi yang dibutuhkan replika. Setelah transaksi itu dibersihkan, replika tidak dapat mengambilnya, dan berapa pun banyaknya penyambungan ulang tidak mengubahnya.
Dengan pemosisian otomatis GTID, kegagalannya eksplisit: replika meminta riwayat yang tidak lagi disimpan sumber dan menolak melanjutkan. Pilihannya lalu mengambil peristiwa yang hilang dari sumber yang masih memilikinya, atau membangun ulang dari cadangan dan membiarkannya menyusul. Melewati celah bukan menyusul, dan itu meninggalkan replika yang datanya diam-diam tidak lengkap. Rencanakan jendela dengan membandingkan perkiraan lama gangguan dengan retensi log biner di sumber dan laju perubahan, karena ketiga angka itu menentukan apakah suatu gangguan dapat dipulihkan sama sekali.
Verifikasi penyusulan, bukan warna indikator
Pulihkan jalur, termasuk resolusi nama dan keamanan transportasi, lalu amati apakah kanal yang ada menyambung ulang menurut kebijakannya sendiri. Beri ia interval yang ditentukan sebelum Anda turun tangan, dan catat kemajuan penerimaan dan penerapan di kedua ujung interval itu. Kanal yang memulai ulang dan kanal yang mutakhir adalah temuan yang berbeda.
Pastikan pelaksana telah mencapai posisi sumber saat ini, bukan hanya akhir tumpukan lama. Periksa bahwa tidak ada kesalahan yang menunggu di pelaksana, karena satu peristiwa gagal menghentikan kemajuan sementara penerima terus melaporkan terhubung. Lalu catat buktinya: nama kanal, kedua keadaan tahap, posisi yang dieksekusi, dan waktu. Indikator hijau adalah klaim; posisi adalah fakta.