本次分享主要包括以下几方面：

1. 以前几十台DB服务器，人工登陆服务器就能维护好，也没有高可用，当master挂了，通知业务将IP切换到slave然后重启也能基本满足业务要求，但是业务迅速发展，实例数不断增加，复制集不断增加，数据库架构多样化，而这种人工维护方式显然大大增加了DBA工作量，而且效率低下、容易出错。

    

2. DB规模的增大，机器故障、SQL故障、实例故障出现的概率也增加、还有来自业务方的DB变更，比如大表增加字段、增加索引、批量删除数据等异常维护操作，当然这些在一定条件下可用采用在线变更，比如采用pt-online-schema-change工具，但是当不满足在线变更条件、或者在线变更复杂的情况下，就需要采用滚动变更的方式，先在各个slave上变更、在线切换后再在master上变更，然后再进行一次切换还原，而这些切换操作如果全部手工敲命令来进行显然是不可取的。

    

3. 随着用户数的不断增加，业务方对DB这种基础服务的可用性也就越来越高，在魅族业务对DB的可用性要求是每个月需要达到四个9，也就意味着每个月的故障时间只有不到5分钟，以前那种通知业务更改IP重启的方式显然是达不到这个要求的。

在这些背景和要求下，我们需要摆脱手工操作，需要一套有效的MySQL高可用方案和一个高效的高可用平台来支撑DB的快速增长。MySQL高可用平台需要达到的目标有以下几点：

如上图所示，通过测试比较几个候选方案，最终我们选择采用MHA作为线上MySQL高可用方案,主要基于如下几点：

而这些特点中，支持调用外部脚本接口和在线切换尤为重要，当然perl编写，二次开发相对容易，可以根据自己业务需求适当的增加功能也不是难事。

DB高可用其实可以分为两部分：DB访问方式控制、数据一致性保证，访问方式控制用于确保DB的服务可用性，而数据一致性则决定DB服务的数据可用性，两者是紧密结合在一起的，而高可用设计也是围绕这两点展开。

一般来说，当DB发生故障时，业务方是不希望通过调整DB连接地址来进行故障切换的，调整DB连接一般都会涉及到业务重启，如果说业务机器数据较多，重启时间则会较长，必然会增加业务的异常时间，也就意味着在业务中配置的DB地址是一个固定的连接，而DB的故障切换要做到对业务透明，无需重启，后端的DB恢复业务能够自动重连即可。通常来说，要对业务透明，像域名、vip、Zookeeper、Proxy这些访问方式都能做到，在魅族这边，业务的访问DB的方式有两种，分别是vip和自研的MySQL Proxy。但是不管是vip也好还是MySQL Proxy也好，对于一个业务来说都是指定了一个固定地址，这个地址一般来说都会一直伴随着这个业务，而高可用系统只要维护这个地址和后端的真实DB的映射关系就可以。

vip访问访问方式架构如下：

vip是在master机器上额外增加一个虚拟IP,而且这个IP是可以在master和standby之间漂移的，主要适用的场景是单机单实例，业务直连DB，切换是以机器为单位进行切换，但是需要master、standby在同一个网段。

MySQL Proxy访问方式架构如下：

MySQL Proxy的方式是在业务和DB之间增加一层中间件，业务连接的是中间件，而不直连后端真实DB，适用的场景为单机多实例，而且master，standby可以不在同一个网段，切换是以实例为单位进行。

在单机多实例下为何不采用vip呢，单机多实例下当一个机器上的一个实例发生故障，而其他实例是正常的，如果采用vip的话，这时候vip是漂移呢还是不漂移？如果漂移，那么其他正常的实例也会有短暂的影响，如果不漂移，那么该异常实例对应的业务异常时间就会增加，而且当该机器上其他实例的standby分布在不同机器上时，vip是无法漂移的。因此在单机多实例部署下采用Proxy，业务连接的是Proxy，而不是DB，而且业务也不需要知道是单机多实例还是单机单实例，而我们只需要维护Proxy和后端真实实例的映射关系即可。

我们知道MHA本身是不做业务访问方式控制的，MHA只负责master存活检测、选择new master、差异数据补齐，slave自动同步到new master，也就是尽可能做到数据一致性保证。因此我们需要找一个有效管理控制访问方式的方案来和MHA结合，使之同时满足高可用的两部分：DB访问方式控制、数据一致性保证。

