Parlons de la façon dont GitHub atteint la haute disponibilité de MySQL

Comment GitHub atteint-il la haute disponibilité pour MySQL ? L'article suivant sera partagé avec vous, j'espère qu'il sera utile à tout le monde.

Github utilise une base de données MySQL comme magasin de données pour toutes les transactions non-git. La disponibilité de la base de données est essentielle au bon fonctionnement de Github. Le site Web Github lui-même, l'API Github, le service d'authentification, etc. doivent tous accéder à la base de données. Github exécute plusieurs clusters de bases de données pour prendre en charge différentes tâches de service. L'architecture de la base de données adopte une structure maître-esclave traditionnelle. Un nœud (base de données maître) du cluster prend en charge l'accès en écriture, et les nœuds restants (bases de données esclaves) synchronisent les modifications apportées à la base de données maître et prennent en charge les services de lecture. 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 的主节点上。

考虑夸三个数据中心的拓扑结构的情况：

一旦主库异常，必须将其中的一个数据副本服务器更新为主库服务器。

orchestratorLa disponibilité de la bibliothèque principale est cruciale. Une fois la base de données principale en panne, le cluster ne sera plus en mesure de prendre en charge les services d'écriture de données : les données devant être enregistrées ne pourront pas être écrites dans la base de données pour être stockées. Par conséquent, toute modification sur Github, telle que la soumission de code, les questions, la création d'utilisateurs, la révision de code, la création d'entrepôt, etc., ne peut pas être effectuée.

Afin d'assurer le fonctionnement normal de l'entreprise, nous avons naturellement besoin d'avoir un nœud de base de données disponible dans le cluster qui supporte l'écriture. Dans le même temps, nous devons également être en mesure de découvrir rapidement les nœuds de base de données de service accessibles en écriture.

C'est-à-dire que dans des circonstances anormales, si la base de données principale est en panne, nous devons nous assurer que la nouvelle base de données principale peut être immédiatement mise en ligne pour prendre en charge les services et garantir que les autres nœuds du cluster peuvent identifier rapidement la nouvelle base de données principale. Le temps total nécessaire à la détection des pannes, à la migration du maître et aux autres nœuds de données du cluster pour identifier le nouveau maître constitue la durée totale de l'interruption du service. 🎜🎜Cet article explique la solution de haute disponibilité MySQL et de découverte de services maîtres de GitHub qui nous permet d'exécuter des opérations de manière fiable dans les centres de données, de tolérer l'isolement du centre de données et de réduire les temps d'arrêt en cas de panne. 🎜

Mise en œuvre de la haute disponibilité#

🎜La solution décrite dans cet article est une version améliorée de la précédente solution haute disponibilité Github. Comme mentionné précédemment, la stratégie de haute disponibilité de MySQL doit s'adapter aux évolutions de l'entreprise. Nous nous attendons à ce que MySQL et d'autres services sur GitHub disposent de solutions hautement disponibles capables de faire face aux changements. 🎜🎜Lors de la conception d'une solution système de haute disponibilité et de découverte de services, partir des questions suivantes peut nous aider à trouver rapidement une solution adaptée : 🎜

• Quelle est la durée maximale d'interruption de service autorisée ?
• Quelle est la précision de la détection des pannes de service ? La détection des pannes de service peut-elle être autorisée à détecter les faux positifs (provoquant un basculement prématuré) ?
• Quelle est la fiabilité du basculement ? Quelles conditions peuvent provoquer l’échec du basculement ?
• Cette solution peut-elle être mise en œuvre dans tous les centres de données, et comment est-elle mise en œuvre ? Que se passera-t-il dans différentes conditions de réseau, avec une latence élevée ou une latence faible ?
• Cette solution peut-elle résister à une panne complète d'un centre de données (DC) ou à l'isolement du réseau ?
• Existe-t-il un mécanisme pour empêcher la situation de division cérébrale du cluster HA (dans un système global, deux nœuds connectés se divisent en deux nœuds indépendants, et les deux nœuds se disputent les ressources partagées pour écrire des données) ?
• La perte de données peut-elle être tolérée ? Quel niveau de perte est toléré ?

🎜Afin d'expliquer les problèmes ci-dessus, examinons d'abord notre précédente solution de haute disponibilité et pourquoi nous souhaitons l'améliorer. 🎜

Abandonner le mécanisme de découverte basé sur VIP et DNS# a >

