Di blog kami sebelumnya, kami membahas MHA sebagai alat failover yang digunakan dalam pengaturan master-slave MySQL. Bulan lalu, kami juga membuat blog tentang cara menangani MHA saat macet. Hari ini, kita akan melihat masalah teratas yang biasanya dihadapi DBA dengan MHA, dan bagaimana Anda dapat memperbaikinya.
Pengantar Singkat Tentang MHA (Ketersediaan Tinggi Master)
MHA singkatan (Master High Availability) masih relevan dan banyak digunakan saat ini, terutama pada setup master-slave berbasis replikasi non-GTID. MHA melakukan failover atau master-switch dengan baik, tetapi ia datang dengan beberapa jebakan dan batasan. Setelah MHA melakukan failover master dan promosi slave, MHA dapat secara otomatis menyelesaikan operasi failover database dalam ~30 detik, yang dapat diterima di lingkungan produksi. MHA dapat memastikan konsistensi data. Semua ini tanpa penurunan kinerja, dan tidak memerlukan penyesuaian atau perubahan tambahan pada penerapan atau penyiapan yang ada. Selain itu, MHA dibangun di atas Perl dan merupakan solusi HA open-source - sehingga relatif mudah untuk membuat pembantu atau memperluas alat sesuai dengan pengaturan yang Anda inginkan. Lihat presentasi ini untuk informasi lebih lanjut.
Perangkat lunak MHA terdiri dari dua komponen, Anda perlu menginstal salah satu paket berikut sesuai dengan peran topologinya:
Node manajer MHA =Manajer MHA (manajer)/Node MHA (node data)
Node Master/Slave =Node MHA (node data)
MHA Manager adalah perangkat lunak yang mengelola failover (otomatis atau manual), mengambil keputusan kapan dan di mana failover, dan mengelola pemulihan slave selama promosi calon master untuk menerapkan log relai diferensial. Jika database master mati, MHA Manager akan berkoordinasi dengan agen MHA Node karena menerapkan log relai diferensial ke budak yang tidak memiliki peristiwa binlog terbaru dari master. Perangkat lunak MHA Node adalah agen lokal yang akan memantau instans MySQL Anda dan mengizinkan MHA Manager untuk menyalin log relai dari slave. Skenario tipikal adalah ketika master kandidat untuk failover saat ini tertinggal dan MHA mendeteksinya tidak memiliki log relai terbaru. Oleh karena itu, ia akan menunggu mandatnya dari MHA Manager saat mencari slave terbaru yang berisi peristiwa binlog dan menyalin peristiwa yang hilang dari slave menggunakan scp dan menerapkannya ke dirinya sendiri.
Perhatikan bahwa MHA saat ini tidak dipelihara secara aktif, tetapi versi saat ini sendiri stabil dan mungkin "cukup baik" untuk produksi. Anda masih dapat menggemakan suara Anda melalui github untuk mengatasi beberapa masalah atau memberikan tambalan ke perangkat lunak.
Masalah Umum Teratas
Sekarang mari kita lihat masalah paling umum yang akan dihadapi DBA saat menggunakan MHA.
Slave tertinggal, failover non-interaktif/otomatis gagal!
Ini adalah masalah umum yang menyebabkan failover otomatis dibatalkan atau gagal. Ini mungkin terdengar sederhana tetapi tidak menunjuk hanya pada satu masalah tertentu. Slave lag mungkin memiliki alasan yang berbeda:
- Masalah disk pada master kandidat yang menyebabkan I/O disk terikat untuk memproses baca dan tulis. Ini juga dapat menyebabkan kerusakan data jika tidak dimitigasi.
- Kueri yang buruk direplikasi terutama tabel yang tidak memiliki kunci utama atau indeks berkerumun.
- beban server tinggi.
- Server dingin dan server belum memanas
- Sumber daya server tidak cukup. Kemungkinan slave Anda memiliki memori atau sumber daya server yang terlalu rendah saat mereplikasi penulisan atau pembacaan intensif tinggi.
Itu dapat dikurangi terlebih dahulu jika Anda memiliki pemantauan yang tepat terhadap database Anda. Salah satu contoh sehubungan dengan kelambatan budak di MHA adalah memori rendah saat membuang file log biner besar. Sebagai contoh di bawah, master ditandai sebagai mati dan harus melakukan failover non-interaktif/otomatis. Namun, karena calon master tertinggal dan harus menerapkan log yang belum dieksekusi oleh utas replikasi, MHA akan menemukan budak paling mutakhir atau terbaru karena akan mencoba memulihkan budak dari yang tertua. yang. Oleh karena itu, seperti yang Anda lihat di bawah, saat melakukan pemulihan budak, memori menjadi terlalu rendah:
[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May 6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May 6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May 6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May 6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May 6 08:43:57 2019 - [info] ok.
Mon May 6 08:43:57 2019 - [info] Alive Servers:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306)
Mon May 6 08:43:57 2019 - [info] Alive Slaves:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Not candidate for the new Master (no_master is set)
Mon May 6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May 6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May 6 08:43:59 2019 - [info]
Mon May 6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May 6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May 6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May 6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007
Mon May 6 08:44:00 2019 - [info]
Relay log found at /var/lib/mysql, up to relay-bin.000007
Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
Binlog Checksum enabled
Master Version is 5.7.23-23-log
Binlog Checksum enabled
…
…...
Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
Binlog Checksum enabled
Binlog Checksum enabled
Dumping binlog format description event, from position 0 to 361.. ok.
Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090] Generating diff files failed with return code 1:0.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 08:44:00 2019 - [info]
----- Failover Report -----
app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)
Master 192.168.10.60(192.168.10.60:3306) is down!
Check MHA Manager logs at testnode20 for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.Dengan demikian, failover gagal. Contoh di atas menunjukkan bahwa node 192.168.10.70 berisi log relai terbaru. Namun, dalam skenario contoh ini, node 192.168.10.70 ditetapkan sebagai no_master karena memiliki memori yang rendah. Saat mencoba memulihkan budak 192.168.10.50, gagal!
Perbaikan/Resolusi:
Skenario ini menggambarkan sesuatu yang sangat penting. Lingkungan pemantauan tingkat lanjut harus disiapkan! Misalnya, Anda dapat menjalankan skrip latar belakang atau daemon yang memantau kesehatan replikasi. Anda dapat menambahkan sebagai entri melalui tugas cron. Misalnya, tambahkan entri menggunakan skrip bawaan masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfatau buat skrip latar belakang yang menjalankan skrip ini dan menjalankannya dalam suatu interval. Anda dapat menggunakan opsi report_script untuk menyiapkan pemberitahuan peringatan jika tidak sesuai dengan persyaratan Anda, misalnya, slave tertinggal sekitar 100 detik selama beban puncak yang tinggi. Anda juga dapat menggunakan platform pemantauan seperti ClusterControl yang mengaturnya untuk mengirimi Anda pemberitahuan berdasarkan metrik yang ingin Anda pantau.
Selain itu, perhatikan bahwa, dalam skenario contoh, failover gagal karena galat kehabisan memori. Anda mungkin mempertimbangkan untuk memastikan semua node Anda memiliki memori yang cukup dan ukuran log biner yang tepat karena mereka perlu membuang binlog untuk fase pemulihan slave.
Budak Tidak Konsisten, Menerapkan perbedaan gagal!
Terkait dengan lag slave, karena MHA akan mencoba menyinkronkan log relai ke master kandidat, pastikan data Anda sinkron. Katakan untuk contoh di bawah ini:
...
Concat succeeded.
Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May 6 05:43:53 2019 - [info] Generating diff files succeeded.
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May 6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May 6 05:43:53 2019 - [info] Generating diffs succeeded.
Mon May 6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May 6 05:43:53 2019 - [info] done.
Mon May 6 05:43:53 2019 - [info] Getting slave status..
Mon May 6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May 6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May 6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50 --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May 6 05:43:53 2019 - [info]
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------
Bye
at /usr/local/bin/apply_diff_relay_logs line 554.
eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399] Applying diffs failed with return code 22:0.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 05:43:53 2019 - [info]Cluster yang tidak konsisten benar-benar buruk terutama ketika failover otomatis diaktifkan. Dalam kasus ini, failover tidak dapat dilanjutkan karena mendeteksi entri duplikat untuk kunci utama '12583545 '.
Perbaikan/Resolusi:
Ada beberapa hal yang dapat Anda lakukan di sini untuk menghindari status cluster yang tidak konsisten.
- Aktifkan Replikasi Semi-Sinkron Lossless. Lihat blog eksternal ini yang merupakan cara yang baik untuk mempelajari mengapa Anda harus mempertimbangkan untuk menggunakan semi-sinkronisasi dalam pengaturan replikasi MySQL standar.
- Jalankan checksum secara konstan terhadap kluster master-slave Anda. Anda dapat menggunakan pt-table-checksum dan menjalankannya seperti seminggu atau sebulan sekali tergantung pada seberapa konstan tabel Anda diperbarui. Perhatikan bahwa pt-table-checksum dapat menambahkan overhead ke lalu lintas database Anda.
- Gunakan replikasi berbasis GTID. Meskipun ini tidak akan memengaruhi masalah itu sendiri. Namun, replikasi berbasis GTID membantu Anda menentukan transaksi yang salah, terutama transaksi yang dijalankan pada slave secara langsung. Keuntungan lain dari ini, lebih mudah untuk mengelola replikasi berbasis GTID saat Anda perlu mengganti host master dalam replikasi.
Kegagalan Perangkat Keras Pada Master Tapi Budak Belum Tertangkap
Salah satu dari banyak alasan mengapa Anda berinvestasi dalam failover otomatis adalah kegagalan perangkat keras pada master. Untuk beberapa pengaturan, mungkin lebih ideal untuk melakukan failover otomatis hanya ketika master mengalami kegagalan perangkat keras. Pendekatan yang biasa dilakukan adalah memberi tahu dengan mengirimkan alarm - yang mungkin berarti membangunkan petugas operasi panggilan di tengah malam, membiarkan orang tersebut memutuskan apa yang harus dilakukan. Jenis pendekatan ini dilakukan di Github atau bahkan Facebook. Kegagalan perangkat keras, terutama jika volume tempat binlog dan direktori data Anda terpengaruh, dapat mengacaukan failover Anda terutama jika log biner disimpan pada disk yang gagal itu. Secara desain, MHA akan mencoba untuk menyimpan log biner dari master yang mogok tetapi ini tidak dapat dilakukan jika disk gagal. Salah satu skenario yang mungkin terjadi adalah server tidak dapat dijangkau melalui SSH. MHA tidak dapat menyimpan log biner dan harus melakukan failover tanpa menerapkan peristiwa log biner yang ada pada master yang crash saja. Hal ini akan mengakibatkan hilangnya data terbaru, terutama jika tidak ada slave yang mengejar master.
Perbaikan/Resolusi
Sebagai salah satu kasus penggunaan oleh MHA, direkomendasikan untuk menggunakan replikasi semi-sinkron karena sangat mengurangi risiko kehilangan data tersebut. Penting untuk dicatat bahwa setiap penulisan yang masuk ke master harus memastikan bahwa slave telah menerima peristiwa log biner terbaru sebelum menyinkronkan ke disk. MHA dapat menerapkan acara ke semua budak lain sehingga mereka bisa konsisten satu sama lain.
Selain itu, lebih baik juga menjalankan aliran cadangan log biner Anda untuk pemulihan bencana jika volume disk utama gagal. Jika server masih dapat diakses melalui SSH, maka mengarahkan jalur log biner ke jalur cadangan log biner Anda masih dapat berfungsi, sehingga failover dan pemulihan budak masih dapat dilanjutkan. Dengan cara ini, Anda dapat menghindari kehilangan data.
Kegagalan VIP (Virtual IP) Menyebabkan Otak Terbelah
MHA, secara default, tidak menangani manajemen VIP apa pun. Namun, mudah untuk menggabungkan ini dengan konfigurasi MHA dan menetapkan kait sesuai dengan apa yang Anda ingin MHA lakukan selama failover. Anda dapat mengatur skrip Anda sendiri dan menghubungkannya ke parameter master_ip_failover_script atau master_ip_online_change_script. Ada juga contoh skrip yang terletak di direktori
Selama failover otomatis, setelah skrip Anda dengan manajemen VIP dipanggil dan dijalankan, MHA akan melakukan hal berikut:memeriksa status, menghapus (atau menghentikan) VIP lama, lalu menetapkan ulang VIP baru ke master baru. Contoh khas dari otak terbelah adalah, ketika master diidentifikasi mati karena masalah jaringan tetapi pada kenyataannya, node budak masih dapat terhubung ke master. Ini adalah positif palsu, dan sering menyebabkan inkonsistensi data di seluruh database dalam penyiapan. Koneksi klien yang masuk menggunakan VIP akan dikirim ke master baru. Sementara di sisi lain, mungkin ada koneksi lokal yang berjalan di master lama, yang seharusnya mati. Koneksi lokal dapat menggunakan soket unix atau localhost untuk mengurangi lompatan jaringan. Hal ini dapat menyebabkan data berpindah ke master baru dan slave lainnya, karena data dari master lama tidak akan direplikasi ke slave.
Perbaikan/Resolusi:
Seperti yang dinyatakan sebelumnya, beberapa mungkin lebih memilih untuk menghindari failover otomatis kecuali pemeriksaan telah menentukan bahwa master benar-benar mati (seperti kegagalan perangkat keras), yaitu bahkan node budak tidak dapat mencapainya. Idenya adalah bahwa positif palsu dapat disebabkan oleh kesalahan jaringan antara pengontrol node MHA dan master, sehingga manusia mungkin lebih cocok dalam kasus ini untuk membuat keputusan apakah akan melakukan failover atau tidak.
Saat berhadapan dengan alarm palsu, MHA memiliki parameter yang disebut secondary_check_script. Nilai yang ditempatkan di sini dapat berupa skrip khusus Anda atau Anda dapat menggunakan skrip bawaan /usr/local/bin/masterha_secondary_check yang dikirimkan bersama dengan paket MHA Manager. Ini menambahkan pemeriksaan ekstra yang sebenarnya merupakan pendekatan yang disarankan untuk menghindari kesalahan positif. Dalam contoh di bawah ini dari pengaturan saya sendiri, saya menggunakan skrip bawaan masterha_secondary_check :
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306Pada contoh di atas, MHA Manager akan melakukan loop berdasarkan daftar node slave (ditentukan oleh argumen -s) yang akan memeriksa koneksi terhadap host MySQL master (192.168.10.60). Perhatikan bahwa, node budak dalam contoh ini dapat berupa beberapa node jarak jauh eksternal yang dapat membuat koneksi ke node database dalam cluster. Ini adalah pendekatan yang disarankan terutama untuk pengaturan di mana MHA Manager berjalan pada pusat data yang berbeda atau jaringan yang berbeda dari node database. Urutan berikut di bawah ini mengilustrasikan bagaimana prosesnya dengan pemeriksaan:
- Dari MHA Host -> periksa koneksi TCP ke 1st Slave Node (IP:192.168.10.50). Sebut saja ini sebagai Connection A. Kemudian dari Slave Node, cek koneksi TCP ke Master Node (192.168.10.60). Sebut saja Koneksi ini B.
Jika "Sambungan A" berhasil tetapi "Sambungan B" tidak berhasil di kedua rute, masterha_secondary_check skrip keluar dengan kode pengembalian 0 dan Manajer MHA memutuskan bahwa master MySQL benar-benar mati, dan akan memulai failover. Jika "Koneksi A" tidak berhasil, masterha_secondary_check keluar dengan kode kembali 2 dan Manajer MHA menebak bahwa ada masalah jaringan dan tidak memulai failover. Jika "Koneksi B" berhasil, masterha_secondary_check keluar dengan kode kembali 3 dan MHA Manager memahami bahwa server master MySQL sebenarnya hidup, dan tidak memulai failover.
Contoh bagaimana reaksinya selama failover berdasarkan log,
Tue May 7 05:31:57 2019 - [info] OK.
Tue May 7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May 7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May 7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May 7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May 7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May 7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May 7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May 7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May 7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May 7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May 7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May 7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May 7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May 7 05:32:04 2019 - [info] Executing SSH check script: exit 0Hal lain yang perlu ditambahkan adalah menetapkan nilai ke parameter shutdown_script. Skrip ini sangat berguna jika Anda harus menerapkan STONITH atau node fencing yang tepat sehingga tidak akan bangkit dari kematian. Ini dapat menghindari inkonsistensi data.
Terakhir, pastikan MHA Manager berada dalam jaringan lokal yang sama bersama dengan node cluster karena hal ini akan mengurangi kemungkinan pemadaman jaringan, terutama koneksi dari MHA Manager ke node database.
Menghindari SPOF di MHA
MHA dapat macet karena berbagai alasan, dan sayangnya, tidak ada fitur bawaan untuk memperbaikinya, yaitu Ketersediaan Tinggi untuk MHA. Namun, seperti yang telah kita bahas di blog sebelumnya "Master High Availability Manager (MHA) Telah Rusak! Apa yang Harus Saya Lakukan Sekarang?", ada cara untuk menghindari SPOF untuk MHA.
Perbaikan/Resolusi:
Anda dapat memanfaatkan Pacemaker untuk membuat node aktif/siaga yang ditangani oleh manajer sumber daya cluster (crm). Atau, Anda dapat membuat skrip untuk memeriksa kesehatan node manajer MHA. Misalnya, Anda dapat menyediakan node siaga yang secara aktif memeriksa node pengelola MHA dengan ssh'ing untuk menjalankan skrip bawaan masterha_check_status seperti di bawah ini:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).kemudian lakukan beberapa pagar simpul jika pengontrol itu dibor. Anda juga dapat memperluas alat MHA dengan skrip pembantu yang berjalan melalui cron job dan memantau proses sistem skrip masterha_manager dan memunculkannya kembali jika proses mati.
Data Hilang Selama Failover
MHA bergantung pada replikasi async tradisional. Meskipun mendukung semi-sinkronisasi, tetap saja, semi-sinkronisasi bergantung pada replikasi asinkron. Dalam jenis lingkungan ini, kehilangan data dapat terjadi setelah failover. Ketika database Anda tidak diatur dengan benar dan menggunakan pendekatan replikasi kuno, maka hal itu dapat menyusahkan terutama ketika berhadapan dengan konsistensi data dan transaksi yang hilang.
Hal penting lainnya yang perlu diperhatikan dengan kehilangan data dengan MHA, adalah ketika GTID digunakan tanpa semi-sinkronisasi diaktifkan. MHA dengan GTID tidak akan terhubung melalui ssh ke master tetapi akan mencoba menyinkronkan log biner untuk pemulihan node dengan budak terlebih dahulu. Hal ini berpotensi menyebabkan lebih banyak kehilangan data dibandingkan dengan MHA non-GTID dengan semi-sinkronisasi tidak diaktifkan.
Perbaikan/Resolusi
Saat melakukan failover otomatis, buat daftar skenario saat Anda mengharapkan MHA Anda untuk failover. Karena MHA berurusan dengan replikasi master-slave, maka saran kami kepada Anda untuk menghindari kehilangan data adalah sebagai berikut:
- Aktifkan replikasi semi-sinkronisasi lossless (ada di versi MySQL 5.7)
- Gunakan replikasi berbasis GTID. Tentu saja, Anda dapat menggunakan replikasi tradisional dengan menggunakan koordinat x &y binlog. Namun, itu membuat segalanya lebih sulit dan memakan waktu ketika Anda perlu mencari entri log biner tertentu yang tidak diterapkan pada slave. Oleh karena itu, dengan GTID di MySQL, lebih mudah untuk mendeteksi transaksi yang salah.
- Untuk kepatuhan ACID replikasi master-slave MySQL Anda, aktifkan variabel spesifik berikut:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Ini mahal karena membutuhkan lebih banyak kekuatan pemrosesan saat MySQL memanggil fungsi fsync() saat dijalankan, dan kinerja dapat diikat ke disk jika jumlah penulisan tinggi. Namun, menggunakan RAID dengan cache cadangan baterai akan menghemat I/O disk Anda. Selain itu, MySQL sendiri telah ditingkatkan dengan komit grup log biner tetapi masih menggunakan cache cadangan dapat menghemat beberapa sinkronisasi disk.
- Manfaatkan replikasi paralel atau replikasi slave multi-utas. Ini dapat membantu budak Anda menjadi lebih berperforma, dan menghindari kelambatan budak melawan master. Anda tidak ingin failover otomatis Anda terjadi ketika master tidak dapat dijangkau sama sekali melalui koneksi ssh atau tcp, atau jika mengalami kegagalan disk, dan slave Anda tertinggal. Hal itu dapat menyebabkan hilangnya data.
- Saat melakukan failover online atau manual, sebaiknya Anda melakukannya selama periode non-puncak untuk menghindari kecelakaan tak terduga yang dapat menyebabkan hilangnya data. Atau untuk menghindari pencarian yang memakan waktu untuk menelusuri log biner Anda saat ada banyak aktivitas yang sedang berlangsung.
MHA Mengatakan APP Tidak Berjalan, atau Failover Tidak Bekerja. Apa yang Harus Saya Lakukan?
Menjalankan pemeriksaan menggunakan skrip bawaan masterha_check_status akan memeriksa apakah skrip mastreha_manager sedang berjalan. Jika tidak, Anda akan mendapatkan kesalahan seperti di bawah ini:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Namun, ada kasus tertentu di mana Anda mungkin mendapatkan NOT_RUNNING bahkan ketika masterha_manager sedang berlari. Hal ini dapat terjadi karena hak istimewa ssh_user yang Anda tetapkan, atau Anda menjalankan masterha_manager dengan pengguna sistem yang berbeda, atau pengguna ssh mengalami penolakan izin.
Perbaikan/Resolusi:
MHA akan menggunakan ssh_user didefinisikan dalam konfigurasi jika ditentukan. Jika tidak, akan menggunakan pengguna sistem saat ini yang Anda gunakan untuk menjalankan perintah MHA. Saat menjalankan skrip masterha_check_status misalnya, Anda perlu memastikan bahwa masterha_manager berjalan dengan pengguna yang sama yang ditentukan di ssh_user di file konfigurasi Anda, atau pengguna yang akan berinteraksi dengan node database lain di cluster. Anda perlu memastikan bahwa ia memiliki kunci SSH tanpa kata sandi, tanpa frasa sandi, sehingga MHA tidak akan mengalami masalah saat membuat koneksi ke node yang dipantau MHA.
Perhatikan bahwa Anda memerlukan ssh_user untuk memiliki akses ke berikut ini:
- Dapat membaca log biner dan relai dari node MySQL yang dipantau MHA
- Harus memiliki akses ke log pemantauan MHA. Lihat parameter ini di MHA:master_binlog_dir, manager_workdir, dan manager_log
- Harus memiliki akses ke file konfigurasi MHA. Ini juga sangat penting. Selama failover, setelah failover selesai, ia akan mencoba memperbarui file konfigurasi dan menghapus entri master yang mati. Jika file konfigurasi tidak mengizinkan ssh_user atau pengguna OS yang Anda gunakan saat ini, tidak akan memperbarui file konfigurasi, yang mengarah ke eskalasi masalah jika bencana menyerang lagi.
Kandidat Master Lag, Cara Memaksa Dan Menghindari Failover yang Gagal
Mengacu pada wiki MHA, secara default, jika seorang budak di belakang master lebih dari 100MB log relai (=perlu menerapkan lebih dari 100MB log relai), MHA tidak memilih budak sebagai master baru karena terlalu lama untuk memulihkan .
Perbaikan/Resolusi
Di MHA, ini dapat ditimpa dengan menyetel parameter check_repl_delay=0. Selama failover, MHA mengabaikan penundaan replikasi saat memilih master baru dan akan mengeksekusi transaksi yang hilang. Opsi ini berguna saat Anda menetapkan kandidat_master=1 pada host tertentu dan Anda ingin memastikan bahwa host tersebut dapat menjadi master baru.
Anda juga dapat berintegrasi dengan pt-heartbeat untuk mencapai akurasi slave lag (lihat posting ini dan yang ini). Tetapi ini juga dapat dikurangi dengan replikasi paralel atau slave replikasi multi-utas, hadir sejak MySQL 5.6 atau, dengan MariaDB 10 - mengklaim memiliki dorongan dengan peningkatan 10x dalam replikasi paralel dan budak multi-utas. Ini dapat membantu budak Anda mereplikasi lebih cepat.
Kata Sandi MHA Terungkap
Mengamankan atau mengenkripsi kata sandi bukanlah sesuatu yang ditangani oleh MHA. The parameters password or repl_password will be exposed via the configuration file. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.
Fixes/Resolution:
MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.
Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.
MHA is Not My Choice, What Are the Alternatives for replication failover?
MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.
- PRM
- Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
- Orchestrator
- ClusterControl
