注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MySQL基于MHA高可用部署篇(GTID模式)

MySQL 彭东稳 8608次浏览 已收录 0个评论

一、GTID与MHA

MHA是被广泛使用MySQL HA组件,MHA 0.56以后支持基于GTID的复制。 MHA在failover时会自动判断是否是GTID based failover,需要满足下面3个条件即为GTID based failover。

  • 所有节点gtid_mode=1
  • 所有节点Executed_Gtid_Set不为空
  • 至少一个节点Auto_Position=1

和之前的基于binlog文件位置的复制相比,基于GTID复制下,MHA在故障切换时的变化主要如下:

基于binlog文件位置的复制

  • 在Master宕机后会尝试从Master上拷贝binlog日志进行补偿。
  • 如果候选Master不拥有最新的relay log,会从拥有最新relay log的Slave上生成差异的binlog传送到候选Master并实施补偿。
  • 新Master的日志补偿完成后,同样采用应用差异binlog的方式将其它Slave和新Master同步后再change master到新Master。

基于GTID的复制

  • 如果候选Master不拥有最新的relay log,让候选Master连上拥有最新relay log的Salve进行补偿。
  • 尝试从binlog server上拉取缺失的binlog并应用。
  • 新Master的数据同步到最新后,让其它的Slave连上新Master并等待数据完成同步。并且可以给masterha_master_switch传入–wait_until_gtid_in_sync=1参数使其不等其它Slave完成数据同步,以加快切换速度。

GTID模式下MHA不会尝试从旧Master上拷贝binlog日志进行补偿,所以在MySQL进程Crash而OS仍然健康的情况下,应尽量不要做主备切换而是原地重启MySQL,除非有其它能确保切换后不丢数据的措施。但在GTID模式下MHA支持在复制拓扑中增加一个或多个 binlog server 起到日志补偿的作用,非GTID模式下即使配置了binlog server 也会被MHA忽略。

日志补偿可以说是MHA中最复杂也最精华的部分,有了GTID后故障切换变得更简单了,不再需要原本复杂的binlog日志解析和补偿。所以Oracle官方推出了只支持GTID复制的切换工具mysqlfailover,在GTID的帮助下,我们有更多靠谱的HA工具可以选择。

二、搭建主从复制环境(GTID异步复制)

注意:所有slave上的replicate-ignore-db设置必须相同,MHA在启动时候会检测过滤规则,如果过滤规则不同,MHA不启动监控和故障转移。

在整个复制集群中,这边都开启了GTID,关于GTID请看其他章节。从MHA 0.57开始,就可以支持GTID了。关于MySQL的安装配置,GTID配置等操作可以看MySQL基于GTID的复制实现详解。下面只给出一些复制相关操作。

1)在mysql01上创建复制用户

2)在mysql02上连接mysql01

3)在mysql03上连接mysql01

4)两台slave服务器设置read_only(从库对外提供读服务,只所以没有写进配置文件,是因为随时slave会提升为master)

5)创建监控用户(在master上执行,也就是10.99.73.9)

到这里整个复制集群环境已经搭建完毕,剩下的就是配置MHA软件了。

三、测试MHA

MHA启动配置

对于GTID模式,要注意,如果数据库没有执行过一条事务,那么show slave status中即没有执行过任何Executed_Gtid_Set,MHA会认为是非GTID模式。

另外,对于GTID模式需要配置binlog server。如果不配置,即使在old master SSH可达的情况下,它也不会去save binlog,所以GTID和non-GTID模式的区别比较大。解决的方案就是: 配置Binlog Server。

配置如下:

注意:当主从复制为GTID时,需要设置binlog1,这里的binlog1既可以设置master为binlog server,也可以设置其他专用的binlog server。

检查主从复制状态

启动MHA

启动日志信息

一、测试自动Failover(主要测试new master是补谁的日志)

必须先启动MHA Manager,否则无法自动切换,当然手动切换不需要开启MHA Manager监控。各位童鞋请参考前面启动MHA Manager。

自动failover模拟测试的操作步骤如下。

1)使用sysbench生成测试数据(使用yum快速安装)

在主库(10.99.73.9)上进行sysbench数据生成,在sbtest库下生成sbtest表,共100W记录。

如果是需要产生大量的binlog,使用sysbench模拟压测,持续时间为2分钟,产生大量的binlog。使用如下语句(这里我们不使用):

