• 欢迎来到本博客,希望可以y一起学习与分享

MySQL集群-MHA高可用架构

MySQL benz 4个月前 (05-20) 10次浏览 0个评论 扫描二维码
文章目录[隐藏]

前言

在 MySQL 的高可用方案中,MHA(Master High Availability)可谓是最为成熟、使用最为广泛的方案之一了。其作者 Yoshinori Matsunobu 现就职于 Facebook,该架构采用 perl 语言编写,可完成秒级别的主库故障切换,接下来详细介绍 MHA 在铜板街的上线之路。

架构选型

在开始计划实施 MySQL 数据库高可用时,我们选择了比较流行的几大方案,分别进行了调研。

MHA:适用于一主多从的架构体系,在故障切换过程中,可从宕机的主库上保存二进制日志,最大程度的保证数据不丢失。但是需要 MHA 架构内所有的节点都必须可以 ssh互通。

MMM:(Master-Master replication manager for MySQL) 适用于双主架构,是一套支持双主故障切换和日常管理的脚本程序,虽无需架构内 ssh 互通,但是无法保存主库的二进制日志,所以数据一致性不如 MHA 高。

PXC:(Percona XtraDB Cluster)是 percona 公司提供的一套高可用方案,需要三个或以上 percona 版本的 DB 节点,该架构保证了数据强一致,但是同等硬件配置下,性能不如 MHA 和 MMM,尤其木桶效应明显,该方案还需依赖外部组件。

MGR:(MySQL Group Replication)是 MySQL 官方发布的高可用架构,该方案依赖于 MySQL5.7 版本,适用于主从架构,但是需要类似主库全表包含主键等相关依赖,成熟度不如以上方案,该方案同样需要依赖外部组件。

综上,在结合自身的业务场景,最终选择 MHA 作为 MySQL 集群的高可用方案。以下详细介绍 MHA 的体系结构及部署和测试的各项细节。

架构简介

MHA - Master High Availability 是由 Perl 实现的一款高可用程序,出现故障时,MHA 以最小的停机时间(通常10-30秒)执行 master 的故障转移以及 slave 的升级。MHA 可防止复制一致性问题,并且易于安装,不需要改变现有部署。

MHA 由MHA managerMHA node组成, MHA manager是一个监控管理程序,用于监控MySQL master状态; MHA node是具有故障转移的工具脚本,如解析 MySQL 二进制/中继日志,传输应用事件到SlaveMHA node在每个MySQL服务器上运行。

MHA manager调用MHA node工具脚本的方式是SSH到主机上然后执行命令,所以各节点需要做等效验证。

MHA 怎么保证数据不丢失

Master宕机后,MHA会尝试保存宕机Master的二进制日志,然后自动判断MySQL集群中哪个实例的中继日志是最新的,并将有最新日志的实例的差异日志传到其他实例补齐,从而实现所有实例数据一致。然后把宕机Master的二进制日志应用到选定节点,并提升为 Master

具体流程如下:

  1. 尝试从宕机Master中保存二进制日志
  2. 找到含有最新中继日志的Slave
  3. 把最新中继日志应用到其他实例,实现各实例数据一致
  4. 应用从Master保存的二进制日志事件
  5. 提升一个SlaveMaster
  6. 其他Slave向该新Master同步

从切换流程流程可以看到,如果宕机Master主机无法SSH登录,那么第一步就没办法实现,对于MySQL5.5以前的版本,数据还是有丢失的风险。对于5.5后的版本,开启半同步复制后,真正有助于避免数据丢失,半同步复制保证至少一个 (不是所有)slave 在 master 提交时接收到二进制日志事件。因此,对于可以处理一致性问题的MHA 可以实现”几乎没有数据丢失”和”从属一致性”。

MHA 优点和限制

优点

  • 开源,用Perl编写
  • 方案成熟,故障切换时,MHA会做日志补齐操作,尽可能减少数据丢失,保证数据一
  • 部署不需要改变现有架构

限制

  • 各个节点要打通SSH信任,有一定的安全隐患
  • 没有 Slave 的高可用
  • 自带的脚本不足,例如虚IP配置需要自己写命令或者依赖其他软件
  • 需要手动清理中继日志

搭建

MHA只支持一主多从,即使是备master,也是主库的从库。

目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二 从,即一台充当master,一台充当备用master,另外一台充当从库,因为至少需要三台服务器。

角色

IP

主机名

类型

Manager

192.168.171.150

manager

管理节点

Master

192.168.171.151

master

主mysql(写入)

CandicateMaster

192.168.171.152

slave1

从mysql(读)

slave

192.168.171.153

slave2

从mysql(读)

其中master对外提供写服务,备选master(实际的slave,主机名slave1)提供读服务,slave也提供相关的读 服务,一旦master宕机,将会把备选master提升为新的master,slave指向新的master,manager作为管理服务器。

主机部署

【4个节点】改主机名:(根据上面表格改)

【4个节点】将ip和域名配置到/etc/hosts文件中