🎜Dans la solution précédente, la solution technique suivante a été appliquée : 🎜

• Utiliser orchestrator En tant que solution de migration de détection de pannes.
• Utilisez les méthodes VIP et DNS comme solution de découverte du nœud maître.

🎜Le client trouve le nœud maître en analysant le nom du nœud, tel que mysql-writer-1.github.net, dans l'adresse IP virtuelle (VIP) du nœud maître. 🎜🎜Par conséquent, dans des circonstances normales, le client peut se connecter au nœud maître de l'IP correspondante en analysant le nom du nœud. 🎜🎜Considérons le cas de la topologie de trois centres de données : 🎜🎜🎜🎜Une fois que la base de données principale est anormale, l'un des serveurs de réplique de données doit être mis à jour vers le serveur de base de données principal. 🎜🎜orchestrator détectera les anomalies, sélectionnera une nouvelle base de données principale, puis réattribuera le nom de la base de données et l'adresse IP virtuelle (VIP). Le client lui-même ne connaît pas les modifications apportées à la bibliothèque principale. Les informations dont dispose le client sont uniquement le 🎜nom🎜 de la bibliothèque principale, ce nom doit donc pouvoir être résolu sur le nouveau serveur de bibliothèque principale. Considérez ce qui suit : 🎜🎜VIP doit être négocié : l'adresse IP virtuelle est détenue par la base de données elle-même. Le serveur doit envoyer une requête ARP pour occuper ou libérer le VIP. Avant que la nouvelle base de données puisse allouer de nouveaux VIP, l'ancien serveur doit d'abord libérer les VIP qu'il détient. Ce processus entraînera des problèmes inhabituels :🎜

• La séquence de basculement consiste à demander d'abord à la machine défaillante de libérer VIP, puis à contacter la nouvelle machine de base de données principale pour allouer VIP. Mais que se passe-t-il si la machine en panne elle-même est inaccessible ou refuse de libérer le VIP ? Compte tenu du scénario de panne de la machine, la machine en panne ne répondra pas immédiatement ou pas du tout à la demande de libération du VIP. L'ensemble du processus présente les deux problèmes suivants :
  • Situation de cerveau divisé : s'il y a deux hôtes détenant le même VIP. Dans cette situation, différents clients se connecteront à différents hôtes en fonction du lien réseau le plus court.
  • L'ensemble du processus de réattribution VIP repose sur la coordination de deux serveurs indépendants et le processus de configuration n'est pas fiable.
• Même si la machine défectueuse libère le VIP normalement, l'ensemble du processus prend beaucoup de temps car le processus de commutation nécessite également une connexion à la machine défectueuse.
• Même si le VIP est réaffecté, les connexions existantes du client ne se déconnecteront pas automatiquement de l'ancienne machine en panne, provoquant une situation de division du cerveau dans l'ensemble du système.

Lorsque nous installons réellement le VIP, le VIP est également lié par l'emplacement physique réel. Cela dépend principalement de l'emplacement du commutateur ou du routeur. Par conséquent, nous ne pouvons réattribuer le VIP que sur le même serveur local. En particulier, il existe des cas où nous ne pouvons pas attribuer de VIP aux serveurs d'autres centres de données et devons apporter des modifications DNS.

• Les modifications DNS mettent plus de temps à se propager. Le client met d'abord en cache les noms DNS avec l'heure configurée. Le basculement multiplateforme signifie davantage de pannes : les clients doivent passer plus de temps à reconnaître le nouveau serveur principal.

Ces limitations à elles seules suffisent à nous pousser à trouver de nouvelles solutions, mais voici les éléments à considérer :

• Le serveur maître utilise le service pt-heartbeat pour s'auto-injecter les battements de coeur d'accès à des fins de Mesure de la latence et contrôle de limitation. Le service doit être démarré sur le nouveau serveur principal. Si possible, le service de l'ancien serveur principal sera arrêté lors du remplacement du serveur principal. pt-heartbeat 服务去自注入访问心跳，目的是延迟测量和节流控制。该服务必须在新的主服务器开始。如果可以，在更换主服务器的同时会关闭旧的主服务器这项服务。

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

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

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

解决方案是有效的，GitHub 已经成功地进行了 MySQL 故障转移，但是我们希望 HA 在以下方面有所改进:

