Shulou(Shulou.com)05/31 Report--

Editor to share with you how to build HA MHA in MySQL, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Mha structure recovery process:

Mha architecture diagram:

The test environment is 3 servers.

In which a slave is used as a manager node in mha

-

Ip hostname mysql

-

10.1.10.244 data01 master

10.1.10.80 data02 slave

10.1.10.91 manager slave

-

Host condition:

Server distribution: centos6.7

Kernel: 2.6.32-220.el6.x86_64

Database software version: MySQL Community 5.6.29

-- modify the hostname--

Undefined

24 (master):

# vi / etc/sysconfig/network

Change HOSTNAME to data01

80 (slave):

# vi / etc/sysconfig/network

Change HOSTNAME to data02

91 (slave):

# vi / etc/sysconfig/network

Change HOSTNAME to manager

Modify the three servers hosts at the same time:

# vi / etc/hosts

Add:

10.1.10.244 data01

10.1.10.80 data02

10.1.10.91 manager

-- establish a relationship of mutual trust.

Execute on each of the three servers:

24 (master), 80 (slave), 91 (slave):

# cd / root/.ssh

# ssh-keygen-t rsa

All defaults, enter directly

Execute on 224 (master):

# cd / root/.ssh

# cat id_dsa.pub > > authorized_keys

# scp root@10.1.10.80:/root/.ssh/id_dsa.pub. / id_dsa.pub.data02.80

# scp root@10.1.10.91:/root/.ssh/id_dsa.pub. / id_dsa.pub.manager.91

# cat id_dsa.pub.data02.80 > > authorized_keys

# cat id_dsa.pub.manager.91 > > authorized_keys

# scp authorized_keys root@10.1.10.80:/root/.ssh/authorized_keys

# scp authorized_keys root@10.1.10.91:/root/.ssh/authorized_keys

Start with 244 (master) for pairwise verification:

[root@data01 ~] # ssh data02

…… Slightly.

[root@data02 ~] # ssh manager

…… Slightly.

[root@manager ~] # ssh data01

…… Slightly.

[root@data01 ~] # ssh manager

…… Slightly.

[root@manager ~] # ssh data02

…… Slightly.

[root@data02 ~] # ssh data01

…… Slightly.

-- establish a master-slave relationship.

Execute on the mysql-server on the three servers:

24 (master), 80 (slave), 91 (slave):

Mysql > GRANT super, replication slave, reload ON *. * TO repl_user@'10.1.10.%' IDENTIFIED BY 'repl_user'

Query OK, 0 rows affected (0.00 sec)

Mysql > FLUSH PRIVILEGES

Query OK, 0 rows affected (0.00 sec)

Modify the configuration files of mysql on the three servers:

24 (master):

[mysqld]

Log-bin = / var/lib/mysql/data01-bin

Log-bin-index = / var/lib/mysql/data01-bin.index

Server-id = 244

Relay-log = / var/lib/mysql/data01-relay-bin

Relay-log-index = / var/lib/mysql/data01-relay-bin.index

Log-slave-updates

80 (slave):

[mysqld]

Log-bin = / var/lib/mysql/data02-bin

Log-bin-index = / var/lib/mysql/data02-bin.index

Server-id = 80

Relay-log = / var/lib/mysql/data02-relay-bin

Relay-log-index = / var/lib/mysql/data02-relay-bin.index

Log-slave-updates

91 (slave):

[mysqld]

Log-bin = / var/lib/mysql/manager-bin

Log-bin-index = / var/lib/mysql/manager-bin.index

Server-id = 91

Relay-log = / var/lib/mysql/manager-relay-bin

Relay-log-index = / var/lib/mysql/manager-relay-bin.index

Log-slave-updates

Execute on both slave:

80 (slave), 91 (slave):

Mysql > CHANGE MASTER TO

-> MASTER_HOST = '10.1.10.244'

-> MASTER_PORT = 3306

-> MASTER_USER = 'repl_user'

-> MASTER_PASSWORD = 'repl_user'

Query OK, 0 rows affected, 2 warnings (0.03 sec)

Mysql > START SLAVE

Query OK, 0 rows affected (0.00 sec)

After execution, you can check to see if there is something wrong with the replication process:

Mysql > SHOW SLAVE STATUS\ G

