站长资讯网GitHub是怎么做好 MySQL 高可用性的？下面本篇文章就来带大家分享一下，希望对大家有所帮助。
程序员必备接口测试调试工具：立即使用
Apipost = Postman + Swagger + Mock + Jmeter
Api设计、调试、文档、自动化测试工具
后端、前端、测试，同时在线协作，内容实时同步
Github 使用 MySQL 数据库作为所有非 git 事务的数据存储。数据库的可用性对 Github 的正常运行而言至关重要。无论是 Github 网站本身，还是 Github API，身份验证服务等都需要访问数据库。Github 运行了多个数据库集群用于支撑不同的服务于任务。数据库的架构采用的是传统的主从结构，集群中一个节点（主库）支持写访问，其余的节点（从库）同步主库的变更，支持读服务。
主库的可用性至关重要。一旦主库宕机，集群将不能够支持数据写入服务：任何需要保存的数据都无法写入到数据库保存。最终导致 Github 上任何变更，例如代码提交，提问，用户创建，代码 review，创建仓库等操作都无法完成。
为了保证业务的正常运行，我们自然需要在集群中有一个可用的支持写入的数据库节点。同时，我们也必须能够快速的发现可用的可写入服务数据库节点。
就是说，在异常情况下，假如主库宕机的场景，我们必须确保新的主库能够立刻上线支持服务，同时保证集群中其他节点能够快速识别到新的主库。故障检测，主库迁移以及集群其他数据节点识别新主库的总时间构成了服务中断的总时间。
这篇文章说明了 GitHub 的 MySQL 高可用性和主库服务发现解决方案，该解决方案使我们能够可靠地运行跨数据中心的操作，能够容忍数据中心的隔离，并缩短在出现故障时停机时间。
高可用性的实现#
本篇文章描述的解决方案是在以前 Github 高可用方案上的改进版本。正如前面说到的一样，MySQL 的高可用策略必须适应业务的变化。我们期望 MySQL 以及 GitHub 上其他的服务都有能够应对变化的高可用解决方案。
当设计高可用以及服务发现系统方案的时候，从下面几个问题出发，也许能够帮助我们快速找到合适的解决方案：
- 最大允许的服务中断的时间是多少？
- 服务中断检测的准确性怎么样？是否能够允许服务中断检测误报（会导致过早故障转移）？
- 故障转移的可靠性怎么样？什么情况会导致故障转移失败？
- 这个方案能否在跨数据中心实现，以及如何实现的？ 在不同的网络状况下会怎么样，延迟高，或延迟低的情况会怎么样？
- 这个解决方案能否承受整个数据中心（DC）的故障 或者网络隔离的情况？
- 有什么机制防止 HA 集群脑裂情况（在一个整体的系统，联系着的两个节点分裂为两个独立节点，这两个节点争抢共享资源写入数据的情况）？
- 能否容忍数据丢失？容忍丢失程度是多少？
为了说明上面的几个问题，我们先来看一下我们之前的高可用方案，以及我们为什么要改进它。
摒弃基于 VIP 和 DNS 的发现机制#
在之前的方案中，应用了下面的技术方案：
- 使用 orchestrator 作为故障检测迁移方案。
- 采用 VIP 和 DNS 方式作为主节点发现方案。
客户端通过节点名称，例如 mysql-writer-1.github.net，解析成主节点的虚拟 IP 地址 (VIP)，从而找到主节点。
因此，正常情况下，客户端可以通过对节点名称的解析，连接到对应 IP 的主节点上。
考虑夸三个数据中心的拓扑结构的情况：
一旦主库异常，必须将其中的一个数据副本服务器更新为主库服务器。
orchestrator 会检测异常，选出新的主库，然后重新分配数据库的名称以及虚拟 IP (VIP)。客户端本身不知道主库的变更，客户端有的信息只是主库的名称，因此这个名称必须能够解析到新的主库服务器。考虑下面的问题：
VIP 需要协商：虚拟 IP 由数据库本身所持有。 服务器必须发送 ARP 请求，才能够占有或释放 VIP。 在新的数据库分配新的 VIP 之前，旧的服务器必须先释放其占有的 VIP。这个过程会产生一些异常问题:
- 故障转移的顺序，首先是请求故障机器释放 VIP，然后联系新的主库机器分配 VIP。但是，如果故障机器本身不能访问，或者说拒绝释放 VIP 呢？ 考虑到机器故障的场景，故障机器不会立即响应或根本就不会响应释放 VIP 的请求，整个过程有下面两个问题：
- 脑裂情况：如果有两个主机持有相同的 VIP 的情况，不同的客户端根据最短的网络链路将会连接到不同的主机上。
- 整个 VIP 重新分配过程依赖两个独立服务器的相互协调，而且设置过程是不可靠的。
- 即使故障机器正常释放 VIP，整个流程也是非常耗时的，因为切换过程还需要连接故障机器。
- 即使 VIP 重新分配，客户端已有的连接不会自动断开旧的故障机器，从而使得整个系统产生脑裂的情况。
在我们实际设置 VIP 时，VIP 还受实际物理位置的约束。这主要取决于交换机或者路由器所在。因此，我们只能在同一本地服务器上重新分配 VIP。特别是在某些情况下，我们无法将 VIP 分配给其他数据中心的服务器，而必须进行 DNS 更改。
- DNS 更改需要更长的时间传播。客户端缓存 DNS 名称会先配置时间。跨平台故障转移意味着需要