2)停掉slave io线程(10.99.73.10)

一定要在master执行sysbench结束之前停掉slave io线程,这样我们才可以模拟查看当10.99.73.10成为new master之后是否会同步old master的binlog。

另外一台slave我们没有停止io线程,所以还在继续接收执行日志。

3)停掉slave io线程(10.99.73.11)

你可以一直使用show slave status命令查看当前此slave的状态,只要比10.99.73.10同步的数据多就可以停掉io线程了,但是记住不要把master的数据完全同步完了。

4)杀掉主库MySQL进程,模拟主库发生故障,进行自动failover操作。

PS:可以看出master是100万数据,slave(10.99.73.10)只有86万数据,而slave(10.99.73.11)有90万数据,下面看整个MHA的切换过程。

5)查看MHA切换日志,了解整个切换过程,在10.99.73.7上查看日志。

看到最后如果出现”Master failover to 10.99.73.10(10.99.73.10:3306) completed successfully.”,说明备选master现在已经上位了。并且可以看到两个slave中10.99.73.10成为了new master,而10.99.73.11成为了10.99.73.10的slave。这主要是因为我们刻意把10.99.73.11设置为了no_master,就是不参与选举。如果没有设置no_master的话,那么MHA在进行选择时会根据数据最接近于master的slave。

从上面的输出可以看出整个MHA的切换过程,共包括以下的步骤:

1. 配置文件检查阶段,这个阶段会检查整个集群配置文件配置。

2. 宕机的master处理,这个阶段包括虚拟ip摘除操作,主机关机操作(待研究)。

3. 复制dead maste和最新slave相差的relay log,并保存到MHA Manger具体的目录下。

4. 识别含有最新更新的slave。

5. 应用从binlog服务器保存的二进制日志事件(binlog events)。

6. 提升一个slave为新的master进行复制。

7. 使其他的slave连接新的master进行复制。

6)验证new master(10.99.73.10)

由此结果可以看出new master跟old master的数据一致,说明mha是根据old master来补齐new master的差异数据的。

7)切换发送邮件

最后补充一下邮件发送脚本send_report ,这个脚本在询问一位朋友后可以使用,如下:

切换后报警信息如下:

MySQL基于MHA高可用部署篇(GTID模式)

二、手动Failover(MHA Manager必须没有运行)

首先搞一个干净的mysql复制集群加mha监控(在mha监控端不需要开启mha manager)。手动failover,这种场景意味着在业务上没有启用MHA自动切换功能,当主服务器故障时,人工手动调用MHA来进行故障切换操作,具体命令如下:

注意:如果,MHA manager检测到没有dead的server,将报错,并结束failover:

进行手动切换命令如下,但是在切换之前我们需要模拟一下slave延迟,然后让切换脚本自动补全relay log。

在主库(10.99.73.9)上进行sysbench数据生成,在sbtest库下生成sbtest表,共100W记录。

主库写入一些数据后,就可以关闭10.99.73.10的io_thread。

然后就可以关闭10.99.73.9的io_thread,但是要保证10.99.73.9主机的数据比10.99.73.10数据多,但是比10.99.73.9的数据小。

然后等主库压测完事之后查看一下主库状态就关闭mysql进程。

然后就可以在mha主机上进行手动切换了,由于要指定特定的slave为候选master,而此slave还落后非常多,可以在每组服务器上都加上check_repl_delay=0表示忽略复制延迟,不然整个恢复过程会加长。如下配置:

手动切换:

会输出整个切换过程以及会询问你是否进行切换,成功后信息如下:

上述模拟了master宕机的情况下手动把10.99.73.10提升为主库的操作过程。

查看一下10.99.73.10主机状态。

可以看到10.99.73.10切换为主后,自动补全了old master所有的差异日志。

masterha_master_switch命令参数介绍

--master_state=dead

这个value可能的取值是:‘dead’or‘alive’。如果设置为alive,就是在线master切换了,这样的场景,master必须是活着的。

--dead_master_host=(hostname)

Dead master的主机信息,包括–dead_master_ip,–dead_master_port。

--new_master_host=(hostname)

New master的主机信息,这个参数是可选项,如果你想特意指定某台机器作为new master,就设置这个参数。如果new_master_host没有设置,那么选举master的规则参考automated master failover( candidate_master parameter )。

--interactive=(0|1)

交互式failover,设置为1(默认)。非交互式failover,设置为0。

