Mysql cluster MHA high availability configuration

Table of contents

1. Overview of MHA

1 Introduction

2. Composition of MHA

(1) MHA Node (data node)

(2) MHA Manager (management node)

3. The characteristics of MHA

2. Build an MHA high-availability database cluster

1. Master-slave replication

(1) Four hosts do time synchronization

(2) Add log configuration to the master-slave database

(3) Make a soft connection to prepare for the subsequent master-standby switchover

(4) User authorization

(5) Master-slave replication configuration

(6) Test master-slave synchronization

2. MHA configuration

(1) Install dependent packages and software

(2) Configure password-free login to each database

(3) Modify the failover management script

(4) Create the MHA software directory and copy the configuration file, here use the app1.cnf configuration file to manage the mysql node server

3. Fault simulation

4. Restoration of faulty database


1. Overview of MHA

1 Introduction

        MHA (Master High Availability) is an excellent set of software for failover and master-slave replication in a MySQL high availability environment.

        The emergence of MHA is to solve the problem of MySQL single point of failure.

        During the MySQL failover process, MHA can automatically complete the failover operation within 0-30 seconds.

        MHA can ensure data consistency to the greatest extent during the failover process to achieve high availability in the true sense.

2. Composition of MHA

(1) MHA Node (data node)

        MHA Node runs on each MySQL server.

(2) MHA Manager (management node)

        MHA Manager can be deployed on an independent machine to manage multiple master-slave clusters; it can also be deployed on a slave node.

        MHA Manager will regularly detect the master node in the cluster. When the master fails, it can automatically promote the slave with the latest data as the new master, and then re-point all other slaves to the new master. The entire failover process is completely transparent to the application.

3. The characteristics of MHA

  • During the automatic failover process, MHA tries to save the binary log from the downtime master server to ensure that the data is not lost to the greatest extent;
  • Using semi-synchronous replication can greatly reduce the risk of data loss. If only one slave has received the latest binary log, MHA can apply the latest binary log to all other slave servers, thus ensuring data consistency of all nodes ;
  • At present, MHA supports a multi-slave architecture with at least three servers, that is, one master and two slaves.

2. Build an MHA high-availability database cluster

Experiment preparation (MHA manages a master-multiple-slave architecture, it is necessary to turn off the firewall and selinux, and install mysql in the database)

MHA server: 192.168.116.30

Master database: 192.168.116.50

Slave1 database: 192.168.116.20

Slave2 database: 192.168.116.40

1. Master-slave replication

 For details, please refer to Mysql master-slave replication and read-write separation_Evens7xxX's Blog-CSDN Blog

(1) Four hosts do time synchronization

#同步在线源阿里云的时间
ntpdate ntp.aliyun.com

(2) Add log configuration to the master-slave database

vim /etc/my.cnf

#在[mysqld]下修改和添加的内容

#id项每台数据库不可一致!
server-id = 1

#二进制日志
log-bin=mysql-bin
binlog_format=MIXED
log-slave-updates=true
expire_logs_days=10
max_binlog_size=500M

#中继日志
relay-log=relay-log-bin
relay-log-index=slave-relay-bin.index

#修改完后重启服务
systemctl restart mysqld.service

(3) Make a soft connection to prepare for the subsequent master-standby switchover

ln -s /usr/local/mysql/bin/mysql /usr/sbin/
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

(4) User authorization

--登入3台数据库,执行以下授权操作--
                                          --架构环境所在网段--
grant replication slave on *.* to 'myslave'@'192.168.116.%' identified by '123123';

grant all on *.* to 'mha'@'192.168.116.%' identified by '123123';

                        --三台数据库主机名--
grant all on *.* to 'mha'@'slave1' identified by '123123';
grant all on *.* to 'mha'@'slave2' identified by '123123';
grant all on *.* to 'mha'@'master' identified by '123123';

(5) Master-slave replication configuration

Check the status of the master node first, and obtain log files and location point information

Execute on two slave nodes

--指定master信息--
change master to master_host='192.168.116.50',master_user='myslave',
master_password='123123',master_log_file='mysql-bin.000008',master_log_pos=2672;

--开启从节点--
start slave;

--查看从节点状态--
show slave status\G

Set the two slave libraries as read-only 

(6) Test master-slave synchronization

The master node builds the database and builds the table to see if the slave node also has it, and if it has it, it is synchronized

2. MHA configuration

(1) Install dependent packages and software

