Replikasi MySQL adalah cara yang sangat populer untuk membangun lapisan basis data yang sangat tersedia. Ini sangat terkenal, teruji dan kuat. Ini bukan tanpa batasan. Salah satunya, tentu saja, adalah fakta bahwa ia hanya menggunakan satu "titik masuk" - Anda memiliki server khusus di topologi, master, dan itu adalah satu-satunya node dalam cluster yang dapat Anda gunakan untuk menulis. Hal ini menyebabkan konsekuensi yang parah - master adalah satu-satunya titik kegagalan dan, jika gagal, tidak ada penulisan yang dapat dijalankan oleh aplikasi. Tidak mengherankan bahwa banyak pekerjaan telah dilakukan untuk mengembangkan alat, yang akan mengurangi dampak kerugian master. Tentu, ada diskusi bagaimana mendekati topik, apakah failover otomatis lebih baik daripada manual atau tidak. Pada akhirnya, ini adalah keputusan bisnis yang harus diambil tetapi jika Anda memutuskan untuk mengikuti jalur otomatisasi, Anda akan mencari alat untuk membantu Anda mencapainya. Salah satu tools yang masih sangat populer adalah MHA (Master High Availability). Meskipun mungkin tidak dipelihara secara aktif lagi, ia masih dalam bentuk yang stabil dan popularitasnya yang besar masih menjadikannya tulang punggung dari pengaturan replikasi MySQL yang tersedia. Namun, apa yang akan terjadi jika MHA itu sendiri tidak tersedia? Bisakah itu menjadi satu titik kegagalan? Apakah ada cara untuk mencegahnya terjadi? Dalam posting blog ini kita akan melihat beberapa skenario.
Hal pertama yang pertama, jika Anda berencana untuk menggunakan MHA, pastikan Anda menggunakan versi terbaru dari repo. Jangan gunakan rilis biner karena tidak berisi semua perbaikan. Instalasi cukup sederhana. MHA terdiri dari dua bagian, manager dan node. Node akan digunakan di server database Anda. Manajer akan ditempatkan pada host terpisah, bersama dengan node.js. Jadi, server database:node, host manajemen:manajer dan node.
Sangat mudah untuk mengkompilasi MHA. Buka GitHub dan klon repositori.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Maka ini semua tentang:
perl Makefile.PL
make
make installAnda mungkin harus menginstal beberapa ketergantungan Perl jika Anda belum menginstal semua paket yang diperlukan. Dalam kasus kami, di Ubuntu 16.04, kami harus menginstal yang berikut:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Setelah Anda menginstal MHA, Anda perlu mengonfigurasinya. Kami tidak akan membahas detail apa pun di sini, ada banyak sumber di internet yang membahas bagian ini. Contoh konfigurasi (pasti non-produksi) mungkin terlihat seperti ini:
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1Langkah selanjutnya adalah melihat apakah semuanya berfungsi dan bagaimana MHA melihat replikasi:
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Yah, itu jatuh. Ini karena MHA mencoba mengurai versi MySQL dan tidak mengharapkan tanda hubung di dalamnya. Untungnya, perbaikannya mudah ditemukan:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Sekarang, kami memiliki MHA yang siap bekerja.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Seperti yang Anda lihat, MHA memantau topologi replikasi kami, memeriksa apakah master node tersedia atau tidak. Mari kita pertimbangkan beberapa skenario.
Skenario 1 - MHA Hancur
Mari kita asumsikan MHA tidak tersedia. Bagaimana ini mempengaruhi lingkungan? Jelas, karena MHA bertanggung jawab untuk memantau kesehatan master dan memicu failover, ini tidak akan terjadi ketika MHA sedang down. Master crash tidak akan terdeteksi, failover tidak akan terjadi. Masalahnya adalah, Anda tidak dapat benar-benar menjalankan beberapa instans MHA secara bersamaan. Secara teknis, Anda dapat melakukannya meskipun MHA akan mengeluh tentang file kunci:
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.Ini akan mulai, meskipun, dan akan mencoba untuk memantau lingkungan. Masalahnya adalah ketika keduanya mulai melakukan tindakan di cluster. Kasus yang lebih buruk adalah jika mereka memutuskan untuk menggunakan budak yang berbeda sebagai kandidat master dan failover akan dieksekusi pada saat yang sama (MHA menggunakan file kunci yang mencegah failover berikutnya terjadi tetapi jika semuanya terjadi pada waktu yang sama, dan itu terjadi di kami tes, tindakan keamanan ini tidak cukup).
Sayangnya, tidak ada cara built-in untuk menjalankan MHA dengan cara yang sangat tersedia. Solusi paling sederhana adalah menulis skrip yang akan menguji apakah MHA berjalan dan jika tidak, mulai. Skrip tersebut harus dijalankan dari cron atau ditulis dalam bentuk daemon, jika perincian 1 menit cron tidak cukup.
Skenario 2 - Node Pengelola MHA Kehilangan Koneksi Jaringan ke Master
Jujur saja, ini adalah situasi yang sangat buruk. Segera setelah MHA tidak dapat terhubung ke master, ia akan mencoba melakukan failover. Satu-satunya pengecualian adalah jika secondary_check_script didefinisikan dan memverifikasi bahwa master masih hidup. Terserah pengguna untuk menentukan tindakan apa yang harus dilakukan MHA untuk memverifikasi status master - semuanya tergantung pada lingkungan dan pengaturan yang tepat. Skrip lain yang sangat penting untuk didefinisikan adalah master_ip_failover_script - ini dijalankan saat failover dan harus digunakan, antara lain, untuk memastikan bahwa master lama tidak akan muncul. Jika Anda memiliki akses ke cara tambahan untuk menjangkau dan menghentikan master lama, itu sangat bagus. Ini bisa berupa alat manajemen jarak jauh seperti Integrated Lights-out, dapat berupa akses ke soket daya yang dapat dikelola (di mana Anda dapat mematikan server), dapat berupa akses ke CLI penyedia cloud, yang akan memungkinkan untuk menghentikan instance virtual . Sangat penting untuk menghentikan master lama - jika tidak, mungkin terjadi bahwa, setelah masalah jaringan hilang, Anda akan berakhir dengan dua node yang dapat ditulisi dalam sistem, yang merupakan solusi sempurna untuk otak terbelah, suatu kondisi di mana data menyimpang antara dua bagian dari cluster yang sama.
Seperti yang Anda lihat, MHA dapat menangani failover MySQL dengan cukup baik. Itu pasti membutuhkan konfigurasi yang hati-hati dan Anda harus menulis skrip eksternal, yang akan digunakan untuk membunuh master lama dan memastikan bahwa otak terbelah tidak akan terjadi. Karena itu, kami masih akan merekomendasikan untuk menggunakan alat manajemen failover yang lebih canggih seperti Orchestrator atau ClusterControl, yang dapat melakukan analisis lebih lanjut dari status topologi replikasi (misalnya, dengan memanfaatkan budak atau proxy untuk menilai ketersediaan master) dan yang mana dan akan dipertahankan kedepannya. Jika Anda tertarik untuk mempelajari bagaimana ClusterControl melakukan failover, kami ingin mengundang Anda untuk membaca posting blog ini tentang proses failover di ClusterControl. Anda juga dapat mempelajari bagaimana ClusterControl berinteraksi dengan ProxySQL yang menghasilkan failover transparan yang mulus untuk aplikasi Anda. Anda selalu dapat menguji ClusterControl dengan mengunduhnya secara gratis.
