如何做好MySQL高可用性的

发布时间：2024-01-01 05:57:30 所属栏目：MySql教程来源：DaWei

导读： 这篇文章主要介绍了GitHub是如何做好MySQL高可用性的的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇GitHub是如何做好MySQL高可用性的文章都会有所收获，下

这篇文章主要介绍了GitHub是如何做好MySQL高可用性的的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇GitHub是如何做好MySQL高可用性的文章都会有所收获，下面我们一起来看看吧。

Github 使用 MySQL 数据库作为所有非 git 事务的数据存储。数据库的可用性对 Github 的正常运行而言至关重要。无论是 Github 网站本身，还是 Github API，身份验证服务等都需要访问数据库。Github 运行了多个数据库集群用于支撑不同的服务于任务。数据库的架构采用的是传统的主从结构，集群中一个节点（主库）支持写访问，其余的节点（从库）同步主库的变更，支持读服务。

主库的可用性至关重要。一旦主库宕机，集群将不能够支持数据写入服务：任何需要保存的数据都无法写入到数据库保存。最终导致 Github 上任何变更，例如代码提交，提问，用户创建，代码 review，创建仓库等操作都无法完成。

为了保证业务的正常运行，我们自然需要在集群中有一个可用的支持写入的数据库节点。同时，我们也必须能够快速的发现可用的可写入服务数据库节点。

就是说，在异常情况下，假如主库宕机的场景，我们必须确保新的主库能够立刻上线支持服务，同时保证集群中其他节点能够快速识别到新的主库。故障检测，主库迁移以及集群其他数据节点识别新主库的总时间构成了服务中断的总时间。

orchestrator 会检测异常，选出新的主库，然后重新分配数据库的名称以及虚拟 IP (VIP)。客户端本身不知道主库的变更，客户端有的信息只是主库的名称，因此这个名称必须能够解析到新的主库服务器。

DNS 更改需要更长的时间传播。客户端缓存 DNS 名称会先配置时间。跨平台故障转移意味着需要更多的中断时间：客户端需要花费更多时间去识别新的主服务器。

主服务器使用 pt-heartbeat 服务去自注入访问心跳，目的是延迟测量和节流控制。该服务必须在新的主服务器开始。如果可以，在更换主服务器的同时会关闭旧的主服务器这项服务。

同样地，Pseudo-GTID 是由服务器自行管理的。它需要在新的主服务器开始，最好在旧的主服务器上停止。

新的主服务器将设置为可写入。如果可以的话，旧的主服务器将设置为 read_only(只读)。

这些额外的步骤是导致总停机时间的一个因素，并引入了它们自己的故障和摩擦。

我们运行一个 orchestrator/raft 设置： orchestrator 节点通过 raft 机制相互通信。每个数据中心有一个或两个 orchestrator 节点。

orchestrator 负责故障检测和 MySQL 故障切换，以及将 master 的变更传达给 Consul 。故障切换由单个 orchestrator/raft leader 节点操作，但是集群现在拥有新 master 的消息通过 raft 机制传播到所有 orchestrator 节点。

当 orchestrator 节点收到 master 变更的消息时，它们各自与本地 Consul 设置通信：它们各自调用 KV 写入。具有多个 orchestrator 代理的 DC 将多次（相同）写入 Consul。

在 DC 网络完全隔离的情况下，该 DC 中的 orchestrator 节点会与其他 DC 中的对等节点断开连接。因此，孤立 DC 中的 orchestrator 节点不能成为 raft 集群的领导者。如果任何这样的节点恰好是领导者，它就会下台。将从任何其他 DC 中分配新的领导者。该领导者将得到所有其他能够相互通信的 DC 的支持。

在 MySQL 的半同步复制中，主服务器不会确认事务提交，直到已知更改已发送到一个或多个副本。它提供了一种实现无损故障转移的方法：应用于主服务器的任何更改要么应用于主服务器，要么等待应用于其中一个副本。

一致性伴随着成本：可用性的风险。如果没有副本确认收到更改，主服务器将阻塞并停止写操作。幸运的是，有一个超时配置，超时后主服务器可以恢复到异步复制模式，从而使写操作再次可用。

我们已经将超时设置为一个合理的低值: 500ms。将更改从主 DC 副本发送到本地 DC 副本，通常也发送到远程 DC，这已经足够了。通过这个超时，我们可以观察到完美的半同步行为 (没有退回到异步复制) ，并且在确认失败的情况下可以很轻松地使用非常短的阻塞周期。

我们在本地 DC 副本上启用半同步，在主服务器死亡的情况下，我们期望 (尽管不严格执行) 无损故障转移。完全直流故障的无损故障转移是昂贵的，我们并不期望它。

在尝试半同步超时的同时，我们还观察到了一个对我们有利的行为：在主要失败的情况下，我们能够影响理想候选对象的身份。通过在指定的服务器上启用半同步，并将它们标记为候选服务器，我们能够通过影响故障的结果来减少总停机时间。在我们的实验中，我们观察到我们通常最终会得到理想的候选对象，从而快速地广而告之。

我们没有在升级 / 降级的主机上管理 pt-heart 服务的启动 / 关闭，而是选择在任何时候在任何地方运行它。这需要进行一些修补，以便使 pt-heart 能够适应服务器来回更改 read_only(只读状态) 或完全崩溃的情况。

在我们当前的设置中，pt-heart 服务在主服务器和副本上运行。在主机上，它们生成心跳事件。在副本上，他们识别服务器是 read_only(只读) 的，并定期重新检查它们的状态。一旦服务器被提升为主服务器，该服务器上的 pt-heart 就会将服务器标识为可写的，并开始注入心跳事件。

代理层使应用程序不知道主服务器的身份，但它也掩盖了应用程序的主服务器的身份。所有主要看到的都是来自代理层的连接，我们会丢失关于连接的实际来源的信息。

值得注意的是，在一个数据中心隔离场景中，假设主服务器位于隔离的 DC 中，该 DC 中的应用程序仍然能够写入主服务器。一旦网络恢复，这可能导致状态不一致。我们正在努力减轻这种分裂的大脑实施一个可靠的 STONITH 从内部非常孤立的 DC。和以前一样，在摧毁初选之前还需要一段时间，而且可能会有一段短时间的脑分裂。避免大脑分裂的操作成本非常高。

还存在更多的情况：在故障转移时停止领事服务；部分直流隔离；其他情况。我们知道这种性质的分布式系统不可能堵住所有的漏洞，所以我们把重点放在最重要的案例上。

关于“GitHub是如何做好MySQL高可用性的”这篇文章的内容就介绍到这里，感谢各位的阅读！

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!