All server installation depends on the environment

yum install epel-release --nogpgcheck -y

yum install -y perl-DBD-MySQL \
perl-Config-Tiny \
perl-Log-Dispatch \
perl-Parallel-ForkManager \
perl-ExtUtils-CBuilder \
perl-ExtUtils-MakeMaker \
perl-CPAN

Install the MHA-node component on all servers (CentOS7.4 needs to select version 0.57)

#先把0.57版本的安装包放到/opt下
cd /opt
tar zxvf mha4mysql-node-0.57.tar.gz

#编译安装
cd mha4mysql-node-0.57
perl Makefile.PL && make && make install

The MHA server also needs to install the MHA-manager component

#先把0.57版本的manager安装包放到/opt下
cd /opt
tar zxvf mha4mysql-manager-0.57.tar.gz
cd mha4mysql-manager-0.57
perl Makefile.PL && make && make install

After the manager component is installed, several tools will be generated under /usr/local/bin, mainly including the following:
masterha_check_ssh #Check the SSH configuration status of MHA
masterha_check_repl #Check the MySQL replication status
masterha_manger #Start the manager script
masterha_check_status #Check the current MHA running Status
masterha_master_monitor #Detect whether the master is down
masterha_master_switch #Control failover (automatic or manual)
masterha_conf_host #Add or delete configured server information
masterha_stop #Close manager

After the node component is installed, several scripts will be generated under /usr/local/bin (these tools are usually triggered by MHAManager scripts without manual operation), mainly as follows: save_binary_logs #Save and copy the binary log of the master apply_diff_relay_logs #Identify
the
difference Relay log events and apply their differential events to other slaves
filter_mysqlbinlog #Remove unnecessary ROLLBACK events (MHA no longer uses this tool)
purge_relay_logs #Clear relay logs (does not block SQL threads)

(2) Configure password-free login to each database

ssh-keygen -t rsa

#每台主机要依次配置其他数据库主机的ip(MHA服务器需要配置所有数据库主机的ip)
ssh-copy-id 192.168.116.20
ssh-copy-id 192.168.116.40
...

(3) Modify the failover management script