如何控制要访问方式，对于vip访问方式来说，可以采用keeepalive来控制其漂移，当master异常，keepalive会自动将vip漂移到standby，但是这个方案在实际使用中会存在如下问题：

既然keepalive不合适，那采用何种方案来控制业务访问DB方式呢，我们知道MHA在切换流程中提供了一个调用外部脚本的接口，当切换流程进行到指定步骤后，可以调用一个外部的脚本，至于外部脚本用于做什么事，MHA是不关注的，只关注调用的返回值，脚本逻辑完全自定义，因此我们可以在脚本中加入MHA本身无法满足的一些逻辑，比如这里说的控制业务访问方式等。也正是因为这个特点我们采用自定义外部脚本来控制业务访问方式，这种方式有如下优点：

但是采用外部脚本来控制访问方式又会带来另外一个问题：根据MHA的配置，外部脚本由master_ip_failover_script和master_ip_online_change_script参数决定，一个用于自动切换，一个用于手动切换，而每个复制集的访问方式不管是vip还是mysql proxy都是固定的，因此就需要在脚本中指定该固定的访问信息，当MySQL复制集很多的情况下，每个复制集一个访问方式控制脚本，这就导致这种访问方式控制脚本很多，如果需要变更逻辑或者增加逻辑都需要变更所有的脚本，管理维护起来很不方便，而且很容了遗留和出错，但是我们不难发现，实际上这些脚本中除了每个业务配置的访问方式不同，其他逻辑都是一样的。既然这样，那我们是否可以将访问方式和MHA实例的配置绑定，将每个业务对应的访问地址写入到MHA实例的配置文件中，再将其控制逻辑剥离出来统一到一个脚本，调用的时候将该访问地址传递给该脚本使用即可。因此我们的解决方案如下：

 那外部脚本在MHA切换流程的哪一步调用呢，这里以自动切换为例（手动切换一样），如下图所示：

切换流程可以简单归结为五步：

 在整个切换流程中，会有两处调用到外部脚本，对这两个接口都需要增加app_vip参数，每次调用需要将app_vip参数传入到外部脚本。

具体实现比较简单，能看懂perl语法的话问题都不大，MHA参数都在Config.pm中定义，在参数列表PARAM_ARRAY中增加app_vip，然后在后面初始化即可，如下图所示：

然后还需要将app_vip这个参数添加到MHA调用外部脚本的接口中，这里涉及到MHA自动切换、手动切换和启动阶段，这三部分功能分别位于MasterFailover.pm、MasterMonitor.pm和MasterMonitor.pm中，这里以自动切换MasterFailover.pm中代码为例，在自动切换过程中，会有两个地方存在调用外部脚本，Phase 2: Dead Master Shutdown Phase..和Phase 3.4: Master Log Apply Phase.对于Phase 2: Dead Master Shutdown Phase..接口在force_shutdown_internal函数中定义，对于Phase 3.4: Master Log Apply Phase. 只需要在recover_master 函数中做接口调整。

简单如下图：

现在看看外部脚本如何实现，至于采用什么语言实现都可以，只需要实现满足调用接口即可，具体的接口参数可以参考MHA源码中的示例代码，我们采用python完成。由于我们这里访问方式有两种，而两种访问方式完全不同，因此对于两种访问方式的控制逻辑也完全不同，vip的控制逻辑比较好理解，app_vip参数配置的是一个具体的vip。master异常包括两种情况，如果是实例异常，则将vip在master机器摘下，确保失效后，绑定到standby即可，如果是机器宕机，则vip会自动实效。

而对于MySQL Proxy就稍微复杂一些，app_vip参数配置的是一个zookeeper节点，每个复制集在Zookeeper上有一个唯一的节点，Proxy和后端MySQL实例的映射关系是在Zookeeper上维护的。当master异常，更改Zookeeper上proxy和后端master的映射关系后，会自动通知到MySQL Proxy，Proxy再将转发打到新的master，采用MHA后，这个映射关系由外部脚本来控制。

外部脚本中实现了两套控制逻辑，根据传入的参数是虚拟IP还是zookeeper节点来选择具体的控制逻辑，而每个控制逻辑对应三个command状态：status、stop or stopssh、start.

• status只在MHA启动的时候调用，从MHA的代码来看，作用是测试该外部脚本是否有效，而我们可以用于检测该app_vip是否是正常状态，绑定关系是否正常，这里主要检查app_vip和master的关系映射是否正常。

• stop or stopssh在MHA切换流程中调用，确保app_vip是失效状态，业务不可写入，这一步在手动切换中更有效，在自动切换中，master发生故障已经不可写入了，这里只是再多check一次而已。

• start 在MHA切换流程中调用，将app_vip和MHA选择的new master绑定，这一步执行完之后，确保app_vip是正常访问状态，业务新的请求全部打到new master。

这里为何要确保app_vip是失效状态或者是正常状态，这个Proxy的实现机制有关，对于MySQL Proxy来说，脚本操作的是Zookeeper节点，而MySQL Proxy收到通知再到变更会有一个短暂的时间差，理论上是非常快的。对于手动操作来说，这里简化一下切换流程如下：先调用外部脚本stop操作，再执行FLUSH TABLES WITH READ LOCK操作，再将standby切换为master，再调用外部脚本的start操作，然后执行master上的UNLOCK TABLES操作，如果Zookeeper和MySQL Proxy之前的网络出现波动就会导致MySQL Proxy收到通知延时，在master上执行UNLOCK TABLES操作后，而此时MySQL Proxy的转发还是在原来的master，而此时切换已经完成，有部分数据业务方写入了，而实际上是丢失了，因为写入是slave角色（原来的master目前是slave），而业务显示是写入是正常的。

为了避免这种情况出现，就需要在每一步调用后，确保app_vip参数是否满足预期状态，对于MySQL Proxy来说，就要确保后端的master和Proxy的映射关系是否正常，而不仅仅是更改了Zookeeper信息就可以。对于vip访问方式来说，绑定操作如下：ip addr add xxx/32 dev xxx,摘除操作如下：ip addr del xxx。将vip绑定到新的master机器，通常要验证本网段之外的其他网段访问该vip是否正常，通过情况下，只是简单的将vip 绑定到new master，其他网段在短时间内是不通的，为了使vip能够迅速生效，需要做一次arping操作，否则对于其他网段访问，会有一定的生效延时。

前面是访问方式控制上实现，再来看看我们在其他两个点上的改动。

• 第一：对于每一个复制集来说，只能是master可以写入，而slave全部要确保是read only = ON，以避免业务配置错误将数据写入到slave。MHA在启动的时候会检测一次各个slave是否设置了read only=ON,对于read only = OFF的实例只是warning提示一下，并不会去强制设置read only=ON。在这里我们增加一个步骤，当检测到slave为read only = OFF的，就将该实例设置为read only=ON，但是设置read only=ON对于线上已经运行的实例来说可能会导致堵塞，从而导致MHA实例启动堵塞，当该实例有长事务执（比如大表逻辑备份操作）的时候，执行set global read_only=ON就会导致堵塞，需要等待长事务执行完成，而且进而导致slave上sql thread堵塞，从而导致slave复制延时。为了避免这种情况，因此在为该实例设置read only之前，先检测该slave实例上是否有长事务在执行，如果有则跳过read only=ON的设置，先优先启动MHA实例。而对于这些没设置read only=ON的实例，会额外增加一个任务来定时检测，检测线上每一个slave是否设置了read only=ON,没有则设置上。这样可以在很大程度上避免因为业务配置错误导致slave产生写入从而导致主从数据不一致的情况出现。

• 第二：master检测失败次数加大，MHA默认的失败检测次数是3次，当连续三次检测master异常，则开始判断是否需要发起切换，而我们设置的检测间隔是1s，也就意味着3s时间内master不通，则会判断是否发起切换，3s时间太短，很容易因为网络波动等原因导致master误切换，因此我们将失败检测次数提高到10次。而且为了避免MHA管理机和master网段之间不通导致的切换，我们还增加了一个外部脚本secondary_check_script，发起切换检测前，该脚本会从其他多个网段来检测是否和master都无法连通了来确定master是否真正需要切换，上面两点也是为了最大程度避免误切带来的业务异常。

