How does the MHA High availability Architecture work? Main library downtime process

Main library downtime process

1. Monitor nodes (get all node information through configuration files)

System, network, SSH connectivity

Master-slave status, focusing on the master library

two。 Choose the master

(1) if the slave database (position or GTID) is judged to be different, the slave that is closest to the Master becomes the candidate.

(2) if it is judged that the slave database (position or GTID) is consistent with the data, choose the master according to the order of the configuration file.

(3) if the weight is set (candidate_master=1), the alternate master is forcibly designated according to the weight.

1. By default, if a slave lags behind a master 100 M relay logs, it will fail even if it has a weight.

two。 If check_repl_delay=0 is changed, even if it lags far behind, it will be forced to be selected as the candidate.

3. Data compensation

(1) when SSH can connect, compare the slave database with the master database GTID or position number, immediately save the binary log to each slave node and apply (save_binary_logs)

(2) when SSH cannot be connected, compare the difference of relaylog between slave libraries (apply_diff_relay_logs)

4. Failover

Switch the identity of the candidate to provide services to the outside world

The rest of the slave library and the new master library confirm the new master-slave relationship

5. Application transparency (VIP)

6. Failover notification (send_reprt)

7. Quadratic data compensation (binlog_server)