爱奇艺MySQL高可用方案概述( 二 ) _MySQL

文章插图
图5：MGR高可用方案
3. HA的选主规则
HA需要一套复杂的选主规则，用以适配我们复杂的部署环境，选主规则如下：

排除在bad slaves里的slave
选择所有latest slaves优先级最高的candidate master
如果从库没有设置优先级，选出所有非bad slaves的slave
根据切换策略，依次选择同DC->同region->跨region的slave 。
对满足条件的从库，排除从库所在机器Master个数和Slave个数太多的salve ，在剩下的slave中选择机器剩余磁盘空间最大的slave 。

通过以上规则，选出一个最优的主进行切换。如果没有满足条件的slave ，则会通过电话告警的方式通知DBA进行人工干预。
4. 补全diff binlog
在Master切换过程中，会存在3种类型的diff binlog：

从库io thread接收到的relay log不完整，不是一个完整的事务或完整的binlog event 。
lastest slave与其他slave存在的diff relay log 。
如果dead master机器还能访问, 则还包括dead master未发送的diff binlog 。

diff binlog的恢复顺序如图所示：

文章插图
图6：数据恢复步骤
如果是使用gtid复制，需要生成3种diff binlog文件，然后顺序Apply diff binlog文件，恢复从库。非gtid复制，先change master到lastest slave ，先让slave从lastest slave恢复数据，然后再apply dead master未发送的diff binlog 文件，完成binlog补齐。
5. 数据一致性的重要性
如果采用半同步复制，且主库宕机瞬间没有发生网络超时，则HA能保证切换以后数据的一致性。但如果主库宕机瞬间，网络存在超时会导致半同步复制退化为异步复制，此时发生切换就可能丢失数据。这种情况需要业务端具备补偿机制，对数据进行补齐。但如果是MGR ，不会存在数据丢失的问题。
结束语
我们结合爱奇艺多种内部监控系统、资产管理系统、CMDB、链路追踪以及混沌工程平台开发一个面向业务的应用运维平台，提供一站式服务拨测、巡检、资源使用分析、调用链路追踪以及故障演练等功能。通过混沌工程平台提供的故障注入能力，对S级业务的数据库进行攻防演练。经过不断的迭代优化，数据库的攻防演练会成为常态，通过不断的演练提升应用的可用性和安全性，真正做到有备无患。
技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式

【爱奇艺MySQL高可用方案概述】