Re-Slaving Server Master MySQL yang Rusak dalam Pengaturan Replikasi Semisinkron

Dalam pengaturan master-slave MySQL 5.7 yang menggunakan pengaturan replikasi semisinkron default untuk rpl_semi_sync_master_wait_point , crash master dan failover ke slave dianggap lossless. Namun, ketika master yang crash kembali, Anda mungkin menemukan bahwa ia memiliki transaksi yang tidak ada di master saat ini (yang sebelumnya adalah slave). Perilaku ini mungkin membingungkan, mengingat replikasi semisinkron seharusnya lossless, tetapi ini sebenarnya adalah perilaku yang diharapkan di MySQL. Mengapa hal ini terjadi dijelaskan secara lengkap dalam posting blog oleh Jean-François Gagné (JF).

Mengingat skenario seperti itu, dokumentasi MySQL merekomendasikan bahwa master yang mogok harus dibuang dan tidak boleh dimulai ulang. Namun, membuang server seperti ini mahal dan tidak efisien. Dalam posting blog ini, kami akan menjelaskan pendekatan untuk mendeteksi dan memperbaiki transaksi pada server master MySQL yang mogok dalam pengaturan replikasi semisinkron, dan cara melakukan re-slave kembali ke pengaturan master-slave Anda.

Mengapa Penting untuk Mendeteksi Transaksi Ekstra pada Master yang Dipulihkan?

Transaksi ekstra pada master yang dipulihkan dapat terwujud dalam dua cara:

1. Replikasi MySQL gagal saat master yang dipulihkan di-slaved

Biasanya, hal ini terjadi saat Anda memiliki kunci utama peningkatan otomatis. Ketika master MySQL baru menyisipkan baris ke tabel seperti itu, replikasi akan gagal karena kunci sudah ada di slave.

Skenario lainnya adalah saat aplikasi Anda mencoba kembali transaksi yang gagal selama master crash. Pada master MySQL yang dipulihkan (yang sekarang menjadi slave), transaksi ini akan benar-benar ada, dan sekali lagi, menghasilkan kesalahan replikasi.

Biasanya, kesalahan replikasi MySQL akan terlihat seperti ini:

2. Inkonsistensi senyap dalam data antara master MySQL baru dan slave (master yang dipulihkan)

Jika aplikasi tidak mencoba lagi transaksi yang gagal dan tidak ada tabrakan kunci utama di masa mendatang, kesalahan replikasi mungkin tidak terjadi. Akibatnya, inkonsistensi data mungkin tidak terdeteksi.

Dalam kedua kasus di atas, ketersediaan tinggi atau integritas data penyiapan MySQL Anda terpengaruh, itulah sebabnya sangat penting untuk mendeteksi kondisi ini sedini mungkin.

Cara Mendeteksi Transaksi Ekstra pada Master MySQL yang Dipulihkan

Kami dapat mendeteksi jika ada transaksi tambahan pada master yang dipulihkan menggunakan fungsi MySQL GTID (pengidentifikasi transaksi global):

GTID_SUBSET(set1 ,set2 ):Diberikan dua set ID transaksi global set1 dan set2 , mengembalikan nilai true jika semua GTID di set1 juga ada di set2 . Mengembalikan false jika tidak.

Mari kita gunakan contoh untuk memahami hal ini.

• GTID disetel pada master yang dipulihkan yang UUID-nya adalah:‘54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ adalah:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
• Set GTID master baru yang UUID-nya adalah:‘57956099-d01d-11e7-80bc-000d3af97c09 ' adalah:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'

Sekarang, jika kita memanggil fungsi GTID_SUBSET sebagai GTID_SUBSET(kumpulan GTID master yang dipulihkan, kumpulan GTID dari master baru) , nilai pengembalian akan benar, hanya jika master yang dipulihkan tidak memiliki transaksi tambahan. Dalam contoh kami di atas, karena master yang dipulihkan memiliki transaksi ekstra 9691 hingga 9700, hasil kueri di atas salah.

Cara Re-Slave Master MySQL yang Dipulihkan yang Memiliki Transaksi Ekstra

Berdasarkan langkah di atas, adalah mungkin untuk mengetahui apakah master yang dipulihkan memiliki transaksi ekstra, dan transaksi apa yang menggunakan fungsi GTID:GTID_SUBTRACT(GTID set of master yang dipulihkan, kumpulan GTID dari master baru).

Dimungkinkan juga untuk mengekstrak transaksi tambahan ini dari log biner dan menyimpannya. Mungkin berguna bagi tim bisnis Anda untuk meninjau transaksi ini di lain waktu guna memastikan kami tidak kehilangan informasi bisnis penting apa pun secara tidak sengaja, meskipun informasi tersebut tidak terikat. Setelah ini selesai, kami membutuhkan cara untuk menyingkirkan transaksi tambahan ini sehingga master yang dipulihkan dapat di-slaved kembali tanpa masalah.

Salah satu cara termudah untuk melakukannya adalah dengan mengambil snapshot cadangan pada master saat ini dan memulihkan data ke slave Anda saat ini. Ingatlah bahwa Anda perlu mempertahankan UUID server ini seperti sebelumnya. Setelah Anda memulihkan data, server dapat di-slaved kembali, dan server akan memulai replikasi dari titik snapshot yang dipulihkan. Anda akan segera memiliki budak yang sehat kembali!

Langkah-langkah di atas sangat membosankan jika Anda harus melakukannya secara manual, tetapi layanan hosting MySQL yang dikelola sepenuhnya oleh ScaleGrid dapat mengotomatiskan seluruh proses untuk Anda tanpa memerlukan intervensi apa pun. Begini cara kerjanya:

Jika master Anda saat ini mogok, ScaleGrid mengotomatiskan proses failover dan mempromosikan budak yang sesuai sebagai master baru. Master lama kemudian dipulihkan, dan kami secara otomatis mendeteksi jika ada transaksi tambahan di dalamnya. Jika ada yang ditemukan, penerapan MySQL dimasukkan ke dalam status terdegradasi, dan kami menggunakan alat otomatis untuk mengekstrak dan menyimpan transaksi tambahan untuk Anda tinjau. Tim dukungan kami kemudian dapat memulihkan master lama ke status yang baik, dan melakukan re-slave kembali ke pengaturan master-slave Anda sehingga Anda akan memiliki penerapan yang sehat!

Ingin mencobanya? Mulai uji coba gratis selama 30 hari untuk menjelajahi semua kemampuan manajemen database MySQL di ScaleGrid.