高可用模式下的故障切换,基于主从复制。
单点故障和主从复制不能切换的问题。
至少需要三台。
故障切换过程0-30秒
vip地址,根据vip地址所在的主机,确定主备。
主 vip
备 vip
主和备不是优先级确定的,主从复制的时候就确定了,备是在MHA的过程中确定。
MHA的组件:
MHA NODE 数据节点,每台mysql和管理服务器都要安装 监控服务器状态以及收集数据
MHA的 manager 管理节点
管理mysql的高可用集群
可以单独部署在一台独立的服务器,也可以部署多个。
实现主备之间切换,主发生故障,切换到备。
MHA的特点:
1、manager来实现主备切换
2、数据同步还是依靠二进制日志,最大程度上保证数据的完整
3、半同步的方式实现数据的完整性
支持一主多从的架构,至少要三台。
实现MySQL的高可用
一主两从
搭建完成MHA的架构
主备之间的切换
故障恢复
4台机器
master 192.168.124.10 MySQL8.0 node组件
master 192.168.124.10 MySQL8.0 node组件
master 192.168.124.10 MySQL8.0 node组件
管理节点 192.168.233.20 node组件
先修改各个主机的主机名
hostnamectl set-hostname master
hostnamectl set-hostname slave1
hostnamectl set-hostname slave2
修改 master、slave1、slave2 节点的 Mysql主配置文件/etc/my.cnf
master
log_bin = master-bin:
用于记录主服务器上的更改操作的日志文件。
这个配置用于主服务器,将生成的二进制日志文件保存为"master-bin"(可以是其他自定义的名称)
log-slave-updates = true:
从服务器是否要记录它自己执行的更改操作到自己的二进制日志文件中。
设置为"true"表示从服务器会记录自己执行的更改操作,将其写入从服务器的二进制日志文件中。
slave1
log_bin = master-bin:
指定主服务器(master)的二进制日志文件名称,用于记录主服务器上的更改操作的日志文件。
relay-log = relay-log-bin:
指定从服务器的中继日志文件名称,即用于记录主服务器的二进制日志在从服务器上执行的中继日志。
从服务器会读取主服务器的二进制日志并将其记录到中继日志中。这个配置用于从服务器。
relay-log-index = slave-relay-bin.index:
指定从服务器的中继日志索引文件的名称,该索引文件用于跟踪中继日志文件的位置和顺序。
通过这个索引文件,从服务器知道哪个中继日志文件是下一个要读取和执行的。这个配置用于从服务器。
slave2
slave2不用设置master,指定主的备服务器为slave1即可。(永远的备胎)
在 master、slave1、slave2 节点上都创建两个软链接
ln -s /usr/local/mysql/bin/mysql /usr/sbin/
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/
配置 mysql 一主两从
master
CREATE USER 'myslave'@'192.168.233.%' IDENTIFIED WITH mysql_native_password BY '123456';
GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.233.%';
#manager 使用
CREATE USER 'mha'@'192.168.233.%' IDENTIFIED WITH mysql_native_password BY 'manager';
GRANT ALL PRIVILEGES ON *.* TO 'mha'@'192.168.233.%' WITH GRANT OPTION;
#防止从库通过主机名连接不上主库
CREATE USER 'mha'@'master' IDENTIFIED WITH mysql_native_password BY 'manager';
GRANT ALL PRIVILEGES ON *.* TO 'mha'@'master';
CREATE USER 'mha'@'slave1' IDENTIFIED WITH mysql_native_password BY 'manager';
GRANT ALL PRIVILEGES ON *.* TO 'mha'@'slave1';
CREATE USER 'mha'@'slave2' IDENTIFIED WITH mysql_native_password BY 'manager';
GRANT ALL PRIVILEGES ON *.* TO 'mha'@'slave2';
flush privileges;
在 master 节点查看二进制文件和同步点
在 Slave1、Slave2 节点执行同步操作
change master to master_host='192.168.124.10',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=2921;
start slave;
在 Slave1、Slave2 节点查看数据同步结果
show slave status\G;
//确保 IO 和 SQL 线程都是 Yes,代表同步正常。
两个从库必须设置为只读模式:
set global read_only=1;
插入数据测试数据库同步
所有服务器上都安装 MHA 依赖的环境,首先安装 epel 源
yum install -y perl-DBD-MySQL \
perl-Config-Tiny \
perl-Log-Dispatch \
perl-Parallel-ForkManager \
perl-ExtUtils-CBuilder \
perl-ExtUtils-MakeMaker \
perl-CPAN
安装 MHA 软件包,先在所有服务器上必须先安装 node 组件
对于每个操作系统版本不一样,这里 CentOS7.6选择 0.57 版本。
在所有服务器上必须先安装 node 组件,最后在 MHA-manager 节点上安装 manager 组件,
因为 manager 依赖 node 组件。
cd /opt
tar zxvf mha4mysql-node-0.57.tar.gz
cd mha4mysql-node-0.57
perl Makefile.PL
make && make install
在 MHA manager 节点上安装 manager 组件
tar zxvf mha4mysql-manager-0.57.tar.gz
cd mha4mysql-manager-0.57
perl Makefile.PL
make && make install
manager 组件安装后在/usr/local/bin 下面会生成几个工具,主要包括以下几个:
masterha_check_ ssh 所有的数据库节点和管理节点通过ssh来进行互相通信,检查集群的ssh配置
masterha_check_ repl 检查mysql的复制情况
masterha_manager 文件的启动脚本
masterha_check_status 检查MHA集群故障的文件
masterha_ master_ switch 控制故障转移
Imasterha_ stop 关闭manager服务
在所有服务器上配置无密码认证
在 manager 节点上配置到所有数据库节点的无密码认证
ssh-keygen -t rsa
ssh-copy-id 192.168.124.50
ssh-copy-id 192.168.124.51
master 上配置到数据库节点 slave1 和 slave2 的无密码认证
ssh-keygen -t rsa #一路按回车键
ssh-copy-id 192.168.124.10
ssh-copy-id 192.168.124.50
ssh-copy-id 192.168.124.51
在 slave1 上配置到数据库节点 master 和 slave2 的无密码认证
ssh-keygen -t rsa
ssh-copy-id 192.168.124.10
ssh-copy-id 192.168.124.51
在 slave2 上配置到数据库节点 master 和 slave1 的无密码认证
ssh-keygen -t rsa
ssh-copy-id 192.168.124.10
ssh-copy-id 192.168.124.50
在 manager 节点上复制相关脚本到/usr/local/bin 目录
cp -rp /opt/mha4mysql-manager-0.57/samples/scripts /usr/local/bin
master_ip_failover 自动切换时 VIP 管理的脚本
master_ip_online_change 在线切换时 vip 的管理
power_manager 故障发生后关闭主机的脚本
send_report 因故障切换后发送报警的脚本
复制上述的自动切换时 VIP 管理的脚本到 /usr/local/bin 目录,
这里使用master_ip_failover脚本来管理 VIP 和故障切换
cp /usr/local/bin/scripts/master_ip_failover /usr/local/bin
修改内容如下:(删除原有内容,直接复制并修改vip相关参数)
vim /usr/local/bin/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.124.100';
my $brdc = '192.168.124.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";
}
创建 MHA 软件目录并拷贝配置文件,这里使用app1.cnf配置文件来管理 mysql 节点服务器
在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
password=manager
ping_interval=1
remote_workdir=/tmp
repl_password=123456
repl_user=myslave
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.124.50 -s 192.168.124,51
#从对主监听
shutdown_script=""
ssh_user=root
user=mha
[server1]
hostname=192.168.124.10
#主服务器
port=3306
[server2]
candidate_master=1
check_repl_delay=0
hostname=192.168.124.50
#备用主服务器
port=3306
[server3]
hostname=192.168.124.51
#从服务器2
port=3306
第一次配置需要在 master 节点上手动开启虚拟IP
在 manager 节点上测试 ssh 无密码认证,如果正常最后会输出 successfully
在 manager 节点上测试 mysql 主从连接情况,最后出现 MySQL Replication Health is OK 字样说明正常。
在 manager 节点上启动 MHA
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 &
实现主服务器宕机了转移备服务器,备服务器变成主
打开manager节点上的日志记录
关闭主服务器的数据库
查看一下vip地址
不见了,查看一下备服务器slave1上的地址
vip地址已经飘到slave1上面了,查看一下manager节点上面的状态信息
查看一下实验结果新的主服务器slave1和备服务器slave2之间能不能实现主从关系
下面恢复原来的主服务器,先停掉manager节点
更改manager节点上app1.cnf上面的配置
更改一下原来从服务器的地址,把原来主服务器的ip地址添加进去
原来的server1消失不见了,把slave1变成主,master变成从,manager节点上就改这么多
更改原主的配置文件和现主的配置文件
更改原主的配置文件,把原来备的配置文件添加到原主的配置文件中
重启一下
进入现主服务器中的数据库中,把只读模式关闭
查看主的状态
进入现在的备服务器数据库中,设置成只读模式
然后停止和重置slave ,执行同步操作
回到manager节点上查看
这时候主变成192.168.124.50
在 manager 节点上测试 mysql 主从连接情况,最后出现 MySQL Replication Health is OK 字样说明正常。
查看一下实验结果
MySQL的MHA总结:
MHA 是一套用于 MySQL 高可用的解决方案,具有以下重要特点和优势:
特点:
1、自动故障切换:能够在主库出现故障时,快速自动地将从库提升为主库,减少服务中断时间。
2、数据一致性保障:在切换过程中,最大程度保证数据的一致性,避免数据丢失或不一致的情况。
3、无需修改现有部署:可以方便地集成到现有的 MySQL 主从复制架构中,无需对现有架构进行大规模修改。
工作原理 :
MHA 通常通过监控主库的状态来判断是否需要进行故障切换。它会定期检查主库的健康状况,包括网络连接、MySQL 服务状态等。一旦检测到主库故障,MHA 会选择一个最新的从库,并执行一系列操作将其提升为主库,包括应用剩余的 binlog 等。
配置步骤:
- 安装 MHA 相关软件包。
- 配置主从复制环境。
- 配置 MHA 管理节点和各个服务器节点。
- 测试故障切换流程。
实际应用中的注意事项:
- 网络延迟:要确保主从库之间的网络延迟在可接受范围内,以免影响故障切换的准确性和速度。
例如,如果网络延迟过高,可能导致 MHA 误判主库故障。 - 从库的同步状态:定期检查从库的同步状态,确保在需要切换时能够选择到最新的从库。
- 监控和告警:配置完善的监控和告警机制,及时发现潜在的问题并通知管理员。
总之,MHA 为 MySQL 提供了一种可靠的高可用解决方案,但在实际应用中需要仔细配置和维护,以确保其正常稳定运行。