MySQL高可用之MHA集群(下)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 一、MHA概述1.1 什么是 MHAMHA(MasterHigh Availability)是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。MHA 的出现就是解决MySQL 单点故障的问题。


6、在 manager 节点上测试 ssh 无密码认证

在 manager 节点上测试 ssh 无密码认证,如果正常最后会输出 successfully,如下所示。

masterha_check_ssh -conf=/etc/masterha/app1.cnf
 Sun Jun 12 22:44:40 2022 - [debug]  Connecting via SSH from root@192.168.72.192(192.168.72.192:22) to root@192.168.72.60(192.168.72.60:22)..
 Sun Jun 12 22:44:41 2022 - [debug]   ok.
 Sun Jun 12 22:44:41 2022 - [debug]  Connecting via SSH from root@192.168.72.192(192.168.72.192:22) to root@192.168.72.80(192.168.72.80:22)..
 Sun Jun 12 22:44:42 2022 - [debug]   ok.
 Sun Jun 12 22:44:43 2022 - [debug]
 Sun Jun 12 22:44:41 2022 - [debug]  Connecting via SSH from root@192.168.72.60(192.168.72.60:22) to root@192.168.72.192(192.168.72.192:22)..
 Sun Jun 12 22:44:42 2022 - [debug]   ok.
 Sun Jun 12 22:44:42 2022 - [debug]  Connecting via SSH from root@192.168.72.60(192.168.72.60:22) to root@192.168.72.80(192.168.72.80:22)..
 Sun Jun 12 22:44:42 2022 - [debug]   ok.
 Sun Jun 12 22:44:43 2022 - [debug]
 Sun Jun 12 22:44:41 2022 - [debug]  Connecting via SSH from root@192.168.72.80(192.168.72.80:22) to root@192.168.72.192(192.168.72.192:22)..
 Sun Jun 12 22:44:42 2022 - [debug]   ok.
 Sun Jun 12 22:44:42 2022 - [debug]  Connecting via SSH from root@192.168.72.80(192.168.72.80:22) to root@192.168.72.60(192.168.72.60:22)..
 Sun Jun 12 22:44:43 2022 - [debug]   ok.
 Sun Jun 12 22:44:43 2022 - [info] All SSH connection tests passed successfully.
复制代码


网络异常,图片无法展示
|


7、在 manager 节点上测试 mysql 主从连接情况

在 manager 节点上测试 mysql 主从连接情况,最后出现MySQL Replication Health is OK 字样说明正常。如下所示。

masterha_check_repl -conf=/etc/masterha/app1.cnf
 Sun Jun 12 22:47:28 2022 - [info] Slaves settings check done.
 Sun Jun 12 22:47:28 2022 - [info]
 192.168.72.192(192.168.72.192:3306) (current master)
  +--192.168.72.60(192.168.72.60:3306)
  +--192.168.72.80(192.168.72.80:3306)
 Sun Jun 12 22:47:28 2022 - [info] Checking replication health on 192.168.72.60..
 Sun Jun 12 22:47:28 2022 - [info]  ok.
 Sun Jun 12 22:47:28 2022 - [info] Checking replication health on 192.168.72.80..
 Sun Jun 12 22:47:28 2022 - [info]  ok.
 Sun Jun 12 22:47:28 2022 - [info] Checking master_ip_failover_script status:
 Sun Jun 12 22:47:28 2022 - [info]   /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.72.192 --orig_master_ip=192.168.72.192 --orig_master_port=3306
 IN SCRIPT TEST====/sbin/ifconfig ens33:1 down==/sbin/ifconfig ens33:1 192.168.72.100===
 Checking the Status of the script.. OK
 Sun Jun 12 22:47:28 2022 - [info]  OK.
 Sun Jun 12 22:47:28 2022 - [warning] shutdown_script is not defined.
 Sun Jun 12 22:47:28 2022 - [info] Got exit code 0 (Not master dead).
 MySQL Replication Health is OK.     #出现该字样说明主从连接正常
复制代码