• 与数据中心无关。
• 容忍数据中心故障。
• 删除不可靠的协作工作流。
• 减少总停机时间。
• 尽可能的，有无损的故障切换。

GitHub 的高可用解决方案：orchestrator ，Consul ， GLB

新策略可以改进，解决或者优化上面提到的问题。现在高可用的组成如下：

• orchestrator 执行检测和故障转移。如链接中描述的那样采用混合数据中心 orchestrator/raft 。
• Hashicorp 的 Consul 作为服务发现。
• GLB/HAProxy 作为客户端和写入节点之间的代理。 GLB 指导是开源的.
• anycast 作为网络路由。

新的结构移除了 VIP 和 DNS 。在引入更多的组件的同时，我们能够解藕这些组件，并且简化相关的任务，并易于利用可靠稳定的解决方案。详情如下。

正常过程

正常情况，应用通过 GLB/HAProxy 连接到写入节点。

应用感知不到 master 身份。之前，都是使用名称。例如 cluster1 的 master 是 mysql-writer-1.github.net。现在的结构中，这个名称被  anycast IP 取代。

通过 anycast，名称被相同的 IP 取代，但流量由客户端的位置来进行路由。特别的，当数据中心有 GLB 时，高可用负载均衡器部署在不同的盒子内。 通向 mysql-writer-1.github.net

🎜🎜De même, le Pseudo-GTID est géré par le serveur lui-même. Il faut le démarrer sur le nouveau maître et l'arrêter de préférence sur l'ancien maître. 🎜🎜🎜🎜Le nouveau maître sera configuré pour être accessible en écriture. L'ancien maître sera défini sur read_only si possible. 🎜🎜🎜🎜Ces étapes supplémentaires sont un facteur de temps d'arrêt total et introduisent leurs propres problèmes et frictions. 🎜🎜La solution fonctionne, GitHub a effectué avec succès le basculement MySQL, mais nous aimerions que HA s'améliore dans les domaines suivants : 🎜🎜🎜Agnostique du centre de données. 🎜🎜Tolérant aux pannes du centre de données. 🎜🎜Supprimez les flux de travail de collaboration peu fiables. 🎜🎜Réduisez les temps d’arrêt totaux. 🎜🎜Dans la mesure du possible, effectuez un basculement sans perte. 🎜🎜

Les solutions haute disponibilité de GitHub : orchestrator, Consul, GLB

🎜De nouvelles stratégies peuvent améliorer, résoudre ou optimiser les problèmes mentionnés ci-dessus. Les composants haute disponibilité actuels sont les suivants : 🎜🎜🎜orchestrator effectue la détection et le basculement. Adoptez un centre de données hybride comme décrit dans le lien orchestrator/raft une>. 🎜🎜Le Consul de Hashicorp comme découverte de service. 🎜🎜GLB/HAProxy en tant que client et nœud d'écriture entre agents . Le directeur GLB est open source.🎜🎜anycast en tant que réseau routeur. 🎜🎜🎜🎜🎜 La nouvelle structure supprime VIP et DNS. Au fur et à mesure que nous introduisons davantage de composants, nous sommes en mesure de les découpler, de simplifier les tâches associées et de faciliter l'exploitation d'une solution fiable et stable. Détails ci-dessous. 🎜

Processus normal

🎜Dans des circonstances normales, l'application se connecte au nœud d'écriture via GLB/HAProxy. 🎜🎜L'application ne connaît pas l'identité du maître. Auparavant, on utilisait des noms. Par exemple, le maître de cluster1 est mysql-writer-1.github.net. Dans la structure actuelle, ce nom est remplacé par anycast IP. 🎜🎜Avec anycast, le nom est remplacé par la même IP, mais le trafic est acheminé par la localisation du client. En particulier, lorsque le data center dispose de GLB, l’équilibreur de charge haute disponibilité est déployé dans un boîtier différent. Le trafic vers mysql-writer-1.github.net est dirigé vers le cluster GLB dans le centre de données local. De cette façon, tous les clients sont servis par le proxy local. 🎜

Utilisez GLB sur HAProxy. HAProxy dispose de pools d'écriture  : un pour chaque cluster MySQL. Chaque pool dispose d'un service backend : le nœud maître du cluster. Tous les boîtiers GLB/HAProxy du data center ont le même pool, ce qui signifie que ces pools correspondent aux mêmes services backend. Ainsi, si l'application s'attend à écrire mysql-writer-1.github.net, elle ne se soucie pas du service GLB auquel se connecter. Cela mènera au nœud maître cluster1 réel. mysql-writer-1.github.net，不同关心连接哪个 GLB 服务。它会导向实际的 cluster1 master 节点。

