MySQL Master Library Failover terutamanya termasuk empat langkah. 1. Pengesanan Kesalahan: Secara kerap memeriksa proses perpustakaan utama, status sambungan dan pertanyaan mudah untuk menentukan sama ada ia adalah downtime, menetapkan mekanisme semula untuk mengelakkan salah faham, dan boleh menggunakan alat seperti MHA, Orchestrator atau yang disimpan untuk membantu dalam pengesanan; 2. Pilih Perpustakaan Utama Baru: Pilih Perpustakaan Hamba yang paling sesuai untuk menggantikannya mengikut Kemajuan Penyegerakan Data (SecondS_Behind_Master), integriti data binLog, kelewatan rangkaian dan keadaan beban, dan melakukan pampasan data atau campur tangan manual jika perlu; 3. Tukar Topologi: Titik perpustakaan hamba lain ke perpustakaan induk baru, laksanakan master reset atau aktifkan GTID, kemas kini VIP, DNS atau konfigurasi proksi untuk mencapai suis aplikasi telus; 4. Kerjasama lapisan aplikasi: Pelanggan mesti menyokong penyambungan semula automatik, pengendalian pengecualian, dan mekanisme DNS seperti penyegaran cache, digabungkan dengan middleware kolam sambungan seperti HikariCP untuk meningkatkan toleransi kesalahan dan memastikan peralihan perkhidmatan yang lancar.

MySQL Master Library Failover adalah pautan utama dalam seni bina yang tinggi. Tujuannya adalah dengan cepat memindahkan lalu lintas ke perpustakaan hamba apabila pengecualian berlaku di perpustakaan utama untuk memastikan perkhidmatan tersebut tersedia secara berterusan. Proses ini biasanya termasuk beberapa langkah seperti mengesan kegagalan, memilih perpustakaan induk baru, dan menukar sambungan klien.

1. Pengesanan kesalahan: Bagaimana untuk menentukan sama ada terdapat masalah dengan perpustakaan utama?

Secara automatik atau secara manual mengesahkan sama ada perpustakaan utama benar -benar downtime adalah langkah pertama dalam keseluruhan proses. Amalan biasa adalah dengan kerap mengesan status kesihatan perpustakaan utama melalui sistem pemantauan, seperti:

• Periksa sama ada proses mysql berjalan
• Cuba buat sambungan pangkalan data
• Jalankan pertanyaan SQL sederhana (seperti SELECT 1 )

Sebaik sahaja ia gagal beberapa kali berturut -turut, perpustakaan utama dianggap tidak tersedia. Harus diingat bahawa jitter rangkaian juga boleh menyebabkan salah laku, jadi mekanisme semula dan masa tamat biasanya ditetapkan untuk mengelakkan penukaran yang tidak perlu.

Sesetengah alat seperti MHA, Orchestrator atau Keepalived boleh digunakan untuk pengesanan kesalahan.

2. Pilih perpustakaan utama baru: Siapa yang akan mengambil alih?

Selepas mengesahkan bahawa perpustakaan induk gagal, langkah seterusnya adalah memilih nod yang sesuai dari perpustakaan hamba yang sedia ada sebagai perpustakaan induk baru.

Kriteria pemilihan umumnya termasuk:

• Kemajuan Penyegerakan Data (lihat Seconds_Behind_Master )
• Adakah data binlog terkini
• Latensi dan kestabilan rangkaian
• Keadaan beban contoh

Idealnya, anda harus memilih perpustakaan hamba yang paling dekat dengan perpustakaan induk asal, yang dapat mengurangkan risiko kehilangan data. Sekiranya banyak perpustakaan hamba tertinggal di belakang banyak, pampasan data atau campur tangan manual mungkin diperlukan.

MHA secara automatik cuba mengisi kayu balak, sementara Orchestrator dapat melihat topologi dan membuat keputusan melalui API.

3. Beralih ke topologi: Biarkan nod lain tahu siapa tuan baru

Selepas menentukan perpustakaan induk baru, perkara seterusnya yang perlu dilakukan ialah menunjuk perpustakaan hamba yang lain ke perpustakaan induk baru dan mengemas kini konfigurasi lapisan aplikasi untuk memastikan permintaan menulis tiba dengan betul.

Operasi khusus termasuk:

• Jalankan RESET MASTER atau Dayakan GTID di Perpustakaan Utama Baru
• Perpustakaan Hamba Lain Melaksanakan CHANGE MASTER TO Menunjuk kepada Master Baru
• Kemas kini konfigurasi VIP atau DNS untuk membolehkan aplikasi bertukar secara telus
• Sekiranya anda menggunakan proksi (seperti ProxySQL, MaxScale), anda juga mesti mengemas kini konfigurasinya

Kunci langkah ini adalah untuk cuba menjadi "lancar" dan mengelakkan gangguan perniagaan. Sesetengah penyelesaian juga akan memudahkan logik beralih dalam kombinasi dengan IP maya atau mekanisme penemuan perkhidmatan.

4. Kerjasama lapisan permohonan: Jangan lupa pelanggan

Walaupun penukaran selesai pada tahap pangkalan data, jika aplikasi tidak melihat perubahan dalam masa, ralat sambungan masih akan berlaku.

Untuk menangani masalah ini, kaedah berikut boleh dipertimbangkan:

• Gunakan middleware kolam sambungan untuk menyokong penyambungan semula automatik dan pemisahan baca-menulis
• Tambahkan logik semula dan pengendalian pengecualian ke kod klien
• Bersempena dengan strategi penyegaran cache DNS, pastikan aplikasi mendapat alamat terkini

Sebagai contoh, menggunakan Hikaricp atau Mybatis dari Spring Boot, anda boleh menetapkan masa tamat sambungan dan bilangan maksimum retries untuk meningkatkan toleransi kesalahan.

Pada dasarnya ini adalah langkah -langkah. Walaupun proses keseluruhannya tidak kelihatan rumit, terdapat banyak butiran dalam penggunaan sebenar yang mudah diabaikan, seperti kelewatan replikasi, konsistensi GTID, konfigurasi kebenaran dan isu -isu lain. Adalah disyorkan untuk melakukan lebih banyak latihan sebelum dilancarkan secara rasmi untuk memastikan failover dapat dilaksanakan dengan lancar.

Atas ialah kandungan terperinci Apakah proses tipikal untuk failover Master MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!