GitHub的的MySQL高可用性实践高可用性实践
GitHub使用MySQL作为所有非git项目的主要数据存储,因此MySQL的可用性对于GitHub的运维来说至关重要。站点本身、
GitHub的API、身份验证等都需要数据库访问。我们运行多个MySQL集群来服务我们的不同服务和任务。我们的集群使用经
典的主-副设置,其中集群的单个节点(主节点)能够接受写操作。其它集群节点(副节点)异步更新主节点的变更并服务我
们的读流量。
主节点的可用性特别地重要。主节点不可用时,集群就不能接受写操作:任何需要持久化的写操作都不能被持久化。任何传入
的变更,例如提交代码、提问题、用户创建、代码审查、新建代码库等等,都会失败。
为了支持写操作,我们显然需要有一个可用的写节点,即集群的主节点。但同样重要的是,我们需要能够识别,或者发现,那
个节点。
遇到一个故障时,比如主节点崩溃的场景,我们必须确保存在一个新的主节点,并且能够快速通告其身份。检测故障、运行故
障恢复以及通告新主节点身份所花费的时间组成了总宕机时间。
本文阐述了GitHub的MySQL高可用性和主服务发现解决方案,这个方案使得我们能够可靠地进行跨数据中心运维、克服数据
中心隔离的影响并实现故障时的短宕机时间。
高可用性目标
本文描述的解决方案是对GitHub先前实现的高可用性(HA)解决方案的迭代和改进。随着我们规模的扩大,我们的MySQL
HA策略必须适应变化。我们希望对我们的MySQL和GitHub的其它服务运用相似的HA策略。
当考虑高可用性和服务发现时,一些问题可以指导你找到一个恰当的解决方案。这些问题包括但不限于:
你能容忍的宕机时间是多久?
崩溃检测的可靠性如何?你能容忍假阳性(过早进行故障恢复)吗?
故障恢复的可靠性如何?它在哪些情况下会失败?
解决方案跨数据中心能力如何?在低延迟和高延迟网络的能力如何?
解决方案能克服完整的数据中心故障或网络隔离的影响吗?
如果有的话,什么机制能够防止或减轻脑裂现象(两个服务器都宣称是指定集群的主节点,都独立地彼此无意识地接受写操
作)?
你能够承受数据丢失吗?到什么程度?
为了说明上述一些问题,让我们先看一下我们之前的HA迭代以及为什么我们要改变它。
远离基于VIP和DNS的服务发现
在我们之前的迭代中,我们使用:
orchestrator用于故障监听和故障恢复
VIP和DNS用于发现主节点
在那个迭代中,客户端通过使用一个名称,例如mysql-writer-1.github.net来发现写节点。这个名称解析为主节点获取的虚拟IP
地址(Virtual IP address,VIP)。
因此,平常的时候,客户端会只解析这个名称,连接解析到的IP地址,然后找到正在另一端监听的主节点。
这个副本拓扑,跨越3个不同的数据中心: