Foreword introduction
I remember I posted an article before, called "Analysis of MySQL High Availability Architecture", after that, many friends have been asking me in the background of the official account or other channels when there are related in-depth configuration management articles. Therefore, Brother migrant workers, we will also sort out the various structures in front of them one by one, and then publish them. Then the overall planning and configuration operation of the MHA that will be released today and in the future.
Architecture Introduction
MHA (Master High Availability) is currently a relatively mature solution in MySQL high availability, as a high availability software for failover and master-slave promotion in MySQL high availability environment. In the process of MySQL failover, MHA can automatically complete the failover operation of the database within 0~30 seconds, and in the process of failover, MHA can ensure the consistency of data to the greatest extent, in order to achieve true High availability in a sense.
The software consists of two parts: MHA Manager (management node) and MHA Node (data node). MHA Manager can be deployed on an independent machine to manage multiple master-slave clusters, or it can be deployed on a slave node. MHA Node runs on each MySQL server, MHA Manager will periodically detect the master node in the cluster, when the master fails, it can automatically promote the latest data slave to the new master, and then re-point all other slaves to the new master the master. The entire failover process is completely transparent to the application.
At present, MHA mainly supports the architecture of one master and multiple slaves. To build MHA, there must be at least three database servers in a replication cluster, one master and two slaves, that is, one acts as the master, one acts as the standby master, and the other acts as the slave database. , since at least three servers are required
**Installation and deployment planning**
system message
[root@db250 ~]# cat /etc/redhat-release
CentOS release 6.8 (Final)
[root@db250 ~]# uname -r
2.6.32-642.el6.x86_64
Database version
mysql-5.7.17
environmental planning
Db250 cluster management node 192.168.4.250
Db251 main library 192.168.4.251
Db253 slave library (standby master library) 192.168.4.253
Db254 from library 192.168.4.254
The architecture diagram is as follows
Install and configure SSH password-free login and HOSTS fileConfigure
hosts file
cat>>/etc/hosts<
192.168.4.250 db250
192.168.4.251 db251
192.168.4.253 db253
192.168.4.254 db254
EOF
Check after configuration is complete
[root@db254 ~]# tail -4 /etc/hosts
192.168.4.250 db250
192.168.4.251 db251
192.168.4.253 db253
192.168.4.254 db254
Configure SSH keyless login
ssh-keygen -t rsa
ssh-copy-id 192.168.4.251
ssh-copy-id 192.168.4.253
ssh-copy-id 192.168.4.254
—— The above two steps to configure all servers need to be configured
Install MYSQL and configure master-slave synchronization to
install mysql database service
rpm -ivh mysql57-community-release-el6-9.noarch.rpm
yum install mysql-community-server -y
/etc/init.d/mysqld start
The default password is
[root@db254 ~]# grep ‘temporary password’ /var/log/mysqld.log
2017-08-30T08:08:05.956867Z 1 [Note] A temporary password is generated for root@localhost: f;2YK51qXlo/
Modify the default password, for the convenience of later operation
mysql> alter user ‘root’@‘localhost’ identified by ‘123456’;
——- All three database servers need to be configured for the above configuration
Configure master-slave synchronization
Both Db251 and db253 configuration files need to be configured to enable binlog
server_id=251
log_bin=master-bin
log_bin_index=master-bin.index
server_id=253
log_bin=slave-bin
log_bin_index=slave-bin.index
log-slave-updates
relay_log_index=slave-relay-bin.index
relay_log=slave-relay-bin
server_id=254
relay_log_index=slave-relay-bin.index
relay_log=slave-relay-bin
Synchronize the master database data to the slave database, please refer to the previous article for master-slave synchronization operation
Linux system MySQL database master-slave synchronization actual combat process
Check master-slave synchronization status
mysql -uroot -p123456 -e “show slave status\G”|egrep “Slave_IO_Running|Slave_SQL_Running”
Install and configure MHA management and node nodes
Install dependencies
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes –y
Manage Node Installation
rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum localinstall -y mha4mysql-manager-0.52-0.noarch.rpm
yum localinstall -y mha4mysql-node-0.52-0.noarch.rpm
Installation of other nodes
yum localinstall -y mha4mysql-node-0.52-0.noarch.rpm
Errors may be reported during the installation process, follow the prompts to solve
The configuration process is as follows:
[root@db250 ~]# mkdir /mha
[root@db250 ~]# vim /etc/masterha_default.cnf
[server default]
#The mysql management username just authorized
user=mha
password=123456
manager_workdir=/mha
manager_log=/mha/manager.log
remote_workdir=/mha
#ssh Account name for keyless login
ssh_user=root
#mysql replication account, used to synchronize binary logs between master and slave machines, etc.
repl_user=slave
repl_password=123456
#ping interval, used to detect whether the master is normal
ping_interval= 1
[server1]
hostname=db251
master_binlog_dir=/var/lib/mysql
#When the candidate master hangs up, let it be the top priority
candidate_master=1
[server2]
hostname=db253
master_binlog_dir=/var/lib/mysql/
candidate_master=1
[server3]
hostname=db254
master_binlog_dir=/var/lib/mysql/
no_master=1
#Cannot become master
——The relevant detection commands are as follows————
masterha_check_ssh Check the SSH configuration status of MHA
masterha_check_repl checks MySQL replication status
masterha_manger starts MHA
masterha_check_status checks the current MHA running status
masterha_master_monitor detects whether the master is down
masterha_master_switch controls failover (automatic or manual)
masterha_conf_host Add or delete configured server information
Detect SSH password-free login
detection synchronization
Start the MHA service and observe the log information
[root@db250 ~]# masterha_manager –conf=/etc/masterha_default.cnf &
[1] 2035Fri Sep 1 01:52:25 2017 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Fri Sep 1 01:52:25 2017 - [info] Reading application default configurations from /etc/masterha_default.cnf..
Fri Sep 1 01:52:25 2017 - [info] Reading server configurations from /etc/masterha_default.cnf..
Test automatic failover
Next simulate the failure and turn off db251
[root@db251 ~]# /etc/init.d/mysqld stop
Stopping mysqld: [OK]
Check the log 
and find that the new master library has been switched to the db253 server. Next, check the master-slave synchronization.
When the original master server is faulty and repaired, you need to manually change the original master to the slave
[root@db250 ~]# grep -i"All other slaves should start" /mha/manager.log
Fri Sep 1 01:59:05 2017 - [info] All other replicas should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='db253 or192.168.4.253', MASTER_PORT=3306,MASTER_LOG_FILE='slave-bin. 000003', MASTER_LOG_POS=760546, MASTER_USER='slave', MASTER_PASSWORD='xxx'; 
Check the log 
and find that the original master library has become a new slave library after being repaired and online, and then synchronize with DB253 to 
find that the data is normal and can be synchronized
From the technical public account: Migrant workers Linux operation and maintenance