【4个节点】上的防火墙上加上端口的允许

这条规则的意思是,想要在输入数据INPUT中,protocol为tcp/IP的方式,访问端口3306,都会被允许的

【4个节点】都配置epel源

用ssh-keygen实现四台主机之间相互免密钥登录

1.生成密钥

【4个节点】执行以下命令

安装mha4mysql-node

mha4mysql-node地址:Github

【4个节点】执行以下命令:

安装mha4mysql-manager

mha4mysql-manager地址:Github

【manager节点】执行以下命令:

建立master,slave1,slave2之间主从复制

为了尽可能的减少主库硬件损坏宕机造成的数据丢失,因此在配置MHA的同时建议配置成MySQL的半同步复制。

注:mysql半同步插件是由谷歌提供,具体位置/usr/local/mysql/lib/plugin/下,一个是master用的semisync_master.so,一个是slave用的semisync_slave.so

在MySQL上安装插件需要数据库支持动态载入,检查是否支持,用如下命令检测:

所有MySQL都可以成为主节点,所有mysql 都开启插件

检查Plugin是否已正确安装:

查看半同步相关信息

上图可以看到半同复制插件已经安装,只是还没有启用,所以是off。

修改my.cnf文件

注:若主MYSQL服务器已经存在,只是后期才搭建从MYSQL服务器,在置配数据同步前应先将主MYSQL服务器的要同步的数据库拷贝到从MYSQL服务器上(如先在主MYSQL上备份数据库,再用备份在从MYSQL服务器上恢复)

所有MySQL配置:

rpl_semi_sync_master_enabled=1: 1表是启用,0表示关闭

rpl_semi_sync_master_timeout=10000:毫秒单位 ,该参数主服务器等待确认消息10秒后,不再等待,变为异步方式。
relay_log_purge=0:禁止 SQL 线程在执行完一个 relay log 后自动将其删除,对于MHA场景下,对于某些滞后从库的恢复依赖于其他从库的relay log,因此采取禁用自动删除功能。

在所有服务器上重启mysql服务。

进入mysql,查看半同步相关信息。

查看半同步状态

有几个状态参数值得关注的:

rpl_semi_sync_master_status :显示主服务是异步复制模式还是半同步复制模式
rpl_semi_sync_master_clients :显示有多少个从服务器配置为半同步复制模式
rpl_semi_sync_master_yes_tx :显示从服务器确认成功提交的数量
rpl_semi_sync_master_no_tx :显示从服务器确认不成功提交的数量
rpl_semi_sync_master_tx_avg_wait_time :事务因开启 semi_sync ,平均需要额外等待的时间
rpl_semi_sync_master_net_avg_wait_time :事务进入等待队列后,到网络平均等待时间

所有MySQL创建复制账号并授权复制

所有MySQL创建MHA管理账号并授权管理

在主库上,查看信息

第一条grant命令是创建一个用于主从复制的帐号,在master和candicate master的主机上创建即可。

第二条grant命令是创建MHA管理账号,所有mysql服务器上都需要执行。MHA会在配置文件里要求能远程登录到数据库,所以要进行必要的赋权。
所有从库链接到主库

查看从的状态,以下两个值必须为yes,代表从服务器能正常连接主服务器。

Slave_IO_Running:Yes
Slave_SQL_Running:Yes

 

查看master服务器的半同步状态

rpl_semi_sync_master_clients :显示有2个从服务器配置为半同步复制模式。

配置mha

在manager节点上

检查SSH配置免密互通

最后显示:All SSH connection tests passed successfully.则为成功。
验证配置

最后 显示:MySQL Replication Health is OK.则为成功。
如果NodeUtil.pm报错,则修改如下:

后台运行

状态检查

测试

停掉master上的mysql服务,查看MHA的日志

日志文件显示:

上面的结果表明master成功切换。至此,MHA成功搭建。

手动切换主从

需要停止MHA manager,manager会自动切换。

注意

宕机的MySQL重回集群

宕机的MySQL重回集群,只能作为现主库的从库。在manager.log上有change master的SQL语句,把SQL语句复制到加入集群的MySQL;

显示如下即为成功:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
重新运行MHA manager

从库不能写数据

从库不能写数据,从库的数据不会同步到主库,且主库同步数据到此库,数据不一致,会报错。
先主库导出到从库,再在从库跳过这条数据https://xiaojin21cen.blog.csdn.net/article/details/107503806

 

master_ip_failover 脚本

master_ip_online_change 脚本

send_report 脚本

清理中继日志定时任务

下面是我的定时任务,参数自行替换, workdir 需要和中继日志在同一个盘

参考

MySQL集群搭建(5)-MHA高可用架构
MySQL高可用之MHA
MySQL高可用架构之MHA
docker搭建Mysql主从MHA高可用集群
MySQL高可用架构之MHA


文章 MySQL集群-MHA高可用架构 转载需要注明出处
喜欢 (0)

您必须 登录 才能发表评论!