#将软件包中的脚本目录复制到/usr/local/bin/
cp -p /opt/mha4mysql-manager-0.57/samples/scripts/* /usr/local/bin/

master_ip_failover #Script of vip management during automatic switching
master_ip_online_change #Management of vip during online switching
power_manager #Script to shut down the host after failure occurs
send_report #Script to send alarm after failover 

#修改故障切换脚本
vim master_ip_failover
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';

use Getopt::Long;

my (
$command, $ssh_user, $orig_master_host, $orig_master_ip,
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port
);

my $vip = '192.168.116.200';
my $brdc = '192.168.116.255';
my $ifdev = 'ens33';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";
my $exit_code = 0;

GetOptions(
'command=s' => \$command,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,
'orig_master_port=i' => \$orig_master_port,
'new_master_host=s' => \$new_master_host,
'new_master_ip=s' => \$new_master_ip,
'new_master_port=i' => \$new_master_port,
);

exit &main();

sub main {

print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";

if ( $command eq "stop" || $command eq "stopssh" ) {

my $exit_code = 1;
eval {
print "Disabling the VIP on old master: $orig_master_host \n";
&stop_vip();
$exit_code = 0;
};
if ($@) {
warn "Got Error: $@\n";
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "start" ) {

my $exit_code = 10;
eval {
print "Enabling the VIP - $vip on the new master - $new_master_host \n";
&start_vip();
$exit_code = 0;
};
if ($@) {
warn $@;
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "status" ) {
print "Checking the Status of the script.. OK \n";
exit 0;
}
else {
&usage();
exit 1;
}
}
sub start_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
## A simple system call that disable the VIP on the old_master
sub stop_vip() {
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

sub usage {
print
"Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

(4) Create the MHA software directory and copy the configuration file, here use the app1.cnf configuration file to manage the mysql node server

[server default]
manager_log=/var/log/masterha/app1/manager.log #manager log
manager_workdir=/var/log/masterha/app1 #manager working directory
master_binlog_dir=/usr/local/mysql/data/ #master save binlog location, the path here must be consistent with the binlog path configured in the master, so that MHA can find
master_ip_failover_script=/usr/local/bin/master_ip_failover #Setting the switching script when automatic failover is set, which is the script above
master_ip_online_change_script=/usr /local/bin/master_ip_online_change #Set the switching script for manual switching
user=mha #Set the mysql user
password=123123 #Set the password of the mysql user, which is the password for the monitoring user created in the previous article
ping_interval=1 #Set the monitoring master library , the time interval for sending ping packets, the default is 3 seconds, and failover will be automatically performed when there is no response after three attempts
remote_workdir=/tmp #Set the storage location of the binlog when the remote mysql switches

repl_user=myslave #Set the user of the replicated user

repl_password=123123 #Set the password of the copy user
report_script=/usr/local/bin/send_report #Set the script of the alarm sent after the switch occurs
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.116.20 -s 192.168.116.40 # Specify the IP address of the slave server to be checked
#shutdown_script=/usr/local/bin/power_manager #Set the script to close the faulty host after the failure occurs (the main function of this script is to shut down the host to prevent split-brain, which is not used here) ssh_user=root
#Setting ssh login username

[server1]
hostname=192.168.116.50
port=3306

[server2]
hostname=192.168.116.20
port=3306

[server3]
hostname=192.168.116.40
port=3306
#candidate_master=1
#Set as the candidate master. After setting this parameter, after the master-slave switch occurs, the slave library will be promoted to the master library, even if the slave library is not the latest in the cluster the slave

#check_repl_delay=0
#By default, if a slave lags behind the master by more than 100M relay logs, MHA will not select the slave as a new master, because it takes a long time to restore the slave; by setting check_repl_delay=0 , MHA triggers switching and will ignore the replication delay when selecting a new master. This parameter is very useful for hosts with candidate_master=1, because the candidate master must be the new master during the switching process

mkdir /etc/masterha
cp /opt/mha4mysql-manager-0.57/samples/conf/app1.cnf /etc/masterha
#修改
vim app1.cnf

[server default]
manager_log=/var/log/masterha/app1/manager.log 
manager_workdir=/var/log/masterha/app1  
master_binlog_dir=/usr/local/mysql/data    
master_ip_failover_script=/usr/local/bin/master_ip_failover 
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
user=mha
password=123123
ping_interval=1
remote_workdir=/tmp
repl_user=myslave
repl_password=123123
report_script=/usr/local/bin/send_report
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.116.20 -s 192.168.116.40
#shutdown_script=/usr/local/bin/power_manager
ssh_user=root

[server1]
hostname=192.168.116.50
port=3306

[server2]
hostname=192.168.116.20
port=3306

[server3]
hostname=192.168.116.40
port=3306
#candidate_master=1
#check_repl_delay=0

(5) The first startup needs to manually enable VIP on the Master node

ifconfig ens33:1 192.168.116.200/24

pre-launch test

start up

#开启
nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &

#检查开启状态
masterha_check_status --conf=/etc/masterha/app1.cnf

--remove_dead_master_conf #This parameter means that when the master-slave switch occurs, the ip of the old master library will be removed from the configuration file
--manger_log #Log storage location
--ignore_last_failover #By default, if MHA detects continuous If a downtime occurs and the interval between two downtimes is less than 8 hours, Failover will not be performed. The reason for this limitation is to avoid the ping-pong effect. This parameter means to ignore the file generated by the last MHA trigger switch. By default, after the MHA switch occurs, it will be recorded in the app1.failover.complete log file. If the file is found to exist in the directory when the switch is made again next time, it will not be allowed Trigger switch, unless the file is deleted after the first switch, set ignore_last_failover to
use &background running program #The result will be output to the terminal for convenience; use Ctrl+C to send SIGINT signal, the program is immune; close the session to send SIGHUP signal, the program is closed .

Run the program with nohup #The result will be output to nohup.out by default; use Ctrl+C to send the SIGINT signal, and the program will close; close the session and send the SIGHUP signal, and the program will be immune.

Use nohup and & to start the program nohup ./test &: Simultaneously immune to SIGINT and SIGHUP signals.

3. Fault simulation

Close the master's mysqld service

Track the log of the mha server (found that the switch was successful)

View mha's configuration file

View Slave1 node

View Slave2 node

4. Restoration of faulty database

1. Flush tables with read lock on the current main library lock table; (to prevent new data from being written when the slave node is restored)

2. Restore the fault database data; (according to the binary log or import sql file)

3. Re-change the master and start the slave to restore the use of the faulty database.

Guess you like

Origin blog.csdn.net/wlc1213812138/article/details/131879079