当线上只有一套或者几套复制环境时，即使手工操作就可以运维下来，但是当线上复制环境有几百套，而且架构多样，跨多个机房的时候，再用手动部署和运维就显得很费时费力，容易出错而且效率很低。目前我们这边的DB现状如下：

而我们面临的问题如下：

拿部署一套MHA来说，需要完成下图中的所有流程：

而且必须保证每一个流程都是正确的，通常人工部署会遇到如下问题：

而且部署每套MHA涉及的操作也是类似的，也就说明DBA在这些工作上都是重复耗时的，而这些流程基本已经固定了，每次部署按部就班即可。因此我们可以将这些流程自动化，让整个部署操作自动完成，以给一套一主三从复制集部署高可用耗时来计算至少可以节约DBA 80%的时间。因此我们迫切需要一个MHA管理平台来帮助解决我们所遇到的问题，MHA管理平台设计的主要的功能点如下：

这些功能点基本涵盖了DBA在MHA上的运维操作，通过将这些运维操作平台、自动化，以最大程度的较少DBA运维时间、提高运维效率和减少运维误操作。

MHA管理平台整体架构如下：

MHA管理平台直接操作的是MHA manager，实际使用中会存在多个MHA manager，当然在部署的时候也会操作到MHA node，对于MHA node来说，MHA manager是服务端，而对于MHA管理平台来说，就是客户端。每个MHA manager可以管理多套MHA实例，我们预设的数量是50，每个MHA manager最多管理50个MHA实例，也就是50套复制集。

MHA管理平台还需要和RDS平台打通，作为RDS的高可用子模块，RDS的高可用需要依赖MHA管理平台，在一定条件下，两者的信息是相互调用的。MHA管理平台和告警平台相连主要是为了告警信息的处理。对于一套复制环境中实例跨多个机房的情况，我们选择master所在机房的MHA manager做为管理节点，而且standby也必须在同一个机房，正常情况下，master只会在同机房进行切换，而对于复制环境需要跨机房容灾也是支持的，这就需要在两个机房先将MHA配置在MHA manager上同步好，确保在两个机房的MHA manager上都能完全操作该MHA实例，不过跨机房切换中需要考虑的因素太多，目前只支持手动切换，尚不支持自动切换，这一点在后续需要进一步完善。

下面介绍几个平台中的主要操作页面，这是MHA部署的页面：

相比于手工操作要登录每台机器，这里只需要填写很小一下信息提交即可，信息验证通过之后，会以任务的形式在后台部署。具体包括如下工作：MHA信息，MySQL实例信息入库，ssh信任连接建立，配置文件生成，选择mha manager，复制状态检查，MHA启动。对于机房的选择和前面说的一样，选择和master实例在同一个机房，访问方式有两种：vip和MySQL Proxy，而我们目前都在往RDS上迁移，因此从RDS上请求过来的部署都是选择MySQL Proxy,而vip目前只是用来满足原有的单机单实例业务进行扩容，对于新业务来说不再提供vip的方式接入，全部采用RDS实例。

我们线上的实例版本主要有两个：5.5.9和5.7.13，5.5.9下我们全部采用MHA 0.54版本，而5.7.13 则采用MHA 0.56版本，在0.56版本支持GTID和table方式存放relay 信息，而在MHA 0.54下会出现异常。这里只需要选择MySQL版本即可后台会根据版本自动根据MHA版本来选择MHA manager。该页面主要是为了兼容vip的部署方式，而对于MySQL Proxy的方式，都是从RDS平台进行调用该页面对应的接口即可,在RDS上申请一套RDS实例是会自动包含高可用的，不需要额外的部署高可用。

MHA列表页：

该页面显示每个MHA管理节点，以及该MHA manager节点下管理的MHA实例列表，可以列出该mha manager管理下的所有MHA实例信息，包括集群名，MHA进程信息，运行状态（运行中、已停止、部署中、正在切换等）

MHA实例详情页：

该页面显示指定的MHA实例详情，包括MHA实例所在的MHA管理节点，复制集名称，访问类型，MHA运行状态，该MHA实例下的所有MySQL实例是否正常，slave状态是都正常等等。而对于MHA的所有日常运维操作也全部在这个页面完成，比如：启停MHA实例，增减slave，slave信息变更，在线切换、复制检查，ssh检查等操作。所有的这些操作都需要有对应的接口，主要提供给RDS平台调用，而这些功能在RDS平台的逻辑单元管理下面都有对应的操作，也就不用两个平台来回切换使用，该页面主要为了兼容非RDS上的实例。