就应用连接 GLB ，发现服务而言，不需要重新发现。GLB 负责全部流量导向正确的目的地。

GLB 是怎么知道哪些服务是后端，以及如何告知 GLB 变化的呢？

Discovery via Consul

Consul 以服务发现解决方案而闻名，也提供 DNS 服务。 然而，在我们的解决方案中，我们将其用作高度可用的键值 (KV) 存储。

在 Consul 的 KV 存储中，我们写入集群主节点的身份。 对于每个集群，都有一组 KV 条目指示集群的主设备 fqdn、端口、ipv4、ipv6。

每个 GLB/HAProxy 节点都运行 consul-template：一个监听 Consul 数据变化的服务（在我们的例子中：集群主数据的变化）。 consul-template 生成一个有效的配置文件，并且能够在配置更改时重新加载 HAProxy。

因此，每个 GLB/HAProxy 机器都会观察到 Consul 对 master 身份的更改，然后它会重新配置自己，将新的 master 设置为集群后端池中的单个实体，并重新加载以反映这些更改。

在 GitHub，我们在每个数据中心都有一个 Consul 设置，并且每个设置都是高度可用的。 但是，这些设置彼此独立。 它们不会在彼此之间复制，也不会共享任何数据。

Consul 如何获知变化，信息如何跨 DC 分发？

orchestrator/raft

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

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

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

把流程组合起来

在 master 崩溃的情况下:

• orchestrator 节点检测故障.
• orchestrator/raft leader 节点开始恢复，一个数据服务器被更新为 master 。
• orchestrator/raft 公告所有 raft 子集群节点变更了 master 。
• 每个 orchestrator/raft 成员收到一个 leader 节点 变更的通知。它们每个成员都把新的 master 更新到本地 Consul KV 存储中。
• 每个 GLB/HAProxy 都运行了 consul-template，该模版观察 Consul KV 存储中的更改，并重新配置和重新加载 HAProxy。
• 客户端流量被重定向到新的 master 。

每个组件都有明确的责任归属，整个设计既是解耦的，又是简化的。orchestrator 不知道负载平衡器。 Consul 不需要知道消息的来源。代理只关心 Consul

Pour que les applications se connectent à GLB et découvrent des services, aucune redécouverte n'est requise. GLB est responsable de diriger tout le trafic vers la bonne destination.

Comment GLB sait-il quels services sont des backends et comment informe-t-il GLB des changements ?

• Découverte via Consul
• Consul est célèbre pour ses solutions de découverte de services et fournit également des services DNS. Cependant, dans notre solution, nous l'utilisons comme magasin clé-valeur (KV) hautement disponible.
• Dans le magasin KV de Consul, nous écrivons l'identité du nœud maître du cluster. Pour chaque cluster, il existe un ensemble d'entrées KV indiquant le fqdn maître du cluster, le port, l'ipv4, l'ipv6.

Chaque nœud GLB/HAProxy exécute consul-template : un service qui surveille les modifications des données du consul (dans notre cas : modifications des données de base du cluster). consul-template génère un fichier de configuration valide et la possibilité de recharger HAProxy lorsque la configuration change.

Ainsi, chaque machine GLB/HAProxy observe les modifications apportées par Consul à l'identité du maître, puis elle se reconfigure, définit le nouveau maître comme une entité unique dans le pool backend du cluster et se recharge pour refléter ces changements.

Chez GitHub, nous avons une configuration Consul dans chaque centre de données, et chaque configuration est hautement disponible. Ces paramètres sont cependant indépendants les uns des autres. Ils ne se copient pas entre eux et ne partagent aucune donnée. 🎜🎜Comment Consul est-il informé des changements et comment les informations sont-elles distribuées entre les DC ? 🎜

