标签：24 11 GitHub 西海岸 东海岸 集群 MySQL 主库 leader
目录这起事故虽然发生在2018年，已经过去了很长时间，但其中的问题和带来的启示永不过时，拿来分析，具有很重要的意义。
1.背景
GitHub主要有东、西海岸两个数据中心，以及其他三个公有云数据中心。本次事故主要涉及东、西海岸两个数据中心。
并且，在GitHub，使用的Orchestrator作为MySQL集群拓扑管理和主库高可用工具。
GitHub 的MySQL集群和Orchestrator高可用服务部署情况如下。
MySQL集群部署情况
MySQL集群是一主 4从：
- 主库和2个从库在东海岸
- 2个从库在西海岸
为了大规模提高扩展性，已经使用读写分离。写操作在主库上，大部分读操作在从库上。
Orchestrator部署情况
Orchestrator高可用服务以分布式集群方式部署，跨东西海岸。
2.事情的经过
东海岸更换光纤设备，导致东海岸数据中心与外界网络断开，43s后，网路恢复。
这个短暂的网络断开，引起了一连串的事故。
这些事故主要包括以下。
1）.ORC leader漂移
ORC leader 原来是在东海岸，网络断开，触发leader 漂移到西海岸。
2）.MySQL集群主库切换后，数据不一致
ORC leader 漂移到西海岸后，发现主库探测异常，2个东海岸从库探测异常，2个西海岸从库复制断开，判定为DeadMasterAndSomeSlaves，触发MySQL集群主库由东海岸切到西海岸。写入流量开始导入到西海岸主库。
在切换过程，东海岸的2个从库无法change到新主库，成为丢失副本。切换后，实际集群拓扑，只包括一主一从，且都在西海岸。
切换后，发现东海岸有部分写入没有同步到西海岸。东、西海岸数据出现不一致。
出现问题后，为了保证数据一致性，GitHub 首先进行了服务降级，暂停了部分服务。
接着，在东海岸重新建立新主库。这其中包括，从备份恢复数据、从东西海岸同步数据等。
再接着，将主库切回东海岸。处理队列中的数据。
最后，网站对外提供服务。
最最后，解决数据不一致。通过与用户沟通，恢复丢失的数据。
3.存在的隐患
通过这个事故，可以看到几个隐患。
1）.ORC 跨Region部署
跨Region 的网络抖动，会导致ORC leader漂移。如果leader正在进行切换，leader漂移，会导致切换进行到一半。
解决方案：ORC 服务不跨Region部署。
2）.MySQL集群跨Region部署
跨Region部署，一方面，可以提供数据远程备份。另一方面，复制可能存在延迟，如果发生类似这个故障场景的切换，会造成数据不一致。
3）. 为什么恢复数据的方式是通过备份进行恢复？
通过备份恢复数据的问题是，时间太长。首先是备份存在公有云，需要远程下载，其次是解压、校验和应用数据，耗费时间。
为什么不将东海岸的其中一个从库，回退部分数据，接着同步西海岸新写入的数据，之后，就可以使用了吧？
4.参考
2018-10-30-oct21-post-incident-analysis
标签：24,11,GitHub,西海岸,东海岸,集群,MySQL,主库,leader 来源： https://www.cnblogs.com/lanyangsh/p/15616567.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。