MHA high availability deployment and Testing

I. MHA features II. MHA working mechanism and failover process parsing III. MHA applicable Master/Slave architecture IV. MHA high availability environment construction 4.1 experiment environment 4.2 experiment steps 4.3 related script description 4.4MHA deployment Process configuration 4.5

I. MHA features II. MHA working mechanism and failover process parsing III. MHA applicable Master/Slave architecture IV. MHA high availability environment construction 4.1 experiment environment 4.2 experiment steps 4.3 related script description 4.4MHA deployment Process configuration 4.5

4.1
4.2
4.3
4.4
4.5

I. MHA features

1. Automatic Monitoring and Failover of the master server
MHA monitors the master server in the replication architecture. Once the master server is detected to be faulty, failover is automatically performed. Even if some slave servers do not receive the latest relay log, MHA automatically identifies the differential relay log from the latest slave server and applies the log to other slave servers, therefore, all slave servers are consistent. MHA usually completes failover within several seconds. It can detect faults on the primary server in 9-12 seconds, and shut down the faulty primary server in 7-10 seconds to avoid split-brain, the application differential relay log in a few seconds is sent to the new master server. The entire process can be completed within 10-30 s. You can also set a priority to specify a Server Load balancer instance as the master candidate. Because MHA fixes consistency between slaves, any slave can be changed to a new master without consistency issues, resulting in replication failure.
2. Interactive master server failover

You can only use MHA failover instead of monitoring the master server. When the master server fails, MHA is manually called for failover.
3. non-interactive master failover
The master server is not monitored, but failover is automatically implemented. This feature applies to the use of other software to monitor the status of the master server, such as heartbeat to detect master server faults and virtual IP address takeover. MHA can be used to achieve failover and upgrade the slave server to the master server.
4. Switch the master server online
In many cases, you need to migrate the existing master server to another server. For example, if the hardware of the primary server is faulty, the RAID controller must be rebuilt to move the primary server to a server with better performance. Maintenance of the master server causes performance degradation, resulting in downtime at least Data Writing. In addition, blocking or killing the currently running session will cause data inconsistency between the master and the master. MHA provides fast switching and elegant blocking of writing. This switching process only takes 0.5-2 seconds, during which data cannot be written. In many cases, 0.5-2 seconds of blocking write is acceptable. Therefore, you do not need to schedule the maintenance time window for switching the master server (haha, you do not need to complete the task of switching the master server all night long when the night is dark ).

Ii. MHA Mechanism

MHA automatic Failover process Parsing

Https://code.google.com/p/mysql-master-ha/wiki/Sequences_of_MHA

Iii. Master-slave architecture applicable to MHA

Https://code.google.com/p/mysql-master-ha/wiki/UseCases

Iv. Construction of MHA high-availability environment
4.1 experiment environment

4.2 experiment steps 4.3 script instructions

MHA node has three scripts, depending on the perl Module
Save_binary_logs: stores and copies the binary logs of the Active Server.
Apply_diff_relay_logs: identifies differential relay log events and applies them to all slave server nodes.
Purge_relay_logs: clears the relay log file.

4.4 MHA deployment process

A. Configure the epel yum source at three nodes and install the relevant dependency packages.

Rpm-Uvh rpm -- import/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6yum-y install perl-DBD-MySQL ncftp

B. Establish a master-slave replication relationship

On node1:

Mysql> grant replication slave on *. * to 'rep '@' 192. 168.10.% 'identified by 'geekwolf '; mysql> grant all on *. * to 'root' @ '192. 168.10.% 'identified by 'geekwolf '; mysql> show master status;

Copy the data directory of node1 and synchronize it to node2. node3 is on node2 node3:

Mysql> change master to master_host = '2017. 168.10.216 ', master_user = 'rep', master_password = 'geekwolf ', master_port = 3306, master_log_file = 'mysql-in.000006', master_log_pos = 120, master_connect_retry = 1; mysql> start slave;

Each node has a soft link for mysql commands.

Ln-s/usr/local/mysql/bin/*/usr/local/bin/

C. ssh-keygen implements mutual key-free login between the three machines on node1 (with the other two nodes ).

Ssh-keygen-t rsa ssh-copy-id-I/root /. ssh/id_rsa.pub root @ node1 ssh-copy-id-I/root /. ssh/id_rsa.pub root @ node2 ssh-copy-id-I/root /. ssh/id_rsa.pub root @ node3

D. Three-node installation mha4mysql-node-0.56, mha4mysql-manager-0.56 installed on node3
Install mha4mysql-node in node1 node2 node3
Wget https://googledrive.com/host/0B1lu97m8-haWeHdGWXp0YVVUSlk/mha4mysql-node-0.56.tar.gz
Tar xf mha4mysql-node-0.56.tar.gz
Cd mha4mysql-node
Perl Makefile. PL
Make & make install

Install mha4mysql-manager on node3
Wget https://googledrive.com/host/0B1lu97m8-haWeHdGWXp0YVVUSlk/mha4mysql-manager-0.56.tar.gz
Tar xf mha4mysql-manager-0.56.tar.gz
Cd mha4mysql-manager-0.56
Yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Config-IniFiles perl-Time-HiRes

E. Manage the MHA configuration file on node3
Mkdir-p/etc/mha/{app1, scripts}
Cp mha4mysql-manager-0.56/samples/conf/etc/mha/
Cp mha4mysql-manager-0.56/samples/scripts/etc/mha/scripts/
Mv/etc/mha/app1.cnf/etc/mha/app1/
Mv/etc/mha/masterha_default.cnf/etc/masterha_default.cnf

Set global Configuration:
Vim/etc/mha/masterha_default.cnf

[Server default] user = rootpassword = geekwolfssh_user = rootrepl_user = reprepl_password = login = 1 # shutdown_script = "" secondary_check_script = objective-s node1-s node2-s node3 -- user = root -- master_host = node1 -- master_ip = 192.168.10.216 -- master_port = 3306 # hosts = "/etc/mha/scripts/master_ip_failover" # hosts = "/etc/mha/scripts/master_ip_online_change" # shutdown_script =/ script/masterha/power_manager # report_script = ""