mysql 高可用方案漫谈
引言：
AliCloudDB HA系统是为阿里云 mysql，sqlserver，pgsql 三大数据库提供实例高可用的一整套技术方案，确保系统能够在故障中快速恢复。同时HA 也满足日常运维管理中涉及到主备切换的需求。由于mysql 在业内使用最为广泛，所以本系列先介绍mysql实例高可用的相关技术。
基本架构:
目前使用最为广泛的实例架构是采用一主一备 share-nothing 的结构。数据链路支持RLB + dbnode 与 RLB + proxy + dbnode 两种。为简便起见，本文以proxy 链路，引擎为innodb 的实例为例介绍。
主备同步模式支持半同步，与异步两种方式，强同步在mysql5.7中将被支持。
这里简要介绍下三种同步方式的区别：
异步模式：主库收到commit 请求后，依次执行：写redo log prepare，写入binlog，写redo log commit，返回客户端成功。
半同步模式：主库收到commit 后，依次执行 redo log prepare，写binlog/发往备库(两个步骤并行)，等待备库回复收到ack，redo log commit，给用户回复成功。
强同步模式：主库收到commit 后，依次执行 redo log prepare，写binlog/发往备库（并行），等待备库fsync到磁盘后，redo log commit ，给用户恢复成功。
以上步骤中，写入redo log 步骤受参数innodb_flush_log_at_trx_commit 影响。 分为0，1，2三种设置，具体含义这里不再赘述。写入binlog 步骤受 sync_binlog 参数影响，具体数字含义，也不再赘述。在两个参数双1 条件下，数据最为安全可靠，性能略有下降。本文假设我们都是设置在双1条件下。
健康检测与切换类型：健康检测：
HA 使用update 语句对mysql 实例分别通过VIP，物理IP进行检测，这样检测的优点是可以检测从VIP到用户实例主库的整条链路的可用性，同时配合备库的io线程的健康状况，避免HA到用户主库网络故障情况下，主库实例健康时的误判。
HA 每次update 成功时，HA都将主库的时间戳记录到HA当中，同时更新主备库的心跳表，让备库同步主库写入的时间戳，当发生切换时，对比HA中与实例备库中保存的时间戳，可以得到备库大致的延迟。作为主备延迟的判断依据之一。
当实例发生连接超时，连接重置，更新超时，socket超时时都被称作故障切换。
普通切换
当发生mysql实例版本升级，规格升级，刷新实例参数等情况时，需要对实例做主备切换。切换基本步骤如下：
- 预检查主备延迟，如果延迟较大，那么直接退出切换，等待下次切换。
- 如果延迟在一定范围内，那么进入切换流程，调用proxy api 切换VIP 指向备库。Proxy 此时会hold 住用户新的连接和请求，不会访问备库（桥接）。关于桥接的具体详情可以参考proxy 技术方案的文章。
- kill 主库连接，设置read_only参数为ON。等待主库瞬间连接上来的事务结束。
- 读取主库master binlog 的位点信息，等待备库同步到该位点，由于之前进行过预等待所以此步骤不会等待很长时间，根据实际运行中数据观察可以控制在数秒以内。
- 备库打开read_only 为OFF
- 调用proxy api 放开用户连接的请求。整个切换过程不会超过10S，用户会感觉到服务器卡住一小段时间后，恢复正常。
故障切换
mysql实例发生故障的环节可能多种多样，这里仅以主备库采用异步复制模式，并且主库所在主机故障导致的切换为例来讲解基本的故障恢复流程，其他类型的故障后面会再综合介绍。
- 当主库自身发生故障时，HA连接主机后，返回的错误类型是连接超时，或者收到主库返回的rst包，那么进入切换流程。
- 检查备库延迟自身SQL线程延迟，如果有延迟，那么不切换，等待备库应用relaylog。
- 当备库SQL线程没延迟后，尝试连接主库，获取主库master binlog，如果能够获取，那么就等待备库跟上主库到该位点。如果不能获取（一般都是如此），那么对比主备库时间戳，如果时间戳在一定范围内（主备可能存在数据不一致），那么根据用户指定的策略决定是否切换。
A, 如果用户指定可用性优先，那么HA会将用户连接切换至备库，数据可能丢失，已经通报给用户。
B, 如果用户指定可靠性优先，那么不会切换VIP，人工介入重启主库或主实例，或拷贝redo log，修复数据，确保主备一致后，提供服务。
由于异步模式在有主备IO线程延迟情况下可能存在数据丢失，我们数据库内核组专门开发了double binlog 复制方式，用于专门判断在切换时是否存在数据丢失，如果存在，那么可靠性优先条件下不切换，可用性优先条件下可以切换。
在用户指定了半同步模式下，也有可能导致主备数据不一致，但是不会引起数据丢失（数据丢失的定义是用户commit 后收到成功的回复，但是数据库内没有该数据。对于执行超时，或者执行异常，客户端认为是unknown状态，那么数据库可以选择丢弃该事务，或者应用该事务）。Semi-sync条件下，主备故障切换后，备库按照新主库备份集来重新搭建，确保主备数据一致。
其他故障切换：
以上图中各处都有可能发生故障，那么对于不同的故障情况，都要分别逐一考虑，目前HA从整体上已经保证了以上各种故障条件下，可以在用户指定策略下按预期切换。考虑篇幅过长，每种情况的分析放在下次分享中，这里暂不作介绍。
HA 自身高可用与高可靠
HA 通过多台机器采用多MASTER结构平衡负载，每台HA负责该region的一部分实例，并动态平衡，同时如果有一台HA发生故障，那么其他HA机器会争抢该dead HA所负责实例，然后再次平衡负载，实现方法既可以很简单，也可以很复杂， ha 这里由于考虑多单元部署的成本问题，使用metaDB中一个表作为负载均衡器，使用另外一张表作为HA心跳表，同时metaDB 使用一主多备方案，避免单点故障。整体上解决了HA 自身的高可用问题。
主库故障：故障分类
可靠性保障：可靠性概述
半同步模式：主库收到commit 后，依次执行 redo log prepare，写binlog/发往备库(两个步骤并行)，等待备库回复收到ack，redo log commit，给用户回复成功。这个有一个等待ack的超时，当超过设置的时长，那么自动降级为异步模式；当网络或备库恢复后，备库IO线程开始追赶主库，当追上后，复制模式会自动升级为半同步模式。
强同步模式：主库收到commit 后，依次执行 redo log prepare，写binlog/发往备库（并行），等待备库fsync到磁盘后，redo log commit ，给用户恢复成功。
保证可靠性：异步模式下，由于主库写入事务时，不会传递到备库（无论物理复制还是逻辑复制），那么当主库down机时，备库数据和主库是很可能不一致的，所以此时是无法保证可靠性的。对于我们阿里云用户使用的mysql库，在此模式下就没任何办法了么？其实不是，在此模式下，我们提供了以下的措施来最大限度的保证主备一致性：
1）备库一定是在应用完所有传递到备库的日志后，才开放可写。这样就最大限度保证备库的数据线是一致的，不会导致双写的问题（一边应用日志，一边接受写入）。
2）主库增加时间戳，通过复制关系同步到备库，当主库故障时，HA系统（数据库高可用系统）通过比对最后一次成功写入主库的时间戳及备库上从主库接受到日志后应用掉后的时间戳进行比较，当大于某个阀值时，不做链路切换动作。这样能够保证主备间数据不一致的时间长度在可控范围内。
3）判断主库故障的条件更加苛刻，当不是主库所在主机是不可恢复的故障时，优先使用主库重启的方式来解决，确保数据线的一致性。
半同步模式下，当网络与主备库都正常情况下，主备库的数据一定是最终一致的（备库需要应用relay日志），当主库故障时，要么事务在主库还没有应用，没有传递日志到备库；要么事务在主库应用了，日志也传递到了备库。所以最终是一致的。
那么是不是半同步下，数据就不丢了呢？我们前面说过，当网络，和备库出现间歇性问题时，那么半同步会降级为异步，那么如果恰恰在此时，备库的IO线程正在追赶主库的binlog位点，但是还没有完全同步上，主库down了(也就是说此时出现延迟的情况下)，主备数据就会出现不一致。
针对这个问题，我们研发了double binlog复制模式，该模式是在半同步基础上更进一步，在主备库间除了半同步复制通路，同时还有一个异步复制通路，平时在主备库及网络都健康情况下，由半同步通路持续的保持复制关系，确保主备数据一致；但是当在备库或主备间网络出现问题，一旦备库或网络恢复后，备库不再使用单一的链路来复制binlog，会同时开启两条复制链路，一条继续从上次备库最后一次接到的位点来复制，一条从主库写入的最新一条事务日志来复制，那么落后的复制不必追赶到最新的主库binlog位置才升级为半同步，而是追赶到备库恢复后的位点即可。这时两条复制通路的binlog就可以完整接上，然后等待备库继续掉日志后，主备数据就完全同步了。
总结：所以通过这个特性，我们能做到在主备出现延迟后，依然能够保证主备的一致性。目前金融专有云已经开始使用该复制模式，对数据要求性高的朋友依然可以使用mysql一主一备的低成本方式来满足企业的日常需求。
- 发表于 2016-09-17 02:24
- 阅读 ( 55 )
