MySQL 41st article ~mha Some aspects of the discussion of a

Introduction: MHA Online has been a long time, but did not write an article, today said

Two preliminary ideas: I am today from the perspective of the journal analysis, to talk about their own ideas

Three-switch process

A copy of the Binlog stage
1 Getting Latest slaves Phase.
The latest binary log file/position on all slaves is mysql-bin.000102:219273659 (according to the command to get the latest Binlog information)
The oldest binary log file/position on all slaves is mysql-bin.000102:219273659 (gets the oldest binlog information according to the command)
Note that the Binlog information obtained here is read in all slave (configuration files) (Read_master_log_pos and Master_log_file)
2 saving Dead Master ' s Binlog Phase (for Binlog retention and copy)
1 Execute related commands save_binary_logs--command=save--start_file=mysql-bin.1--start_pos=position--binlog_dir=/data/mysql/data /--output_file=/var/tmp/xx.binlog--handle_raw_binlog=1--disable_log_bin=0--manager_version=0.56
Note 1 retention is based on the Binlog information obtained from Phase 1 and is saved in the MHA Manager folder, named Xx.binlog
Two new main election stage
1 determining New Master Phase. (for the new main election phase)
1 Finding the latest slave that have all relay logs for recovering other slaves (looking for the latest relay log from the library as recovery from the other library)
2 searching new master from slaves. (from these libraries to find new from the library as the main library)
3 candidate Masters from the configuration file (choose the priority configuration from the profile, it is important to note that if the priority policy is configured, the priority will become the main, and some settings cannot be the primary)
4 new Master is IP (election of the main)
Four new primary recovery phases
1 New Master Diff Log Generation Phase. (Main library vs Binlog vs Relay-log diff log)
2 Master Log Apply Phase. (Main library app Binlog and relay-log differencing log)
All relay logs were successfully applied (main library differential log application complete)
3 Getting new Master's binlog name and position. (Get the new Master's Binlog information)
4 All miscellaneous slaves should start replication from here (generate additional from library change statement)
5 executing master IP Activate script (performs a script switch, VIP drifts)
Db_master_ip_failover--command=start--ssh_user=root--orig_master_host=--orig_master_ip=--orig_master_port=-- new_master_host=--new_master_ip=--new_master_port=--new_master_user= "--new_master_password="

Five other recovery stages from the library
 1 slaves Recovery Phase. Open from library recovery process)
   1 starting Parallel Slave Diff log Generation Phase. Turn on parallel from library log relay-log compare
   2 Sta Rting Parallel Slave Log Apply Phase. Open parallel from library log application
  Note the tools used here are also apply_diff_relay_logs, and we can see that this tool plays a very important role in MHA data differentiation and completion, The Relay-log contrast here should be the Relay-log comparison of all other slave
2 Executed change MASTER. Re-change from library to main library)
 1 all relay logs were successfully applied. (Make sure all relay-log are completed, that is, the previous step is applied)
 2 resetting slave and starting replication from the new master (reset slave and reset)
 3 start slave (open from Library application)
Six recovery complete

Seven Related script action description
1 save_binary_logs If the master binary log can be accessed, save the copy Master's binary log to ensure that the data is not lost to the maximum extent
2 Apply_diff_relay_logs generates a differential trunk log relative to the latest slave and applies all differential events to all other slave
1 for generating differential log events Comparison example
Apply_diff_relay_logs--command=generate_and_send--target_version=5.1.56--scp_user=s--scp_host=s--latest_mlf=s- -target_mlf=s--target_rmlp=i--relay_log_info=s--server_id=i--diff_file_readtolatest=s--target_version=s-- Workdir=s--timestamp=s
2 Applying Relay Log application Example
Apply_diff_relay_logs--command=apply--target_version=5.1.56--slave_user=s--slave_host=s--slave_ip=s--slave_ Port=i--apply_files=file1,file2. --workdir=s--timestamp=s--slave_pass=xxx

3 Purge_relay_logs Delete the trunk log without blocking the SQL thread for use from the library
4 db_master_ip_failover VIP Drift (need to write it yourself, there are 2 mature versions on the Internet, respectively, Shell/perl version)
5 Masterha_secondary_check Second detection script, recommended to add, the selected IP is the configuration file from the library can be

Eight description of auto-toggle related switch failure

1 All replication function (Io/sql) threads are running normally
2 All show slave status outputs have seconds_behind_master parameters less than or equal to running_updates_limit seconds, if Running_updates_limit is not specified during the switchover process, Then Running_updates_limit is 1 seconds by default
3 Second detection script configured IP is incorrect, may also cause a switchover failure, such as switching once again after switching (I have encountered)

Nine more notes.
1 MHA does not recommend manual switching, regardless of the circumstances, we are using failover mode
2 0.56 MHA can already support Gtid mode, faster and safer
3 for MHA monitoring can be used to monitor the MHA process, once triggered the switch, the MHA process will die.
4 MHA Manager in the event of a switchover failure, be sure to observe the log and analyze the cause.
5 Skilled Perl technicians can delve into the core script of MHA, I do not understand.

This is a bit of my experience, there are problems can be timely message, I am also a rookie haha

MySQL 41st article ~mha Some aspects of the discussion of a