🎜orchestrator/raft🎜🎜🎜Nous exécutons une configuration orchestrator/raft : nœud orchestrator via raft🎜 communiquent entre eux. Chaque centre de données possède un ou deux nœuds orchestrator. 🎜🎜orchestrator est responsable de la détection des pannes et du basculement MySQL, ainsi que de la communication des modifications de 🎜master🎜 à 🎜Consul🎜. Le basculement est opéré par un seul nœud leader orchestrator/raft, mais le message indiquant que le cluster a désormais un nouveau 🎜master🎜 est propagé à tous les nœuds orchestrator via le mécanisme de radeau . 🎜🎜Lorsque les nœuds orchestrator reçoivent le message du changement 🎜master🎜, ils communiquent chacun avec la configuration 🎜Consul🎜 locale : ils appellent chacun KV write. Un DC avec plusieurs agents orchestrator écrira plusieurs fois (identiques) à 🎜Consul🎜. 🎜

🎜Combinez les processus🎜🎜🎜En cas de crash du maître :🎜🎜🎜orchestrator Échec de détection du nœud.🎜🎜orchestrator/raft Le le nœud leader commence à récupérer et un serveur de données est mis à jour pour devenir le maître. 🎜🎜orchestrator/raft annonce que tous les nœuds du sous-cluster raft ont changé de maître. 🎜🎜Chaque membre orchestre/radeau reçoit une notification de changement de nœud leader. Chacun de leurs membres met à jour le nouveau maître dans le magasin KV Consul local. 🎜🎜Chaque GLB/HAProxy exécute consul-template, qui observe les changements dans le magasin KV Consul et reconfigure et recharge HAProxy. 🎜🎜Le trafic client est redirigé vers le nouveau maître. 🎜🎜🎜Chaque composant a une responsabilité claire, et l'ensemble de la conception est à la fois découplé et simplifié. orchestrator ne connaît pas les équilibreurs de charge. Consul n'a pas besoin de connaître la source du message. L'agent ne se soucie que du Consul. Le client ne se soucie que du proxy. 🎜🎜Aussi : 🎜🎜🎜Aucune modification DNS à propager🎜🎜Pas de TTL. 🎜🎜Le stream ne coopère pas avec le maître défaillant, il est largement ignoré. 🎜🎜🎜🎜Détails supplémentaires🎜🎜🎜Pour protéger davantage votre trafic, nous avons ce qui suit : 🎜

• HAProxy est configuré avec un hard-stop-after très court. Lorsqu'il recharge le nouveau serveur principal dans le pool d'écriture, il met automatiquement fin à toutes les connexions existantes à l'ancien serveur maître. hard-stop-after。当它重新加载写入器池中的新后端服务器时，它会自动终止与旧主服务器的任何现有连接。
  • 使用 hard-stop-after，我们甚至不需要客户的合作，这减轻了脑裂的情况。值得注意的是，这不是封闭的，并且在我们终止旧连接之前一段时间过去了。但是在某个时间点之后，我们会感到很舒服，并且不会期待任何令人讨厌的惊喜。
• 我们并不严格要求 Consul 随时待命。事实上，我们只需要它在故障转移时可用。如果 Consul 发生故障，GLB 将继续使用最后的已知值进行操作，并且不会采取剧烈行动。
• GLB 设置为验证新提升的 master 的身份。与我们的 上下文感知 MySQL 池 类似，会在后端服务器上进行检查，以确认它确实是写入器节点。如果我们碰巧在 Consul 中删除了 master 的身份，没问题；空条目被忽略。如果我们在 Consul 中错误地写了一个非主服务器的名字，没有问题； GLB 将拒绝更新它并继续以最后一个已知状态运行。

我们将在以下部分进一步解决问题并追求 HA 目标。

Orchestrator/RAFT 故障检测

orchestrator 使用 整体方法 来检测故障，因此非常可靠。我们没有观察到误报：我们没有过早的故障转移，因此不会遭受不必要的停机时间。

orchestrator/raft 进一步解决了完整的 DC 网络隔离（又名 DC 围栏）的情况。 DC 网络隔离可能会导致混乱：该 DC 内的服务器可以相互通信。是它们与其他 DC 网络隔离，还是其他 DC 被网络隔离？

在 orchestrator/raft 设置中，raft 领导节点是运行故障转移的节点。领导者是获得组中大多数人（法定人数）支持的节点。我们的协调器节点部署是这样的，没有一个数据中心占多数，任何 n-1 数据中心都可以。

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

因此，发号施令的 orchestrator 节点将是网络隔离数据中心之外的节点。如果一个独立的 DC 中有一个主控，orchestrator 将启动故障转移，用其中一个可用 DC 中的服务器替换它。我们通过将决策委托给非隔离 DC 中的法定人数来缓解 DC 隔离。