If the IO and SQL threads are shown to be Yes, the replication is established:

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

You can also see it through SHOW PROCESSLIST.

-install mha-manager and mha-node--

Attachments that will be used soon:

Mha4mysql-node-0.56.tar.gz

Mha4mysql-manager-0.56.tar.gz

You can search these two tar bags.

Execute on each of the three servers:

24 (data01), 80 (data02), 91 (manager):

# yum install-y perl-DBD-MySQL

Continue to install mha-node tools on each of the three servers:

Mha-node installation:

# tar zxvf mha4mysql-node-0.56.tar.gz

# cd mha4mysql-node-0.56

# perl Makefile.PL

# make & & make install

Install the mha-manager tools on the management server:

91 (manager):

First install some dependent tools or perl modules on the manager server:

# yum install-y perl-Config-Tiny

The following three may not fit:

# yum install-y perl-Log-Dispatch

# yum install-y perl-Parallel-ForkManager

# yum install-y perl-Config-IniFiles

You can install it through perl CPAN, if not, install CPAN through yum first:

# yum install-y perl-CPAN

Go to CPAN to install the perl module:

# perl-MCPAN-e shell

Cpan [1] > install Log::Dispatch

Cpan [1] > install Parallel::ForkManager

Cpan [1] > install Config::IniFiles

If the installation fails, you can install some dependent modules according to the prompt, which can be summarized as follows (in CPAN):

Install Test::Requires

Install Module::Runtime

Install Dist::CheckConflicts

Install Params::Validate

Install Module::Runtime

Install Module::Implementation

Install ExtUtils::MakeMaker

Mha-manger installation:

# tar zxvf mha4mysql-manager-0.56.tar.gz

# cd mha4mysql-manager-0.56

# perl Makefile.PL

By checking the Makefile.PL, you can see whether the previous module was successfully installed.

The results of the inspection are as follows:

.

[Core Features]

-DBI... loaded. (1.609)

-DBD::mysql... loaded. (4.013)

-Time::HiRes... loaded. (1.9728)

-Config::Tiny... loaded. (2.12)

-Log::Dispatch... loaded. (2.54)

-Parallel::ForkManager... loaded. (1.17)

-MHA::NodeConst... loaded. (0.56)

.

If missing, it is missing.

If both ok, compile:

# make & & make install

-- add mha profile--

Configure on the management server:

91 (manager):

# mkdir / var/log/mha

# vi / etc/mha-manger.cnf

There is only one node in this experiment. If there are multiple nodes, you can change the configuration file structure of the manager server:

Touch / etc/masterha_default.cnf write [server default]

Touch / etc/node1.cnf writes server information on this node, such as [server_1], [server_2], etc.

Use-- global_conf=/etc/masterha_default.cnf-- conf=/etc/node1.cnf respectively

-profile-

[server default]

Manager_workdir = / var/log/mha/

Manager_log = / var/log/mha/manager.log

Ssh_user = root

Repl_user = repl_user

Repl_password = repl_user

[server_1]

Hostname = 10.1.10.244

User = root

Password = root

Candidate_master = 1

Master_binlog_dir = / var/lib/mysql

[server_2]

Hostname = 10.1.10.80

User = root

Password = root

# candidate_master = 1

Master_binlog_dir = / var/lib/mysql

[server_3]

Hostname = 10.1.10.91

User = root

Password = root

# candidate_master = 1

Master_binlog_dir = / var/lib/mysql

Other parameters are defaulted here, and more parameters can be found in the reference documentation at the end of this article.

-profile-

Undefined

# masterha_check_ssh-conf=/etc/mha-manager.cnf

[warning] Global configuration file / etc/masterha_default.cnf not found. Skipping.

-[info] Reading application default configuration from / etc/mha-manager.cnf..

-[info] Reading server configuration from / etc/mha-manager.cnf..

-[info] Starting SSH connection tests..

-[debug]

-[debug] Connecting via SSH from root@10.1.10.244 (10.1.10.244) to root@10.1.10.80 (10.1.10.80).

[debug] ok.

-[debug] Connecting via SSH from root@10.1.10.244 (10.1.10.244) to root@10.1.10.91 (10.1.10.91).

[debug] ok.

-[debug]

