原创

MySQL基于MHA高可用理论篇

MySQL高可用系统

MySQL高可用,顾名思义就是当MySQL主机或服务发生任何故障时能够立马有其他主机顶替其工作,并且最低要求是要保证数据一致性。因此,对于一个MySQL高可用系统需要达到的目标有以下几点:

(1)、数据一致性保证这个是最基本的同时也是前提,如果主备的数据不一致,那么切换就无法进行,当然这里的一致性也是一个相对的,但是要做到最终一致性。

(2)、故障快速切换,当master故障时这里可以是机器故障或者是实例故障,要确保业务能在最短时间切换到备用节点,使得业务受影响时间最短。

(3)、简化日常维护,通过高可用平台来自动完成高可用的部署、维护、监控等任务,能够最大程度的解放DBA手动操作,提高日常运维效率。

(4)、统一管理,当复制集很多的情况下,能够统一管理高可用实例信息、监控信息、切换信息等。

(5)、高可用的部署要对现有的数据库架构无影响,如果因为部署高可用,需要更改或者调整数据库架构则会导致成本增加。

目前MySQL高可用方案可以一定程度上实现数据库的高可用,比如MMM,heartbeat+drbd,NDB Cluster等。还有MariaDB的Galera Cluster,以及MySQL 5.7.17 Group Replication等。这些高可用软件各有优劣。在进行高可用方案选择时,主要是看业务对数据一致性方面的要求。最后出于对数据库的高可用和高可靠的要求,目前推荐使用MHA架构,因为MySQL GP还不能在生产使用,但是相信以后慢慢就会被用到生产环境的。

MHA技术介绍

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。除了failover之外,MHA还支持在线master切换,非常安全和高效,大概只需要(0.5 ~ 2秒)的阻塞写时间。

该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当slave。当然,如果你处于成本考虑,也可以使用两个节点的MHA,一主一从(实测过的)。

总结一下,MHA提供了如下功能:

(1)master自动监控,故障转移一体化(Automated master monitoring and failover)

(2)MHA可以在一个复制组中监控master的状态,如果挂了,就可以自动的做failover。

(3)MHA通过所有slave的差异relay-log来保证数据的一致性。

(4)MHA在做故障转移,日志补偿这些动作的时候,通常只需要10~30秒。

(5)通常情况下,MHA会选择最新的slave作为new master,但是你也可以指定哪些是候选maser,那么新master选举的时候,就从这些host里面挑。

(6)导致复制环境中断的一致性问题,在MHA中是不会发生的,请放心使用。

在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MySQL 5.5及以上版本的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。

(7)手工-交互式master故障转移(Interactive manually initiated Master Failover)

MHA可以配置成手工-交互式方式进行故障转移,不支持监控master的状态。

(8)非交互式master故障转移 (Non-interactive master failover)

非交互式,自动的故障转移,不提供监控master状态功能,监控可以交给其他组件做(如:Pacemaker heartbeat)。

(9)在线master切换 (Online switching master to a different host)

如果你有更快,更好的master,计划要将老master替换成新的master,那么这个功能特别适合这样的场景。

这不是master真的挂掉了,只是我们有很多需求要进行master例行维护。

MHA的优点

1. master failover和slave promotion非常快速。

2. 自动探测,多重检测,切换过程中支持调用其他脚本的接口。

3. master crash不会导致数据不一致,自动补齐数据,维护数据一致性。

4. 不需要修改复制的任何设置,简单易部署,对现有架构无影响。

5. 不需要增加很多额外的机器来部署MHA,支持多实例集中管理。

6. 没有任何性能影响。

7. 支持在线切换。

8. 跨存储引擎,支持任何引擎。

官方介绍:https://code.google.com/p/mysql-master-ha

MHA工作流程

下图展示了如何通过MHA Manager管理多组主从复制,可以将MHA工作原理总结为如下:

1、MHA如何监控master和故障转移?

1.1 验证复制设置以及确认当前master状态

连接所有hosts,MHA自动来确认当前master是哪个,配置文件中无需指定哪个是master。

如果其中有任何一个slave挂了,脚本立即退出,停止监控。

如果有一些必要的脚本没有在MHA Node节点安装,那么MHA在这个阶段终止,且停止监控。

1.2 监控master

监控master,直到master挂了。

这个阶段,MHA不会监控slave,Stopping/Restarting/Adding/Removing操作在slave上,不会影响当前的MHA监控进程。当你添加或者删除slave的时候,请更新好配置文件,最好重启MHA。

1.3 检测master是否失败

如果MHA Manger三次间隔时间都没办法连接master server,就会进入这个阶段。

如果你设置了secondary_check_script ,那么MHA会调用脚本做二次检测来判断master是否是真的挂了。

接下来的步骤,就是masterha_master_switch的工作流程了。

1.4 再次验证slave的配置

如果发现任何不合法的复制配置(有些slave的master不是同一个),那么MHA会停止监控,且报错。可以设置ignore_fail忽略。

这一步是处于安全考虑,很有可能,复制的配置文件已经被改掉了,所以double check是比较推荐的做法。

检查最后一次failover(故障转移)的状态

如果上一次的failover报错,或者上一次的failover结束的太近(默认3天),MHA停止监控,停止failover,那么在masterha_manager命令中设置ignore_last_failover,wait_on_failover_error来改变这一检测。这么做,也是出于安全考虑。频繁的failover,检查下是否网络出问题,或者其他错误呢?

1.5 关掉失败的master的服务器(可选)

如果在配置文件中定义了master_ip_failover_script and/or shutdown_script ,MHA会调用这些的脚本。

关闭dead master,避免脑裂(值得商榷)。

1.6 恢复一台新master

从crashed master服务器上保存binlog到Manager(如果可以的话

如果dead master可以SSH的话,拷贝binary logs从最新的slave上的end_log_pos(Read_Master_Log_Pos)位置开始拷贝。

选举新master

一般根据配置文件的设置来决定选举谁,如果想设置一些候选master,设置candidate_master=1;如果想设置一些host,永远都不会选举,设置no_master=1;确认最新的slave (这台slave拥有最新的relay-log)。

恢复和提升新master

根据老master binlog生成差异日志,应用日志到new master,如果这一步发生错误(如:duplicate key error),MHA停止恢复,并且其余的slave也停止恢复。

2)MHA如何在线快速切换master?

下面的步骤,就是masterha_master_switch—master_state=alive做的事情。

2.1 验证复制设置以及确认当前master状态

连接配置文件中列出的所有hosts,MHA自动来确认当前master是哪个,配置文件中无需指定哪个是master。

执行 flush tables 命令在master上(可选). 这样可以缩短FLUSH TABLES WITH READ LOCK的时间。

既不监控master,也不会failover。

检查下面的条件是否满足。

A. IO线程是否在所有slave上都是running。

B. SQL线程是否在所有slave上都是running。

C. Seconds_Behind_Master 是否低于2秒(—running_updates_limit=N)。

D. master上是否没有长的更新语句大于2秒。

2.2 确认新master

新master需要设置: –new_master_host参数。

原来的master和新的master必须要有同样的复制过滤条件(binlog-do-db and binlog-ignore-db)。

2.3 当前master停写

如果你在配置中定义了master_ip_online_change_script,MHA会调用它。可以通过设置SET GLOBAL read_only=1来完美的阻止写入。

在老master上执行FLUSH TABLES WITH READ LOCK来阻止所有的写(–skip_lock_all_tables可以忽略这一步)。

2.4 等待其他slave追上当前master,同步无延迟

调用这个函数MASTER_LOG_POS()。

2.5 确保新master可写

执行SHOW MASTER STATUS来确定新master的binary log文件名和position。

如果设置了master_ip_online_change_script,会调用它。可以创建写权限的用户,SET GLOBAL read_only=0。

2.6 让其他slave指向新master

并行执行CHANGE MASTER, START SLAVE。

MHA组件介绍

MHA软件由两部分组成,Manager工具包和Node工具包,具体的说明如下。

Manager工具包主要包括以下几个工具:

(1)masterha_check_ssh    #检查MHA的SSH配置状况;

(2)masterha_check_repl    #检查MySQL复制状况;

(3)masterha_manger    #启动MHA;

(4)masterha_check_status  #检测当前MHA运行状态;

(5)masterha_master_monitor  #检测master是否宕机;

(6)masterha_master_switch    #控制故障转移(自动或者手动);

(7)masterha_conf_host    #添加或删除配置的server信息;

Node工具包(这些工具通常由MHA Manager的脚本触发,无需人为操作)主要包括以下几个工具:

(1)save_binary_logs      #保存和复制master的二进制日志;

(2)apply_diff_relay_logs  #识别差异的中继日志事件并将其差异的事件应用于其他的slave;

(3)purge_relay_logs      #清除中继日志(不会阻塞SQL线程);

注意:为了尽可能的减少主库硬件损坏宕机造成的数据丢失,因此在配置MHA的同时建议配置成MySQL半同步复制。关于半同步复制原理各位自己进行查阅(不是必须)。



作者:张伟科
链接:https://www.jianshu.com/p/dc6c62c50b98
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。
正文到此结束
Loading...