更快的广而告之

通过更快地公布主要更改可以进一步减少总停机时间。如何实现这一点？

当 orchestrator 开始故障转移时，它观察可用于提升的服务器队列。理解复制规则并遵守提示和限制，它能够对最佳操作过程做出有根据的决策。

它可能认识到，一个可用于促销的服务器也是一个理想的候选人，例如:

• 没有什么可以阻止服务器的升级 (用户可能已经暗示这样的服务器是首选的升级) ，以及
• 预计服务器能够将其所有兄弟服务器作为副本。

在这种情况下， orchestrator

Avec hard-stop-after, nous n'avons même pas besoin de la coopération du client, ce qui atténue les situations de division cérébrale. Il convient de noter que celle-ci n'est pas fermée et qu'un certain temps s'écoule avant que nous ne mettions fin à l'ancienne connexion. Mais passé un certain point, on se sent à l’aise et on ne s’attend pas à de mauvaises surprises.

Nous n'exigeons pas strictement que le consul soit de garde à tout moment. En fait, nous avons seulement besoin qu’il soit disponible en cas de basculement. Si Consul échoue, GLB continuera à fonctionner en utilisant les dernières valeurs connues et ne prendra pas de mesures drastiques.

GLB est configuré pour vérifier l'identité du maître nouvellement promu. Semblable à notre pool MySQL contextuel

, sera sur le serveur backend Vérifiez qu'il s'agit bien du nœud rédacteur. S'il nous arrive de supprimer l'identité du maître dans Consul, aucun problème ; les entrées vides sont ignorées. Si nous écrivons par erreur un nom non maître dans Consul, aucun problème GLB refusera de le mettre à jour et continuera à fonctionner dans le dernier état connu. Nous aborderons davantage le problème et poursuivrons les objectifs de HA dans les sections suivantes.

Détection de défauts Orchestral/RAFT

orchestrator en utilisant Approche holistique

pour détecter les pannes et donc très fiable. Nous n’avons observé aucun faux positif : nous n’avons eu aucun basculement prématuré et n’avons donc pas subi de temps d’arrêt inutiles. 🎜🎜orchestrator/raft aborde en outre le cas de l'isolation complète du réseau DC (c'est-à-dire la clôture DC). L'isolation du réseau DC peut prêter à confusion : les serveurs de ce DC peuvent communiquer entre eux. Le réseau d'autres DC est-il isolé des autres contrôleurs de domaine, ou le réseau des autres contrôleurs de domaine est-il isolé ? 🎜🎜Dans une configuration orchestrator/raft, le nœud leader raft est le nœud qui exécute le basculement. Le leader est le nœud qui bénéficie du soutien de la majorité du groupe (le quorum). Le déploiement de notre nœud de coordination est tel qu'aucun centre de données n'a la majorité, n'importe quel centre de données n-1 fera l'affaire. 🎜🎜Lorsque le réseau DC est complètement isolé, le nœud orchestrator du DC sera déconnecté des nœuds homologues des autres DC. Par conséquent, le nœud orchestrator dans un contrôleur de domaine orphelin ne peut pas devenir le leader du cluster raft. Si l’un de ces nœuds devient le leader, il se retirera. Un nouveau leader sera assigné à partir de n'importe quel autre DC. Ce leader sera soutenu par tous les autres DC pouvant communiquer entre eux. 🎜🎜Par conséquent, le nœud orchestrateur donnant les ordres sera un nœud extérieur au data center d'isolation du réseau. S'il y a un maître dans un DC autonome, orchestrator lancera un basculement, en le remplaçant par un serveur de l'un des DC disponibles. Nous atténuons l'isolement du DC en déléguant les décisions à un quorum dans un DC non isolé. 🎜

