MySQL High-availability MHA (Supplemental 3)-manages multiple sets of master-slave replication

Earlier we learned that MHA manages a group of master and slave, however different applications in the actual production environment will use different databases, so there will be multiple sets of master-slave replication, we can use a MHA manager to manage multiple sets of master-slave replication database. We only need to create a global profile, you can write the same configuration information in these groups to the global profile, such as user name, password, etc., while other configuration information is written separately in each app*.cnf.

Website Introduction:

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

Let's introduce the following:

MHA Architecture:

As above: We use a MHA Manager node to manage 3 sets of master-slave replication, I only configure two groups, each set of specific configuration please refer to the previous blog post, here only focus.

10.10.10.59 MHA Manager

APP1:

10.10.10.56 Master

10.10.10.57 slave1

10.10.10.58 Slave2

10.10.10.60 VIP

APP2:

10.10.10.61 Master

10.10.10.62 slave1

10.10.10.63 Slave2

10.10.10.64 VIP

1. Create a global profile masterha_default.cnf

Mkdir-p/etc/mhacp/usr/local/src/mha4mysql-manager-0.56/samples/conf/masterha_default.cnf/etc/mha/ln-s/etc/mha/ masterha_default.cnf/etc/masterha_default.cnf# writes the same configuration information to the global configuration file [[email protected] mha]# cat masterha_default.cnf [ Server default]master_binlog_dir=/data/mysqlpassword=123456ping_interval=1remote_workdir=/tmprepl_password= 123456repl_user=repreport_script=/usr/local/bin/send_reportssh_port=22ssh_user=rootuser=mha

Note: masterha_default.cnf must be in/etc, otherwise the inspection process will not find this file, in order to put all the MHA related configuration files together for easy management, I made a soft connection.
2. Create a configuration file for each app app*.conf

App1.conf

[Email protected] mha]# cat/etc/mha/app1.cnf [Server Default]manager_log=/var/log/masterha/app1/manager.logmanager _workdir=/var/log/masterha/app1master_ip_failover_script=/usr/local/bin/master_ip_failover_app1master_ip_ Online_change_script=/usr/local/bin/master_ip_online_change_app1[server1]hostname=10.10.10.56port=3306[server2 ]candidate_master=1check_repl_delay=0hostname=10.10.10.57port=3306[server3]hostname=10.10.10.58port=3306

App2.conf

[Email protected] mha]# cat/etc/mha/app2.cnf [Server Default]manager_log=/var/log/masterha/app2/manager.logmanager _workdir=/var/log/masterha/app2master_ip_failover_script=/usr/local/bin/master_ip_failover_app2master_ip_ Online_change_script=/usr/local/bin/master_ip_online_change_app2[server1]hostname=10.10.10.61port=3306[server2 ]candidate_master=1check_repl_delay=0hostname=10.10.10.62port=3306[server3]hostname=10.10.10.63port=3306

Note: The Master_ip_failover_script and Master_ip_online_change_script scripts for each app are different, as we use VIPs during the migration process to achieve high availability, master_ The ip_failover automatically shifts the VIP during the automatic failover process, while the master_ip_online_change shifts the VIP during the online migration process. Therefore, in multiple master-slave replication groups We use several different scripts to manage different IPs.

3. Check the SSH configuration

Masterha_check_ssh--conf=/etc/mha/app1.cnf

Masterha_check_ssh--conf=/etc/mha/app2.cnf

Note: (1) The global profile is automatically checked during the detection process, and if the global profile is not found, the specified app profile is read.

(2) Each master-slave replication group needs to configure SSH without password login with the MHA Manager node, but the group and group are not configured before.

4. Check the replication configuration

Masterha_check_repl--conf=/etc/mha/app1.cnf

Masterha_check_repl--conf=/etc/mha/app2.cnf

5. Start monitoring

Nohup Masterha_manager--conf=/etc/mha/app1.cnf--remove_dead_master_conf--ignore_last_failover </dev/null >/ Var/log/masterha/app1/manager.log 2>&1 &

Nohup Masterha_manager--conf=/etc/mha/app2.cnf--remove_dead_master_conf--ignore_last_failover </dev/null >/ Var/log/masterha/app1/manager.log 2>&1 &

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

MySQL High-availability MHA (Supplemental 3)-manages multiple sets of master-slave replication