-[debug] Connecting via SSH from root@10.1.10.80 (10.1.10.80) to root@10.1.10.244 (10.1.10.244).

[debug] ok.

-[debug] Connecting via SSH from root@10.1.10.80 (10.1.10.80) to root@10.1.10.91 (10.1.10.91).

[debug] ok.

-[debug]

-[debug] Connecting via SSH from root@10.1.10.91 (10.1.10.91) to root@10.1.10.244 (10.1.10.244).

Warning: Permanently added '10.1.10.91' (RSA) to the list of known hosts.

[debug] ok.

-[debug] Connecting via SSH from root@10.1.10.91 (10.1.10.91) to root@10.1.10.80 (10.1.10.80).

[debug] ok.

[info] All SSH connection tests passed successfully.

Continue to check if replication is successful:

# masterha_check_repl-conf=/etc/mha-manager.cnf

If you see [MySQL Replication Health is OK.], the connection is successful.

If it fails, it can be checked from the firewall, the corresponding mysql server user rights, and the corresponding operating system users' read and write permissions to the file.

-- manage manager--

Continue to start on the management server:

91 (manager):

Start manager:

# nohup masterha_manager-- conf=/etc/mha-manager.cnf / var/log/mha/manager.log 2 > & 1 &

Check the process:

# ps-ef | grep manager

Root 18210 10044 0 18:11 pts/1 00:00:00 perl / usr/local/bin/masterha_manager-- conf=/etc/mha-manager.cnf / var/log/mha/manager.log

You can take a look at the final log:

# tail-20 / var/log/mha/manager.log

...

Thu Feb 18 18:11:37 2016-[info] Ping (SELECT) succeeded, waiting until MySQL doesn't respond..

Continue to check the master status:

# masterha_check_status-conf=/etc/mha-manager.cnf

Mha-manager (pid:18210) is running (0:PING_OK), master:10.1.10.244

Turn off manager:

# masterha_stop-conf=/etc/mha-manager.cnf

Stopped mha-manager successfully.

-- failover detection

The entire server downtime is simulated here.

Action: restart the master server directly (in this case, data01)

Check the mha-manager.log log through tail-f and brush it out as follows:

Thu Feb 18 18:23:37 2016-[warning] Got error on MySQL select ping: 2006 (MySQL server has gone away)

Thu Feb 18 18:23:37 2016-[info] Executing SSH check script: save_binary_logs-command=test-start_pos=4-binlog_dir=/var/lib/mysql-output_file=/var/tmp/save_binary_logs_test-manager_version=0.56-binlog_prefix=data01-bin

Thu Feb 18 18:23:37 2016-[warning] HealthCheck: SSH to 10.1.10.244 is NOT reachable.