🎜Publicité plus rapide🎜🎜🎜Peut réduire davantage les temps d'arrêt globaux en publiant plus rapidement les modifications majeures. Comment y parvenir ? 🎜🎜Lorsque orchestrator démarre un basculement, il observe la file d'attente des serveurs disponibles pour la promotion. Comprendre les règles de réplication et respecter les conseils et les limites vous permet de prendre des décisions éclairées sur la meilleure marche à suivre. 🎜🎜On peut reconnaître qu'un serveur disponible en promotion est aussi un candidat idéal, par exemple : 🎜🎜🎜Rien n'empêche la mise à niveau du serveur (l'utilisateur a peut-être laissé entendre qu'un tel serveur est la mise à niveau privilégiée), et 🎜Un serveur devrait pouvoir avoir tous ses frères et sœurs comme répliques. 🎜Dans ce cas, orchestrator définit d'abord le serveur comme accessible en écriture, puis annonce immédiatement la promotion du serveur (dans notre cas, en écrivant au magasin Consul KV), même si la réparation de l'arbre de réplication démarre de manière asynchrone, cette opération prend généralement plusieurs secondes. 🎜🎜Il est probable que l'arborescence de réplication soit intacte avant que le serveur GLB ne soit complètement rechargé, mais ce n'est pas strictement obligatoire. Le serveur accepte très bien les écritures ! 🎜🎜🎜Réplication semi-synchrone🎜🎜🎜Dans la 🎜réplication semi-synchrone🎜 de MySQL, le maître n'accuse pas les validations de transaction tant que les modifications ne sont pas connues comme ayant été envoyées à une ou plusieurs répliques. Il fournit un moyen d'obtenir un basculement sans perte : toutes les modifications appliquées au serveur principal sont soit appliquées au serveur principal, soit attendent d'être appliquées à l'une des répliques. 🎜

La cohérence a un coût : le risque de disponibilité. Si aucune réplique n'accuse réception des modifications, le maître bloque et arrête l'écriture. Heureusement, il existe une configuration de délai d'attente après laquelle le maître peut revenir en mode de réplication asynchrone, rendant ainsi les écritures à nouveau disponibles.

Nous avons fixé le délai d'attente à une valeur raisonnablement basse : 500ms. Il suffit d’envoyer les modifications de la réplique principale du DC à la réplique DC locale ainsi qu’au DC distant. Avec ce timeout, nous pouvons observer un comportement semi-synchrone parfait (pas de repli vers la réplication asynchrone) et pouvons facilement utiliser des périodes de blocage très courtes en cas d'échec d'acquittement. 500ms。将更改从主 DC 副本发送到本地 DC 副本，通常也发送到远程 DC，这已经足够了。通过这个超时，我们可以观察到完美的半同步行为 (没有退回到异步复制) ，并且在确认失败的情况下可以很轻松地使用非常短的阻塞周期。

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

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

注入心跳

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

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

orchestrator 所有权委托

我们进一步 orchestrator:

• 注入 Pseudo-GTID ,
• 将提升的 master 设置为可写，清除其复制状态，以及，
• 如果可能，将旧主服务器设置为 read_only。

在所有的新 master 的基础上，这减少了摩擦。一个刚刚被提升的 master 显然应该是有生命力，并且可以被接受的，否则我们不会提升它。因此，让 orchestrator 直接讲更改应用于提升的 msater 是有意义的。

orchestrator 所有权委托

我们进一步 orchestrator：

• Pseudo-GTID 注入，
• 将提升的 master 设置为可写，清除其复制状态，以及，
• 如果可能，将旧的 master 设置为 read_only。

在所有的新 master 的基础上，这减少了摩擦。一个刚刚被提升的 master 显然应该是有活力，并且可以被接受的，否则我们不会提升它。因此，让 orchestrator

Nous activons la semi-synchronisation sur la réplique DC locale et en cas de décès du maître, nous nous attendons (bien que nous n'appliquions pas strictement) un basculement sans perte. Le basculement sans perte d’un défaut DC complet coûte cher et nous ne nous y attendons pas.

En expérimentant des délais d'attente semi-synchrones, nous avons également observé un comportement qui a joué en notre faveur : en cas d'échec primaire, nous avons pu influencer l'identité du candidat idéal. En activant la semi-synchronisation sur des serveurs désignés et en les marquant comme serveurs candidats, nous sommes en mesure de réduire les temps d'arrêt globaux en influençant l'issue d'une panne. Dans nos expériences nous avons observé que nous nous retrouvons généralement avec des candidats idéauxpour faire passer le message rapidement.

Inject heartbeat

Nous ne gérons pas le démarrage/arrêt du service pt-heart sur l'hôte mis à niveau/déclassé, mais choisissons de le faire n'importe où à à tout moment, exécutez-le. Cela nécessite quelques patch

afin d'activer pt-heart Accommodates situations dans lesquelles le serveur passe d'avant en arrière en read_only (état de lecture seule) ou plante complètement. Dans notre configuration actuelle, le service pt-heart s'exécute sur le maître et les répliques. Sur l'hôte, ils génèrent des événements de battement de cœur. Sur les répliques, ils identifient les serveurs comme read_only et revérifient périodiquement leur état. Une fois qu'un serveur est promu maître, pt-heart sur ce serveur identifie le serveur comme étant accessible en écriture et commence à injecter des événements de battement de cœur.

Délégation de propriété de l'orchestrateur

Nous en outre orchestrateur :

• Injecter le pseudo-GTID,
• Définir le maître promu pour qu'il soit accessible en écriture et effacer sa réplication status, et,
• Si possible, définissez l'ancien maître sur read_only.

En plus de tous les nouveaux masters, cela réduit les frictions. Un maître nouvellement promu doit évidemment être vivant et acceptable, sinon nous ne le promouvrons pas. Par conséquent, il est logique de laisser l'orchestrateur parler directement de la modification du msater qui doit être appliqué au boost.

Délégation de propriété de l'orchestrateur🎜🎜🎜Nous avons en outre l'orchestrateur : 🎜

• Injection pseudo-GTID,
• définissez le maître élevé sur accessible en écriture, effacez-le Statut de réplication , et
• Si possible, définissez l'ancien maître sur read_only.

🎜En plus de tous les nouveaux masters, cela réduit les frictions. Un master nouvellement promu doit évidemment être actif et acceptable, sinon nous n'en ferons pas la promotion. Par conséquent, il est logique que l'orchestrateur applique les modifications directement au msater promu. 🎜🎜🎜Limitations et inconvénients🎜🎜🎜La couche proxy rend l'identité du serveur maître inconnue de l'application, mais elle masque également l'identité du serveur maître de l'application. Tout ce qui est principalement visible, c'est la connexion provenant de la couche proxy, et nous perdons des informations sur l'origine réelle de la connexion. 🎜🎜Avec le développement des systèmes distribués, nous sommes toujours confrontés à des scénarios non gérés. 🎜🎜Il convient de noter que dans un scénario d'isolement de centre de données, en supposant que le serveur principal soit situé dans un contrôleur de domaine isolé, les applications de ce contrôleur de domaine sont toujours capables d'écrire sur le serveur principal. Cela peut conduire à un état incohérent une fois le réseau restauré. Nous travaillons à atténuer cette division du cerveau en mettant en œuvre un 🎜STONITH🎜 fiable et très isolé de l'intérieur du DC. Comme auparavant, il faudra un certain temps avant que les primaires ne soient détruites, et il pourrait y avoir une brève période de division cérébrale. Le coût opérationnel pour éviter la division du cerveau est très élevé. 🎜🎜Il existe de nombreux autres cas : arrêt du service consul en cas de basculement ; isolation partielle du DC, autres cas ; Nous savons qu'il est impossible de corriger toutes les vulnérabilités d'un système distribué de cette nature, c'est pourquoi nous nous concentrons sur les cas les plus importants. 🎜🎜🎜Conclusion🎜🎜🎜Notre coordinateur/GLB/Consul nous a fourni :🎜

• Détection fiable des pannes,
• basculement indépendant du centre de données,
• basculement généralement sans perte,
• prise en charge de l'isolation du réseau du centre de données,
• atténuation du split-brain (plus de résultats de travail),
• ne dépend pas de la collaboration,
• Dans la plupart des cas , la durée totale d'interruption est comprise entre 10 et 13 secondes. 10 and 13 seconds 之间。
  • 在不常见的情况下，我们最多可以看到 20 seconds 的总停机时间，在极端情况下则可以看到最多 25 seconds
  Dans des cas rares, nous pouvons constater jusqu'à 20 secondes de temps d'arrêt total, et dans les cas extrêmes jusqu'à 25 secondes de temps d'arrêt.

Conclusion

Le paradigme de découverte orchestration/agent/service utilise des composants bien connus et fiables dans une architecture découplée, ce qui le rend plus facile à déployer, à exploiter et à observer, et chaque composant peut s'étendre vers le haut ou vers le bas. indépendamment. Nous pouvons constamment tester les paramètres et rechercher des améliorations.

Adresse originale : https://github.blog/2018-06-20-mysql-high-availability-at-github/

Adresse de traduction : https://learnku.com/mysql/t/36820

【Recommandations associées : tutoriel vidéo mysql

】🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!