Github工程师为MySQL高可用性采用了新架构

Github.com使用MySQL作为其许多关键服务的主干，如对外API，身份验证和Github.com网站本身。 Github的工程师团队用基于Orchestrator，Consul和Github负载均衡器的设置替换了之前基于DNS和VIP的设置以脑裂和DNS缓存问题。

Github为不同的服务和任务运行多个MySQL集群，因此必须使它们具有高可用性。 Github的基础架构分布在多个数据中心，包括大约15个集群，近150个生产服务器和15 TB的MySQL表。每个MySQL集群都有一个主节点，它响应写入请求，以及多个从节点，它们是主节点的副本并提供读取请求。主节点形成单点故障，没有它，写入将完全失败。此设置的高可用要求包括自动检测故障，将从节点自动升级到主节点以及将新主节点自动通告给客户端应用程序。

多年来，Github的工程师团队为HA尝试了多种策略，逐渐整个组织在策略上得到了统一。由于这不仅限于MySQL，因此对HA解决方案要求包括跨数据中心可用性和脑裂预防。 MySQL主发现有不同的可能方法。以前，Github利用DNS和虚拟IP地址（VIP）来发现MySQL主节点。客户端应用程序将连接到固定主机名，DNS将解析该主机名以指向虚拟IP（VIP）。 VIP允许将流量路由到不同的主机以提供移动性，而无需将其绑定到单个主机。 VIP将始终由当前主节点拥有。但是，在故障转移事件（包括脑裂情况）期间，VIP获取和释放过程存在潜在问题。发生这种情况时，两个不同的主机可以拥有相同的VIP，并且流量可以路由到错误的主机。此外，必须进行DNS更改才能处理位于不同数据中心的主节点，并且由于客户端的DNS缓存而需要时间来传播。

Github的最新设置包括Orchestrator工具包，Consul用于服务发现和Github负载均衡。在此体系结构中，当客户端应用程序通过其名称在DNS上查找主服务器的IP时，它将通过Anycast解析。使用Anycast的优势在于，虽然名称在每个数据中心被解析为相同的IP地址，但是到该IP的客户端流量将路由到最近的主服务器。最近的主服务器是共同位于同一数据中心的主服务器。这个路由由GLB处理，GLB知道当前活动的MySQL主后端。

图片来源：https://githubengineering.com/mysql-high-availability-at-github/

Orchestrator也是一个Github开源项目，负责主故障检测和故障转移过程。它利用从包括副本在内的所有MySQL节点中获取的信息来得出关于主控状态的决策。当写主机发生故障时，Orchestrator领导节点会检测到故障并启动故障转移过程以选择新的MySQL主机。其余的Orchestrator集群节点会注意到此更改，并使用新的详细信息更新其本地Consul守护进程。 Consul是Hashicorp的服务发现工具，它通过将主节点存储为键值对来跟踪主节点。 Consul可以跨数据中心以分布式模式运行，但在Github的情况下，每个Consul集群在数据中心级别是独立的。使用Consul Template向GLB通知故障转移事件的主状态更改，Consul Template查询Consul集群并更新GLB状态，GLB状态又将流量路由到新主服务器。

在文章中，Github的高级基础设施工程师Shlomi Noach提到，虽然新设置在大多数情况下提供了“10到13秒”的最大停机时间，但有些情况需要更多时间，例如数据中心隔离导致 故障转移时的脑裂或停电。 Github的新设置是从基于网络的传统技术转向基于代理和服务发现的技术。 它完全取代了基于VIP的方案，但是围绕使用边界网关协议（BGP）采用不同方法是否更容易存在争议。

查看英文原文：https://www.infoq.com/news/2018/07/github-mysql-high-availability