在线切换操作是远程调用masterha_master_switch来完成的，为了保证切换的顺利进行，采用非交互的方式进行interactive=0，而且在切换前做前置条件检查，这里主要是复制延时检查，ssh互通检查，master长事务检查，只有满足在线切换前提才发起在线切换操作。在线操作默认的日志输出是在屏幕，这对于远程调用而言，为了便于定位问题需要将日志保存，保存在指定的workdir目录下。这里的代码调整比增加app_vip参数稍微复杂一点，但是可以参考自动切换的流程来进行调整。原来的流程是在identify_orig_master（）函数中拿到所有的实例信息，并选择出orig_master，在这里我们增加一个函数init_config（）用于获取所有的实例信息，并且初始化日志信息，返回值为所有的实例信息，然后将返回值传递给identify_orig_master()函数，而在identify_orig_master（）函数中去掉获取实例信息的代码。这样就能确保原有的逻辑不变而且增加了日志记录功能，在线切换日志需要和自动切换日志区分开来，增加一个switch_online后缀即可。

为何要做MHA状态监控和MySQL角色同步？随着大规模的部署，在运维过程中就会遇到各种各样的问题，主要问题如下：

而这其中有不少问题是会直接影响到高可用或者数据一致性的，比如MHA进程异常退出了而没有告警，DBA也一直不知道，而到了master异常，才发现没有切换，再一查才发现MHA进程早就停止了。有时候master发生了切换，但是MySQL角色在RDS平台上没有同步更新，这就导致RDS上数据和实际的角色不一致。还有因为某些原因将一个slave下线了，数据也清理了，但是没有在MHA配置中同步，从而导致当MHA发生切换时连接该实例发生异常导致整个切换流程失败。还有在一个复制环境下，增加一个slave，或者slave信息变更没有同步到MHA配置中，发生切换后导致该实例的复制异常，等等以上原因都会影响到业务的可用性。

此外切换进度不透明，我们只知道发起了切换，但是不通过看日志的话，切换进行到哪一步了根本不知道，无法做到完全可控。为了最大程度的避免上述问题，就需要提前发现和处理掉这些问题，对于异常情况及时告警，对于上述出现的问题，针对每一项做针对性的跟踪和监控，有些只需要告警即可，而有些需要根据场景做特定的处理。我们的解决方案如下：

MHA状态如何跟踪？我们首先看一下MHA实例的生命周期，如下图所示：

这里从MHA实例启动开始，先做启动初始化，主要是配置检查，包括复制检查，ssh检查等等，有异常则直接退出，启动失败，正常则启动成功，此时MHA状态为PING_OK，然后开始对master进行ping监控，注意这里是没有对slave做监控的。当master异常时，ping失败，这里MHA的状态为PING_FAILING，然后连续ping master，当失败次数大于10次后，MHA的状态为PING_FAILED，这时候会再做一次master check，确认master是否已经dead，如果此时是alive状态，MHA的状态为RETRYING_MONITOR，重新对master进行ping监控，如果此时确实是dead状态，则发起切换流程，此时MHA的状态为FAILOVER_RUNNING，切换流程之前已经说过大致可以分为五步，如果切换过程中发生异常，MHA的状态为FAILOVER_ERROR，生成切换失败文件，以failover.error为后缀，如果切换正常完成，则生成一个failover.complete后缀的文件。这些状态码在ManagerConst.pm中已经定义好，如下图所示：

而我们则可以根据这些状态来判断MHA的具体的运行状态，我们只需要将这些状态码上报到MHA管理平台，在服务端做针对性处理即可。除了这些MHA定义的状态之外，为了更准确的跟踪MHA切换流程，还需要在在状态为FAILOVER_RUNNING的五步中，定义更细致的子状态用于跟踪切换流程的具体进度，以便于根据切换流程。定义了状态码之后，就需要在MHA切换逻辑中增加这些状态码上报的逻辑，具体实现如下：