网络异常,图片无法展示
|


网络异常,图片无法展示
|


8、在 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 &
 ------------------------------以下都是注释-----------------------------------------------------------
 --remove_dead_master_conf   #该参数代表当发生主从切换后,老的主库的 ip 将会从配置文件中移除。
 --manger_log                #日志存放位置。
 --ignore_last_failover      #在缺省情况下,如果 MHA 检测到连续发生宕机,且两次宕机间隔不足 8 小时的话,则不会进行 Failover, 之所以这样限制是为了避免 ping-pong 效应(来回切换导致脑裂)。该参数代表忽略上次 MHA 触发切换产生的文件,默认情况下,MHA 发生切换后会在 app1.failover.complete 日志文件中记录,下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换, 除非在第一次切换后删除该文件,为了方便,这里设置为--ignore_last_failover。
 -------------------------------------------------------------------------------------
 ●使用&后台运行程序:结果会输出到终端;使用Ctrl+C发送SIGINT信号,程序免疫;关闭session发送SIGHUP信号,程序关闭。
 ●使用nohup运行程序:结果默认会输出到nohup.out;使用Ctrl+C发送SIGINT信号,程序关闭;关闭session发送SIGHUP信号,程序免疫。
 ●使用nohup和&配合来启动程序 nohup ./test &:同时免疫SIGINT和SIGHUP信号。
 -------------------------------------------------------------------------------------
复制代码


网络异常,图片无法展示
|


9、在 manager 节点上查看 MHA 状态 和 MHA 日志,可以看到 master的地址

#查看 MHA 状态,可以看到当前的 master 是 Mysql1 节点。
 masterha_check_status --conf=/etc/masterha/app1.cnf
 #查看 MHA 日志,也可以看到当前的 master 是 192.168.72.192
 cat /var/log/masterha/app1/manager.log | grep "current master"
复制代码


网络异常,图片无法展示
|


10、在Mysql1上查看 VIP 地址 192.168.72.100 是否存在

查看 Mysql1 的 VIP 地址 192.168.72.100 是否存在,这个 VIP 地址不会因为 manager 节点停止 MHA 服务而消失。

ifconfig
 #若要关闭 manager 服务,可以使用如下命令。
 masterha_stop --conf=/etc/masterha/app1.cnf
 #或者可以直接采用 kill 进程 ID 的方式关闭。
复制代码


网络异常,图片无法展示
|


3.3 故障模拟

在Mysql1上停止mysql服务,MHA 会自动修改 app1.cnf 文件内容,将宕机的 mysql1 节点删除。 mysql2 会自动接管 VIP,成为新的master。

##(1)在 Master 节点 Mysql1 上停止mysql服务
 systemctl stop mysqld
 pkill -9 mysql
 ##(2)在 manager 节点上监控观察日志记录
 tail -f /var/log/masterha/app1/manager.log
 Master 192.168.72.192(192.168.72.192:3306) is down!  #监控到master宕机
 Selected 192.168.72.60(192.168.72.60:3306) as a new master.  #选举mysql2成功新的master
 ##(3)正常自动切换一次后,MHA 进程会退出。MHA 会自动修改 app1.cnf 文件内容,将宕机的 mysql1 节点删除。
 vim /etc/masterha/app1.cnf   #查看manager节点的配置文件
 ##(4)查看 mysql2 是否接管 VIP
 ifconfig
 ------------------------故障切换备选主库的算法------------------------
 故障切换备选主库的算法:
 1.一般判断从库的是从(position/GTID)判断优劣,数据有差异,最接近于master的slave,成为备选主。
 2.数据一致的情况下,按照配置文件顺序,选择备选主库。
 3.设定有权重(candidate_master=1),按照权重强制指定备选主。
 (1)默认情况下如果一个slave落后master 100M的relay logs的话,即使有权重,也会失效。
 (2)如果 check_repl_delay=0 的话,即使落后很多日志,也强制选择其为备选主。
复制代码


(1)在 Master 节点 Mysql1 上停止mysql服务:

网络异常,图片无法展示
|


(2)在 manager 节点上监控观察日志记录,manager选举了mysql2作为新的主服务器:

网络异常,图片无法展示
|


网络异常,图片无法展示
|


(3)查看manager节点的配置文件。MHA 会自动修改 app1.cnf 文件内容,将宕机的 mysql1 节点删除。

网络异常,图片无法展示
|


(4) mysql2 已接管 VIP

网络异常,图片无法展示
|


3.4 故障修复

1)修复mysql1(即修复原来的主节点)

systemctl restart mysqld
复制代码


网络异常,图片无法展示
|


2)修复主从数据

#在新的主库服务器 Mysql2 中查看二进制日志文件和同步点
 show master status;
 +-------------------+----------+--------------+------------------+      
 | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |     
 +-------------------+----------+--------------+------------------+       
 | master-bin.000002 |     1745 |              |                  |                   
 +-------------------+----------+--------------+------------------+   
 #在原主库服务器 mysql1 执行同步操作,同步现在主库中的数据
 change master to master_host='192.168.72.60',master_user='myslave',master_password='123123',master_log_file='master-bin.000002',master_log_pos=1745;
 start slave;
复制代码


在新的主库服务器 Mysql2 查看二进制日志文件和同步点:

网络异常,图片无法展示
|


在原主库服务器 mysql1 执行同步操作,同步现在主库中的数据:

网络异常,图片无法展示
|


3)在 manager 节点上修改配置文件app1.cnf

重新把三台mysql节点服务器这个记录添加进去,因为它检测到主节点失效时候会自动删除主节点。

将mysql1添加为新的候选master。

vi /etc/masterha/app1.cnf
 ......
 secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.72.192 -s 192.168.72.80
 ......
 [server1]
 hostname=192.168.72.60
 port=3306
 [server2]
 candidate_master=1
 check_repl_delay=0
 hostname=192.168.72.192
 port=3306
 [server3]
 hostname=192.168.72.80
 port=3306
复制代码


网络异常,图片无法展示
|


4)在 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 &
复制代码


网络异常,图片无法展示
|


小贴士

解决中英字符不兼容报错的问题,可执行如下语句:

dos2unix /usr/local/bin/master_ip_failover
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
164 3
Mysql高可用架构方案
|
2月前
|
分布式计算 关系型数据库 MySQL
大数据-88 Spark 集群 案例学习 Spark Scala 案例 SuperWordCount 计算结果数据写入MySQL
大数据-88 Spark 集群 案例学习 Spark Scala 案例 SuperWordCount 计算结果数据写入MySQL
56 3
|
2月前
|
消息中间件 分布式计算 关系型数据库
大数据-140 - ClickHouse 集群 表引擎详解5 - MergeTree CollapsingMergeTree 与其他数据源 HDFS MySQL
大数据-140 - ClickHouse 集群 表引擎详解5 - MergeTree CollapsingMergeTree 与其他数据源 HDFS MySQL
62 0
|
2月前
|
SQL 分布式计算 关系型数据库
Hadoop-24 Sqoop迁移 MySQL到Hive 与 Hive到MySQL SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
Hadoop-24 Sqoop迁移 MySQL到Hive 与 Hive到MySQL SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
110 0
|
2月前
|
SQL 分布式计算 关系型数据库
Hadoop-23 Sqoop 数据MySQL到HDFS(部分) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
Hadoop-23 Sqoop 数据MySQL到HDFS(部分) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
51 0
|
2月前
|
SQL 分布式计算 关系型数据库
Hadoop-22 Sqoop 数据MySQL到HDFS(全量) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
Hadoop-22 Sqoop 数据MySQL到HDFS(全量) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
60 0
|
2月前
|
SQL 关系型数据库 MySQL
mysql集群方案
mysql集群方案
51 0
|
4月前
|
SQL 关系型数据库 MySQL
orchestrator搭建mysql高可用
orchestrator搭建mysql高可用
57 0
|
5天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
19 3
|
5天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
23 3