标签：可用 -- server1 MHA masterha master 切换 mysql
mysql的高可用切换
mysql的高可用切换
我们前面在做主从的时候是我们手动的分配的server1是主，
server2从库存在意义就是，主库宕机的时候，去接替它的工作，
但是自动转换，主库往从库转换是第三方软件MHA来做的(人为来做的话,效率太低了)
MHA是一个日本人开发的，这个日本人现在Facebook工作，
MHA的前提是做好主从，我们使用server1，server2，server3来做高可用，
关闭三台主机mysqld，都配置主从复制和gtid复制
先将三台机器的主从给停止了
server1，server2，server3同时执行
systemctl stop mysqld
将主从复制和gtid复制的配置写在里面
(其实也可以在主从复制的基础上做半同步复制使高可用更可靠)
三个是做主从切换的，所以每台主机机可能称为master也可能称为slave，
所以要开启binlog日志(主才开)，现在都可能为主，所以就每个都打开binlog日志
Server1：
vim /etc/my.cnf
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
log_bin=binlog
Server2：
Server3：
启动1的mysql，初始化，授权
现在认为server1是主，server2和server3是server1的从库
Server1：
mysql_secure_installation
然后设置server1为主库，
参考Mysql(1.1)主从复制_1的配置：
grant replication slave on *.* to huige@'172.25.21.%' identified by 'Westos.123';
配置2的mysql启动，初始化，配置Gtid指定主库
然后做从
Server2：
然后从机上的操作是基于Gtid的主从复制：
change master to master_host ='172.25.21.1', #指定主库的ip地址
master_user='huige', #从库复制的主库的用户
master_password='Westos.123', #主库的密码,注意我们这里的密码改了
master_auto_position=1; #设定为自动
start slave
3的mysql和2操作相同
Server3：
systemctl start mysqld
cat /var/log/mysqld.log | grep password
mysql_secure_installation
mysql -uroot -pWestos.123
start slave;
show slave status\G
开启一台server4，模拟偶数选举票数相同情况
然后我们再准备一台server4
在线上的操作中一般都是3台，
这样的话如果主宕机了，三台主机就可以投票选举出一个主机来做新的master，
如果是偶数的服务器数量就会出现票数相同的情况
Server4：
安装MHA的管理包和node包
下载MHA的管理节点和perl相关包，还有MHA的节点安装包
yum install -y mha4mysql-manager-0.58-0.el7.centos.noarch.rpm perl-* mha4mysql-node-0.58-0.el7.centos.noarch.rpm
4做免密连接1,2,3
做免密操作，
Server4要免密连接server1，server2，server3
ssh-keygen
ssh-copy-id server1
ssh-copy-id server2
ssh-copy-id server3
其他节点配置MHAnode包
在其他节点上配置MHA的node包
可以看到我们传输文件是免密的
给server1，server2，server3同时执行如下命令
yum install -y mha4mysql-node-0.58-0.el7.centos.noarch.rpm
给高可用一个信息，告诉高可用主机，mysql节点是怎么工作的
配置高可用主机4的高可用配置文件
Server4:
mkdir /etc/masterha/
vim /etc/masterha/app1.cnf
[server default]
manager_workdir=/etc/masterha #MHA的主目录
manager_log=/var/log/masterha.log #MHA的日志文件
master_binlog_dir=/etc/masterha #binlog日志目录
#master_ip_failover_script=/usr/local/bin/master_ip_failover #这里是两个脚本
#master_ip_online_change_script=/usr/local/bin/master_ip_online_change
password=Westos.123 #mysql的管理员帐号和密码
user=root
ping_interval=1
remote_workdir=/tmp
repl_password=Westos.123 #复制用户的帐号和密码(复制master的数据使用端的数据库用户)
repl_user=huige
#report_script=/usr/local/send_report
#secondary_check_script=/usr/local/bin/masterha_secondary_check -s server03 -s server02
#shutdown_script=""
ssh_user=root #系统ssh用户，使用这个用户去免密的连接server1，server2，server3
[server1]
hostname=172.25.21.1
port=3306
[server2]
hostname=172.25.21.2
port=3306
candidate_master=1 #这个参数为1，说明server2在主机宕机后有资格转换为master
check_repl_delay=0 #检查交互解释器repl的时延
[server3]
hostname=172.25.21.3
port=3306
no_master=1 #no_master表示这个节点不呢个做为master(我们先让server3作为backup，来试一试no_master这个参数)
masterha_check_ssh --conf=/etc/masterha/app1.cnf
检测ssh功能，出错，进行排错
检测ssh功能是否可用
这里可以看到检测三个节点的ssh的结果是失败的
根据报错可以看到是因为
1，2，3两两之间做好免密
scp -r /root/.ssh/ server1:
scp -r /root/.ssh/ server2:
scp -r /root/.ssh/ server3:
测试是否免密
然后再测试server1和server2，server3之间是否免密
Server1：
Server2：
Server3：
测试ssh可用
Server4：
再次检测高可用的ssh功能是否可用
测试复制功能
做完免密后ssh就正常了
然后去检测一下复制功能(根据我们自己写的这个配置文件)
能不能用，，能不能连接上远程数据库
masterha_check_repl --conf=/etc/masterha/app1.cnf
可以看到mysql的复制功能健康没有配置正确
我们再仔细看下报错:
Server4默认使用的root用户来连接数据，
但是在配置高可用集群的时候我们使用了root用户还
使用了普通用户huige来登陆数据库
4默认使用root用户连接主机，在主库给root授权
报错提示让我们检查mysql(master)的设置
我们给主库的root用户添加权限
Server1：
grant all on *.* to root@'%' identified by 'Westos.123';
测试成功
再次测试高可用的复制功能,可以看到这里的复制功能可以使用了
开启4的MHA，查看是否成功
然后测试server4的MHA能不能正常开启
nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha.log 2>&1 &
关掉MHA，测试手动切换
我们看到这个高可用是开启的
我们现在先将高可用给关掉
然后我们先进行手动切换
感受一下切换的过程
Server4：
masterha_stop --conf=/etc/masterha/app1.cnf
先测试手动切换是否可以成功：
关掉server1的mysql，将server1 master迁移到server2上 #死切
Server1:
systemctl stop mysqld
关掉server1上的mysql后，这样mysql master就死掉了
我们现在要手动来将master迁到server2上去，
Server4：
masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=172.25.21.1 --dead_master_ip=172.25.21.1 --dead_master_port=3306 --new_master_host=172.25.21.2 --new_master_port=3306
#注意第一遍我们执行的时候由于应该输入yes的时候，输成了别的，
然后我就使用Ctrl +C中断了命令的执行
我再次执行这个命令时报错如下:
file /etc/masterha/app1.failover.error exists
然后根据报错，可以知道是该命令执行错了以后会生成一个
/etc/masterha/app1.failover.error文件，有这个文件
则执行 masterha_master_switch命令手动迁移master到server2时会失败
(因为这个命令是否出错，读取的就是这个文件，所以我们将这个文件删掉即可)
rm -fr /etc/masterha/app1.failover.error
手动迁移成功后，
去server3上：
因为server3是加入到高可用节点中的，所以是可以检测到server2变成了master
可以看到这里新的master已经变成了server2
MHA只管主从切换
我们要手动保证每个节点的主从复制都是没有问题的
这时我们启动server1的mysql
再将server1上的mysql加到主从复制节点中去
Server1：
这时server1就变成了备机
这时我们就要重新配置Gtid的主从复制：
主变成了server2
给server1在数据库中配置新的Gtid主从复制：
Server1：
change master to master_host ='172.25.21.2',
master_user='huige',
master_password='Westos.123',
master_auto_position=1;
start slave;
在我们切换完后在server4中的cd /etc/masterha/中会生成一个app1.failover.complete文件是进行错误域的转换记录
下一次我们进行测试时要将这个文件给删掉
否则下次就不成功了
在master server2的mysql正常运行的话， #活切
我们进行将master切换到server1上
注意我们不能将/etc/masterha下的app1.cnf给删掉
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=172.25.21.1 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
敲三个yes
可以看到活切成功
Server2：
Server3：
活切测试成功
手动的死切和活切都实现了
半自动切换主从(底层的主从还是要自己手动来做)：
我们在切完后，下次测试之前一定要将 app1.failover.complete删掉
nohup masterha_manager --conf=/etc/masterha/app1.cnf &>/dev/null &
#注意这个命令&>/dev/null中间不能有空格
我们让MHA自己去检测，把MHA自带的守护进程开启在后台
kill -9 721
我们将server1上的mysql进程给删掉
然后发现这个mysql自动开启
(MHA的半自动切换模式可以帮我们监控节点上的mysql依赖是否停止，如果停止，帮我们自动开启mysql)
这时将server1上面的mysql给停掉
使用MHA半自动切换
Server4：
刚才是手动，现在我们已经将这个进程在后台运行了
Server3：
我们去server3的数据库中查看：
可以看到server2已经自动变成新的master了
Server1：
然后再把server1上线：
给server1在数据库中配置新的Gtid主从复制：
Server1：
change master to master_host ='172.25.21.2',
master_user='huige',
master_password='Westos.123',
master_auto_position=1;
start slave;
show slave status\G
MHA全自动(使用脚本)
我们在做mysql高可用的时候，其实用户使用mysql时的接进来的IP只有一个，
谁是主谁拿到这个IP，用户不知道这个高可用集群有多少个，谁是主，谁是从，
由于用户的入口只有一个，所以这里就需要配置一个VIP(用户访问的IP)
我们把两个脚本下载下来：
配置自动删除和添加vip
我们去修改一下脚本的内容，把ssh vip修改一下
#将添加一个IP(VIP)的命令赋给一个添加vip变量
#将删出一个IP(VIP)的命令赋给一个删出vip变量
my $ssh_start_vip = "/sbin/ip addr add $vip dev eth0";
my $ssh_stop_vip = "/sbin/ip addr del $vip dev eth0";
cp master_ip_failover master_ip_online_change /usr/local/bin
chmod +x master_ip_failover
chmod +x master_ip_online_change
然后我们去/etc/masterha/下面清空app1.failover.complete
然后将app1.cnf中的两个脚本的注释符号删掉
我们将加完权限的脚本一定要放在app1.cnf中规定的路径
Server2现在是master，我们不需要手动给server2配vip(如果要将server2上的服务给server1时，后面如果某个出问题，往另一个切换时只有一个节点有vip)
这时我们来测vip的漂移
测试一次手动
将后台运行的高可用关掉(防止自动切换)
测试活切:
现在往server1上切
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=172.25.21.1 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
敲三个yes
Server2：
Server3：
然后在server1：
Server1上有了vip，而且称为了master
全自动：
Server4：
可以看到没有错误域文件
将MHA开在后台，现在是全自动
nohup masterha_manager --conf=/etc/masterha/app1.cnf &>/dev/null &
这里有两种操作模式，手动和自动，
对数据库操作要非常谨慎
很多人不愿意使用全自动，不想将所有的资源都交给MHA服务来管理，想将资源都留在手边
然后将master主机server1上的mysql给关掉
Server4：
Server2已经切换过来
在server3上看一下：
master切换成server2
再看server1时发现vip被server2抢了去
标签：可用,--,server1,MHA,masterha,master,切换,mysql 来源： https://blog.csdn.net/qq_43309149/article/details/114776581
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。