此外我们针对性的做了MHA配置一致性监控，为何要做MHA配置一致性监控? 前面也提到了几点：增减slave实例没有同步到MHA配置中，slave信息变更没有同步到MHA配置中，因为某些原因切换时发先ssh信任关系是失败的，这些因素要么导致MHA切换失败，要么导致MHA发生切换后有slave数据和新的master数据不一致而且复制关系异常，不管是哪一种结果，对于业务来说都是不可接受的，因此我们需要提前发现这些问题。增加如下任务：

做这些操作是为了尽可能多角度的监控MHA实例状态，以确保master异常时，MHA切换流程能正常的完成，而不是等到切换开始后才发现切换流程无法完成。

增加了监控还需要做告警处理，告警处理主要分为两种：短信和邮件，对于需要DBA干预的，尽可能快速的通过短信方式同步到DBA侧，对于只需要DBA知会的，只做邮件通知即可，具体的告警场景如下所示：

这其中需要说明的是，当切换开始后，会上报切换开始的状态码，这时候需要在指定的时间内判断是否接收到切换完成或者切换失败的状态码，用于判定切换是否失败或者正常完成，避免在某些情况下，切换流程hold住导致切换流程长时间无法完成,从而影响DB服务时间。

对于vip可用性、mysql proxy可用性的告警，是做了一个额外的任务来完成，定时检测所有的vip或者proxy的可用性并根据结果做告警处理。这里的告警看似很多，但是很多都是很有必要的，我们应该尽可能多的将MHA的状态及时的同步到DBA侧，以便于在出现异常情况时，DBA更加及时的进行干预和处理。

目前该平台已经运行了大半年时间，运行稳定，不过还存在有待完善地方，有如下几点：

Q1：这个只有故障切换功能，没有负载均衡，读写分离？

A1：有的，MySQL  Proxy架构下面只有挂载了读的slave，就会将select转发过去的，如果没有slave（不是standby）则全部请求master。而对于vip的方式，扩展读用的是LVS。

Q2：是否有遇到在高并发下，切换有时会失败？

A2：失败没遇到过，如果是在线切换的话，时间会延长不少。
 

Q3：魅族自研的MySQL Proxy，是中心式结构，像mycat。还是分布式结构，像TDDL。最大集群的分片是多少？

A3：都不是的，MySQL  Proxy目前的功能只是处理转发，起到一个过载保护的作用，我们在Proxy上可以做一些统计以及审计的工作。分片我们这边是业务自己做的，最大分片集群的有70多组。

Q4：对于主从同步失败造成的主从不一致如何检测和修复？

A4：这种不一致，我们会定时的采用pt工具去check一次。如果数据不一致情况严重，会选择重做。

Q5：MySQL proxy做负载均衡的话，是按BATCH请求，还是按数据库connection连接来做的？

A5：connection连接来做的。

Q6：老师您好！我这在使用MySQL  数据库遇到一些问题，还望各位老师能给些意见。背景如下：MySQL  是 1主3从，每台机器一个数据库4个实例，总共16台机器，前4台是主库，后12台是从库，但数据插入到主库，往从库同步时特别慢，1900万数据几个小时还没有同步完，后台只有一个线程在同步，单核cpu达到100%，我们的48核cpu根本没用上。

A6：如果是5.5版本的话，复制是单线程的，主库写入很大的情况下，从库需要一定的时间才能追上。从库在复制上是用不到多核的。如果有多个数据库的话，可以采用5.6版本或者5.7版本。复制性能会好不少。

Q7：老师，我们使用的5.7.16的版本。我们同步的一张大表的数据，整个库中也就几张大表。

A7：如果是一张表的话，性能不会有多大改善，建议做大表拆分。

Q8：请问该系统的自动化运维如何实现的？

A8：django + celery + fabric。

Q9：如何有效管理版本升级及补丁发布？

A9：对于MySQL Proxy而言有专门的版本管理和发布平台，对于MHA版本来说，目前有0.54和0.56,都是基于这两个版本来改的。

Q10：备份如何实施的？

A10：针对MySQL备份开发了备份恢复的模块，目前采用的分布式的全量备份，副本保存30天，目前也在开发基于binlog的增量备份。

Q11：如何和CMDB结合应急处理的？

A11：每个复制集所对应的业务都是从CMDB中获取的。