Dalam seri blog tiga bagian ini, kami memperkenalkan Kerangka Kerja Ketersediaan Tinggi (HA) untuk hosting MySQL di Bagian I, dan membahas detail replikasi semisinkron MySQL di Bagian II. Sekarang di Bagian III, kami meninjau bagaimana kerangka kerja menangani beberapa skenario kegagalan MySQL yang penting dan memulihkannya untuk memastikan ketersediaan yang tinggi.
Skenario Kegagalan MySQL
Skenario 1 – Master MySQL Turun
- Kerangka Corosync dan Pacemaker mendeteksi bahwa MySQL master tidak lagi tersedia. Alat pacu jantung menurunkan sumber daya master dan mencoba memulihkan dengan memulai ulang layanan MySQL, jika memungkinkan.
- Pada titik ini, karena sifat replikasi yang semisinkron, semua transaksi yang dilakukan pada master telah diterima oleh setidaknya satu budak.
- Alat pacu jantung menunggu hingga semua transaksi yang diterima diterapkan pada slave dan membiarkan slave melaporkan skor promosi mereka. Penghitungan skor dilakukan sedemikian rupa sehingga skornya adalah '0' jika budak benar-benar sinkron dengan master, dan sebaliknya adalah angka negatif.
- Pacemaker memilih slave yang telah melaporkan skor 0 dan mempromosikan slave tersebut yang sekarang berperan sebagai master MySQL yang memungkinkan penulisan.
- Setelah promosi budak, Agen Sumber Daya memicu modul perutean ulang DNS. Modul memperbarui entri DNS proxy dengan alamat IP master baru, sehingga memfasilitasi semua penulisan aplikasi untuk dialihkan ke master baru.
- Alat pacu jantung juga menyiapkan slave yang tersedia untuk mulai mereplikasi dari master baru ini.
Dengan demikian, setiap kali master MySQL down (apakah karena MySQL crash, OS crash, sistem reboot, dll), kerangka kerja HA kami mendeteksi dan mempromosikan budak yang cocok untuk mengambil alih peran master. Ini memastikan bahwa sistem terus tersedia untuk aplikasi.
Penjelasan #MySQL High Availability Framework – Bagian III:Skenario KegagalanKlik Untuk Tweet
Skenario 2 – MySQL Budak Turun
- Kerangka Corosync dan Pacemaker mendeteksi bahwa MySQL slave tidak lagi tersedia.
- Alat pacu jantung mencoba memulihkan sumber daya dengan mencoba memulai ulang MySQL pada node. Jika muncul, itu ditambahkan kembali ke master saat ini sebagai budak dan replikasi berlanjut.
- Jika pemulihan gagal, Pacemaker melaporkan resource tersebut sebagai down – berdasarkan peringatan atau notifikasi yang dapat dihasilkan. Jika perlu, tim dukungan ScaleGrid akan menangani pemulihan node ini.
- Dalam hal ini, tidak ada dampak pada ketersediaan layanan MySQL.
Skenario 3 – Partisi Jaringan – Konektivitas Jaringan Terputus Antara Node Master dan Slave
Ini adalah masalah klasik dalam sistem terdistribusi mana pun di mana setiap node mengira node lain sedang down, sedangkan pada kenyataannya, hanya komunikasi jaringan antara node yang terputus. Skenario ini lebih dikenal sebagai skenario split-brain, dan jika tidak ditangani dengan benar, dapat menyebabkan lebih dari satu node mengklaim sebagai master MySQL yang pada gilirannya menyebabkan inkonsistensi data dan korupsi.
Mari kita gunakan contoh untuk meninjau bagaimana kerangka kerja kita menangani skenario split-brain di cluster. Kami berasumsi bahwa karena masalah jaringan, cluster telah dipartisi menjadi dua grup – master di satu grup dan 2 slave di grup lain, dan kami akan menyatakan ini sebagai [(M), (S1,S2)].
- Corosync mendeteksi bahwa node master tidak dapat berkomunikasi dengan node slave, dan node slave dapat berkomunikasi satu sama lain, tetapi tidak dengan master .
- Node master tidak akan dapat melakukan transaksi apa pun karena replikasi semisinkron mengharapkan pengakuan dari setidaknya satu budak sebelum master dapat melakukan. Pada saat yang sama, Pacemaker mematikan MySQL pada master node karena kurangnya kuorum berdasarkan pengaturan Pacemaker 'no-quorum-policy =stop'. Kuorum di sini berarti mayoritas node, atau dua dari tiga dalam pengaturan cluster 3-node. Karena hanya ada satu node master yang berjalan di partisi cluster ini, setelan kebijakan tanpa kuorum dipicu yang menyebabkan master MySQL dimatikan.
- Sekarang, Alat Pacu Jantung pada partisi [(S1), (S2)] mendeteksi bahwa tidak ada master yang tersedia di cluster dan memulai proses promosi. Dengan asumsi bahwa S1 up to date dengan master (sebagaimana dijamin oleh replikasi semisinkron), kemudian dipromosikan sebagai master baru.
- Lalu lintas aplikasi akan dialihkan ke node MySQL master baru ini dan slave S2 akan mulai mereplikasi dari master baru.
Dengan demikian, kami melihat bahwa kerangka kerja MySQL HA menangani skenario split-brain secara efektif, memastikan konsistensi dan ketersediaan data jika konektivitas jaringan terputus antara node master dan slave.
Ini mengakhiri seri blog 3 bagian kami tentang kerangka kerja MySQL High Availability (HA) menggunakan replikasi semisinkron dan tumpukan Corosync plus Pacemaker. Di ScaleGrid, kami menawarkan hosting yang sangat tersedia untuk MySQL di AWS dan MySQL di Azure yang diimplementasikan berdasarkan konsep yang dijelaskan dalam seri blog ini. Kunjungi Konsol ScaleGrid untuk uji coba gratis solusi kami.