Thu Feb 18 18:23:43 2016-[warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.1.10.244' (4))

Thu Feb 18 18:23:43 2016-[warning] Connection failed 2 time (s)..

Thu Feb 18 18:23:46 2016-[warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.1.10.244' (4))

Thu Feb 18 18:23:46 2016-[warning] Connection failed 3 time (s)..

Thu Feb 18 18:23:49 2016-[warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.1.10.244' (4))

Thu Feb 18 18:23:49 2016-[warning] Connection failed 4 time (s)..

Thu Feb 18 18:23:49 2016-[warning] Master is not reachable from health checker!

Thu Feb 18 18:23:49 2016-[warning] Master 10.1.10.244 (10.1.10.244 Master 3306) is not reachable!

Thu Feb 18 18:23:49 2016-[warning] SSH is NOT reachable.

Thu Feb 18 18:23:49 2016-[info] Connecting to a master server failed. Reading configuration file / etc/masterha_default.cnf and / etc/mha-manager.cnf again, and trying to connect to all servers to check server status..

Thu Feb 18 18:23:49 2016-[warning] Global configuration file / etc/masterha_default.cnf not found. Skipping.

Thu Feb 18 18:23:49 2016-[info] Reading application default configuration from / etc/mha-manager.cnf..

Thu Feb 18 18:23:49 2016-[info] Reading server configuration from / etc/mha-manager.cnf..

Thu Feb 18 18:23:50 2016-[info] GTID failover mode = 0

Thu Feb 18 18:23:50 2016-[info] Dead Servers:

Thu Feb 18 18:23:50 2016-[info] 10.1.10.244 (10.1.10.244 3306)

Thu Feb 18 18:23:50 2016-[info] Alive Servers:

Thu Feb 18 18:23:50 2016-[info] 10.1.10.80 (10.1.10.80 purl 3306)

Thu Feb 18 18:23:50 2016-[info] 10.1.10.91 (10.1.10.91 purl 3306)

Thu Feb 18 18:23:50 2016-[info] Alive Slaves:

Thu Feb 18 18:23:50 2016-[info] 10.1.10.80 (10.1.10.80 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:50 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:50 2016-[info] 10.1.10.91 (10.1.10.91 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:50 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:50 2016-[info] Checking slave configurations..

Thu Feb 18 18:23:50 2016-[info] read_only=1 is not set on slave 10.1.10.80 (10.1.10.80 read_only=1 is not set on slave 3306).

Thu Feb 18 18:23:50 2016-[warning] relay_log_purge=0 is not set on slave 10.1.10.80 (10.1.10.80 relay_log_purge=0 is not set on slave 3306).

Thu Feb 18 18:23:50 2016-[info] read_only=1 is not set on slave 10.1.10.91 (10.1.10.91 read_only=1 is not set on slave 3306).

Thu Feb 18 18:23:50 2016-[warning] relay_log_purge=0 is not set on slave 10.1.10.91 (10.1.10.91 relay_log_purge=0 is not set on slave 3306).

Thu Feb 18 18:23:50 2016-[info] Checking replication filtering settings..

Thu Feb 18 18:23:50 2016-[info] Replication filtering check ok.

Thu Feb 18 18:23:50 2016-[info] Master is down!

Thu Feb 18 18:23:50 2016-[info] Terminating monitoring script.

Thu Feb 18 18:23:50 2016-[info] Got exit code 20 (Master dead).

Thu Feb 18 18:23:50 2016-[info] MHA::MasterFailover version 0.56.

Thu Feb 18 18:23:50 2016-[info] Starting master failover.

Thu Feb 18 18:23:50 2016-[info]

Thu Feb 18 18:23:50 2016-[info] * Phase 1: Configuration Check Phase..

Thu Feb 18 18:23:50 2016-[info]

Thu Feb 18 18:23:51 2016-[info] GTID failover mode = 0

Thu Feb 18 18:23:51 2016-[info] Dead Servers:

Thu Feb 18 18:23:51 2016-[info] 10.1.10.244 (10.1.10.244 3306)

Thu Feb 18 18:23:51 2016-[info] Checking master reachability via MySQL (double check).

Thu Feb 18 18:23:52 2016-[info] ok.

Thu Feb 18 18:23:52 2016-[info] Alive Servers:

Thu Feb 18 18:23:52 2016-[info] 10.1.10.80 (10.1.10.80 purl 3306)

Thu Feb 18 18:23:52 2016-[info] 10.1.10.91 (10.1.10.91 purl 3306)

Thu Feb 18 18:23:52 2016-[info] Alive Slaves:

Thu Feb 18 18:23:52 2016-[info] 10.1.10.80 (10.1.10.80 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:52 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:52 2016-[info] 10.1.10.91 (10.1.10.91 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:52 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:52 2016-[info] Starting Non-GTID based failover.

Thu Feb 18 18:23:52 2016-[info]

Thu Feb 18 18:23:52 2016-[info] * * Phase 1: Configuration Check Phase completed.

Thu Feb 18 18:23:52 2016-[info]

Thu Feb 18 18:23:52 2016-[info] * Phase 2: Dead Master Shutdown Phase..

Thu Feb 18 18:23:52 2016-[info]

Thu Feb 18 18:23:52 2016-[info] Forcing shutdown so that applications never connect to the current master..

Thu Feb 18 18:23:52 2016-[warning] master_ip_failover_script is not set. Skipping invalidating dead master IP address.

Thu Feb 18 18:23:52 2016-[warning] shutdown_script is not set. Skipping explicit shutting down of the dead master.

Thu Feb 18 18:23:53 2016-[info] * Phase 2: Dead Master Shutdown Phase completed.

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 3: Master Recovery Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 3.1: Getting Latest Slaves Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] The latest binary log file/position on all slaves is data01-bin.000016:120

Thu Feb 18 18:23:53 2016-[info] Latest slaves (Slaves that received relay log files to the latest):

Thu Feb 18 18:23:53 2016-[info] 10.1.10.80 (10.1.10.80 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:53 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:53 2016-[info] 10.1.10.91 (10.1.10.91 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:53 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:53 2016-[info] The oldest binary log file/position on all slaves is data01-bin.000016:120

Thu Feb 18 18:23:53 2016-[info] Oldest slaves:

Thu Feb 18 18:23:53 2016-[info] 10.1.10.80 (10.1.10.80 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:53 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:53 2016-[info] 10.1.10.91 (10.1.10.91 Version=5.6.29-log) Version=5.6.29-log (oldest major version between slaves) log-bin:enabled

Thu Feb 18 18:23:53 2016-[info] Replicating from 10.1.10.244 (10.1.10.244 Replicating from 3306)

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 3.2: Saving Dead Master's Binlog Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[warning] Dead Master is not SSH reachable. Could not save it's binlogs. Transactions that were not sent to the latest slave (Read_Master_Log_Pos to the tail of the dead master's binlog) were lost.

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 3.3: Determining New Master Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] Finding the latest slave that has all relay logs for recovering other slaves..

Thu Feb 18 18:23:53 2016-[info] All slaves received relay logs to the same position. No need to resync each other.

Thu Feb 18 18:23:53 2016-[info] Searching new master from slaves..

Thu Feb 18 18:23:53 2016-[info] Candidate masters from the configuration file:

Thu Feb 18 18:23:53 2016-[info] Non-candidate masters:

Thu Feb 18 18:23:53 2016-[info] New master is 10.1.10.80 (10.1.10.80 New master is 3306)

Thu Feb 18 18:23:53 2016-[info] Starting master failover..

Thu Feb 18 18:23:53 2016-[info]

From:

10.1.10.244 (10.1.10.244 virtual 3306) (current master)

+-10.1.10.80 (10.1.10.80 purl 3306)

+-10.1.10.91 (10.1.10.91 purl 3306)

To:

10.1.10.80 (10.1.10.80 3306) (new master)

+-10.1.10.91 (10.1.10.91 purl 3306)

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 3.3: New Master Diff Log Generation Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] This server has all relay logs. No need to generate diff files from the latest slave.

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 3.4: Master Log Apply Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * NOTICE: If any error happens from this phase, manual recovery is needed.

Thu Feb 18 18:23:53 2016-[info] Starting recovery on 10.1.10.80 (10.1.10.80 Starting recovery on 3306).

Thu Feb 18 18:23:53 2016-[info] This server has all relay logs. Waiting all logs to be applied..

Thu Feb 18 18:23:53 2016-[info] done.

Thu Feb 18 18:23:53 2016-[info] All relay logs were successfully applied.

Thu Feb 18 18:23:53 2016-[info] Getting new master's binlog name and position..

Thu Feb 18 18:23:53 2016-[info] data02-bin.000003:684

Thu Feb 18 18:23:53 2016-[info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.1.10.80', MASTER_PORT=3306, MASTER_LOG_FILE='data02-bin.000003', MASTER_LOG_POS=684, MASTER_USER='repl_user', MASTER_PASSWORD='xxx'

Thu Feb 18 18:23:53 2016-[warning] master_ip_failover_script is not set. Skipping taking over new master IP address.

Thu Feb 18 18:23:53 2016-[info] * * Finished master recovery successfully.

Thu Feb 18 18:23:53 2016-[info] * Phase 3: Master Recovery Phase completed.

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 4: Slaves Recovery Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..

Thu Feb 18 18:23:53 2016-[info]

Thu Feb 18 18:23:53 2016-[info]-- Slave diff file generation on host 10.1.10.91 (10.1.10.91 started) started, pid: 18577. Check tmp log/ var/log/mha//10.1.10.91_3306_20160218182350.log if it takes time..

Thu Feb 18 18:23:54 2016-[info]

Thu Feb 18 18:23:54 2016-[info] Log messages from 10.1.10.91...

Thu Feb 18 18:23:54 2016-[info]

Thu Feb 18 18:23:53 2016-[info] This server has all relay logs. No need to generate diff files from the latest slave.

Thu Feb 18 18:23:54 2016-[info] End of log messages from 10.1.10.91.

Thu Feb 18 18:23:54 2016-[info]-- 10.1.10.91 (10.1.10.91) has the latest relay log events.

Thu Feb 18 18:23:54 2016-[info] Generating relay diff files from the latest slave succeeded.

Thu Feb 18 18:23:54 2016-[info]

Thu Feb 18 18:23:54 2016-[info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..

Thu Feb 18 18:23:54 2016-[info]

Thu Feb 18 18:23:54 2016-[info]-- Slave recovery on host 10.1.10.91 (10.1.10.91 started) started, pid: 18579. Check tmp log/ var/log/mha//10.1.10.91_3306_20160218182350.log if it takes time..

Thu Feb 18 18:23:55 2016-[info]

Thu Feb 18 18:23:55 2016-[info] Log messages from 10.1.10.91...

Thu Feb 18 18:23:55 2016-[info]

Thu Feb 18 18:23:54 2016-[info] Starting recovery on 10.1.10.91 (10.1.10.91 Starting recovery on 3306).

Thu Feb 18 18:23:54 2016-[info] This server has all relay logs. Waiting all logs to be applied..

Thu Feb 18 18:23:54 2016-[info] done.

Thu Feb 18 18:23:54 2016-[info] All relay logs were successfully applied.

Thu Feb 18 18:23:54 2016-[info] Resetting slave 10.1.10.91 (10.1.10.91) and starting replication from the new master 10.1.10.80 (10.1.10.80).

Thu Feb 18 18:23:54 2016-[info] Executed CHANGE MASTER.

Thu Feb 18 18:23:54 2016-[info] Slave started.

Thu Feb 18 18:23:55 2016-[info] End of log messages from 10.1.10.91.

Thu Feb 18 18:23:55 2016-[info]-- Slave recovery on host 10.1.10.91 (10.1.10.91) succeeded.

Thu Feb 18 18:23:55 2016-[info] All new slave servers recovered successfully.

Thu Feb 18 18:23:55 2016-[info]

Thu Feb 18 18:23:55 2016-[info] * Phase 5: New master cleanup phase..

Thu Feb 18 18:23:55 2016-[info]

Thu Feb 18 18:23:55 2016-[info] Resetting slave info on the new master..

Thu Feb 18 18:23:55 2016-[info] 10.1.10.80: Resetting slave info succeeded.

Thu Feb 18 18:23:55 2016-[info] Master failover to 10.1.10.80 (10.1.10.80 completed successfully 3306).

Thu Feb 18 18:23:55 2016-[info]

-Failover Report-

Mha-manager: MySQL Master failover 10.1.10.244 (10.1.10.244 to 3306) to 10.1.10.80 (10.1.10.80 to 3306) succeeded

Master 10.1.10.244 (10.1.10.244 3306) is down!

Check MHA Manager logs at manager:/var/log/mha/manager.log for details.

Started automated (non-interactive) failover.

The latest slave 10.1.10.80 (10.1.10.80) has all relay logs for recovery.

Selected 10.1.10.80 (10.1.10.80) as a new master.

10.1.10.80 (10.1.10.80): OK: Applying all logs succeeded.

10.1.10.91 (10.1.10.91): This host has the latest relay log events.

Generating relay diff files from the latest slave succeeded.

10.1.10.91 (10.1.10.91): OK: Applying all logs succeeded. Slave started, replicating from 10.1.10.80 (10.1.10.80 3306)

10.1.10.80 (10.1.10.80): Resetting slave info succeeded.

Master failover to 10.1.10.80 (10.1.10.80) completed successfully.

Simulation end

The test is not too much, so far we know a pit:

Mha recommends that relay_log_purge be turned off to ensure that there are enough relay logs to recover other slave libraries, that is, relay_log_purge=0 is required, so that relay-log cannot clean up periodically.

You may need to manually add scheduled tasks to clean up, which can be done as follows:

. / purge_relay_logs-- user=$user-- password=$password-disable_relay_log_purge > >. / log/purge_relay_logs.log 2 > & 1

Of course, we also need to cooperate with vip nodes to ensure the transparency of the application and achieve failover.

The above is all the content of the article "how to build HA MHA in MySQL". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.