--skip_change_master(0.56)

只会完成日志补偿,不会进行change master和start slave。如果你想double check slave是否成功的恢复完成,那么设置该参数对你特别有用。

--skip_disable_read_only

如果设置了这个参数,那么新master将还会是只读状态。如果你想手动开启新master的写权限,那么这个参数特别有用。

--last_failover_minute=(minutes)

同masterha_manager里面的参数一样 。

--ignore_last_failover

同masterha_manager里面的参数一样 。

--wait_on_failover_error=(seconds)

同masterha_manager里面的参数一样。这个参数,只对自动或者非交互式的failover有用,如果–interactive=0没有设置,那么这个参数将不起作用。

--remove_dead_master_conf

同masterha_manager里面的参数一样。

--wait_until_gtid_in_sync=(0|1)

这是基于GTID的参数,如果设置为1(默认): MHA会等待,直到所有slave追上新master的gtid。如果设置为0: 那么MHA不会等待slave追上新master。

--ignore_binlog_server_error

MHA忽略任何binlog server的错误。

三、在线进行切换

在许多情况下,需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障,RAID 控制卡需要重建,将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降, 导致停机时间至少无法写入数据。 另外, 阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。 MHA 提供快速切换和优雅的阻塞写入,这个切换过程只需要 0.5-2s 的时间,这段时间内数据是无法写入的。在很多情况下,0.5-2s 的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口。

MHA在线切换的大概过程:

1)检测复制设置和确定当前主服务器。

2)确定新的主服务器。

3)阻塞写入到当前主服务器。

4)等待所有从服务器赶上复制。

5)授予写入到新的主服务器。

6)重新设置从服务器。

注意,在线切换的时候应用架构需要考虑以下两个问题:

1)自动识别master和slave的问题(master的机器可能会切换),如果采用了vip的方式,基本可以解决这个问题。

2)负载均衡的问题(可以定义大概的读写比例,每台机器可承担的负载比例,当有机器离开集群时,需要考虑这个问题)

为了保证数据完全一致性,在最快的时间内完成切换,MHA的在线切换必须满足以下条件才会切换成功,否则会切换失败。

1)所有slave的IO线程都在运行。

2)所有slave的SQL线程都在运行。

3)所有的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒,如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。

4)在master端,通过show processlist输出,没有一个更新花费的时间大于running_updates_limit秒。

在线切换步骤如下:

首先,停掉MHA监控:

注意:由于在线进行切换需要调用到master_ip_online_change这个脚本,但是由于该脚本不完整,需要自己进行相应的修改,我google到后发现还是有问题,脚本中new_master_password这个变量获取不到,导致在线切换失败,所以进行了相关的硬编码,直接把mysql的mha用户密码赋值给变量new_master_password,如果有哪位大牛知道原因,请指点指点。这个脚本还可以管理vip。下面贴出脚本:

然后可以在主库(10.99.73.9)上进行sysbench数据生成,在sbtest库下生成sbtest表,共100W记录。

有条件的可以在压测时连接数据指定VIP地址,把socket去掉,添加–mysql-host=10.99.73.100,这就样可以模拟应用在线切换(一边压测一边切换)。

等主库一压测完后。就可以进行在线切换操作(模拟在线切换主库操作,原主库10.99.73.9变为slave,10.99.73.10提升为新的主库)。

其中参数的意思:

--orig_master_is_new_slave

切换时加上此参数是将原master变为slave节点,如果不加此参数,原来的master将不启动。

--running_updates_limit=10000

故障切换时,候选master如果有延迟的话, mha切换不能成功,加上此参数表示延迟在此时间范围内都可切换(单位为s),但是切换的时间长短是由recover时relay日志的大小决定。

最后查看日志,了解切换过程,最后输出信息如下:

查看10.99.73.10主机切换为master了。

PS:online切换主从状态必须正常,切换后old maser会变成slave,且为read_only模式。

四、修复宕机的Master

通常情况下自动切换以后,原master可能已经废弃掉,待原master主机修复后,如果数据完整的情况下,可能想把原来master重新作为新主库的slave,这时我们可以借助当时自动切换时刻的MHA日志来完成对原master的修复。下面是提取相关日志的命令:

获取上述信息以后,就可以直接在修复后的master上执行change master to相关操作,重新作为从库了。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (5)or分享 (0)
关于作者:

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