Orchestrator pour MySQL : pourquoi vous ne pouvez pas créer un projet tolérant aux pannes sans lui

Tout grand projet a démarré avec quelques serveurs. Au début, il y avait un serveur de base de données, puis des esclaves y ont été ajoutés pour adapter la lecture. Et puis - arrêtez ! Il y a un maître, mais il y a plusieurs esclaves ; si l'un des esclaves part, alors tout ira bien, mais si le maître part, ce sera mauvais : temps d'arrêt, les administrateurs essaient de relancer le serveur. Ce qu'il faut faire? Réservez un maître. Mon collègue Pavel a déjà écrit à ce sujet статью, je ne le répéterai pas. Au lieu de cela, je vais vous expliquer pourquoi vous avez absolument besoin d'Orchestrator pour MySQL !

Commençons par la question principale : « Comment allons-nous transférer le code sur une nouvelle machine lorsque le maître partira ?

• J'aime le plus le schéma avec VIP (Virtual IP), nous en parlerons ci-dessous. C'est le plus simple et le plus évident, même s'il a une limitation évidente : le master que nous réserverons doit être dans le segment L2 avec la nouvelle machine, c'est-à-dire que nous pouvons oublier le deuxième DC. Et, à l'amiable, si vous suivez la règle selon laquelle un grand L2 est mauvais, car L2 est uniquement par rack et L3 est entre les racks, et un tel schéma a encore plus de restrictions.
• Vous pouvez écrire un nom DNS dans le code et le résoudre via /etc/hosts. En fait, il n’y aura pas de résolution. L'avantage du schéma : il n'y a pas de limitation caractéristique de la première méthode, c'est-à-dire qu'il est possible d'organiser un cross-DC. Mais alors la question évidente se pose : à quelle vitesse pouvons-nous apporter la modification à /etc/hosts via Puppet-Ansible ?
• Vous pouvez modifier un peu la deuxième méthode : installer une mise en cache DNS sur tous les serveurs Web, via lesquels le code ira à la base de données principale. Vous pouvez définir TTL 60 pour cette entrée dans DNS. Il semble que si elle est correctement appliquée, la méthode est bonne.
• Un schéma avec découverte de services, impliquant l'utilisation de Consul et etcd.
• Une option intéressante avec ProxySQL. Vous devez acheminer tout le trafic vers MySQL via ProxySQL ; ProxySQL lui-même peut déterminer qui est le maître. À propos, vous pouvez en savoir plus sur l'une des options d'utilisation de ce produit dans mon article.

L'auteur d'Orchestrator, travaillant sur Github, a d'abord implémenté le premier schéma avec VIP, puis l'a converti en un schéma avec consul.

Disposition typique de l'infrastructure :

Je décrirai immédiatement les situations évidentes dont il faut tenir compte :

• L'adresse VIP ne doit être enregistrée dans la configuration sur aucun des serveurs. Imaginons une situation : le maître a redémarré et, pendant le chargement, Orchestrator est passé en mode de basculement et a fait de l'un des esclaves le maître ; puis le vieux maître s'est levé, et maintenant le VIP est sur deux voitures. C'est mauvais.
• Pour l'orchestrateur, vous devrez écrire un script pour appeler l'ancien maître et le nouveau maître. Sur l'ancien maître, vous devez exécuter ifdown et sur le nouveau maître – ifup vip. Ce serait bien d'inclure également dans ce script qu'en cas de basculement, le port sur l'ancien switch maître est simplement désactivé pour éviter tout splitbrain.
• Une fois qu'Orchestrator a appelé votre script pour d'abord supprimer le VIP et/ou éteindre le port sur le commutateur, puis appelé le script d'augmentation du VIP sur le nouveau maître, n'oubliez pas d'utiliser la commande arping pour dire à tout le monde que le nouveau VIP est maintenant ici.
• Tous les esclaves doivent avoir read_only=1, et dès que vous promouvez l'esclave au rang de maître, il doit avoir read_only=0.
• N'oubliez pas que n'importe quel esclave que nous avons choisi pour cela peut devenir maître (Orchestrator a tout un mécanisme de préférence pour quel esclave considérer comme candidat à un nouveau maître en premier lieu, lequel en second lieu, et quel esclave doit ne sera en aucun cas sélectionné comme maître). Si l'esclave devient maître, alors la charge de l'esclave restera sur lui et la charge du maître s'ajoutera, il faut en tenir compte.

Pourquoi avez-vous besoin d’Orchestrator si vous n’en avez pas ?

• Orchestrator dispose d'une interface graphique très conviviale qui affiche l'intégralité de la topologie (voir capture d'écran ci-dessous).
• Orchestrator peut suivre quels esclaves sont à la traîne et où la réplication est généralement en panne (nous avons des scripts attachés à Orchestrator pour l'envoi de SMS).
• Orchestrator vous indique quels esclaves ont un GTID errant.

Interface de l'orchestrateur :

Qu'est-ce que le GTID errant ?

Le fonctionnement d’Orchestrator requiert deux conditions principales :

• Il est nécessaire que le pseudo GTID soit activé sur toutes les machines du cluster MySQL ; nous avons GTID activé.
• Il est nécessaire qu'il y ait un seul type de binlogs partout, vous pouvez utiliser une instruction. Nous avions une configuration dans laquelle le maître et la plupart des esclaves avaient Row, et deux restaient historiquement en mode Mixte. Par conséquent, Orchestrator ne souhaitait tout simplement pas connecter ces esclaves au nouveau maître.

N'oubliez pas que le plus important chez un esclave de production est sa cohérence avec le maître ! Si l'ID de transaction globale (GTID) est activé à la fois sur votre maître et votre esclave, vous pouvez utiliser la fonction gtid_subset pour savoir si les mêmes demandes de modifications de données ont réellement été exécutées sur ces machines. Vous pouvez en savoir plus à ce sujet ici.

Ainsi, Orchestrator vous montre à travers le GTID errant qu'il y a des transactions sur l'esclave qui ne sont pas sur le maître. Pourquoi cela arrive-t-il?

• Read_only=1 n'est pas activé sur l'esclave, quelqu'un s'est connecté et a effectué une demande de modification des données.
• Super_read_only=1 n'est pas activé sur l'esclave, puis l'administrateur, après avoir confondu le serveur, est entré et y a exécuté la requête.
• Si vous avez pris en compte les deux points précédents, alors il y a encore une astuce : dans MySQL, une demande de vidage des binlogs va également au binlog, donc au premier vidage, un GTID errant apparaîtra sur le maître et tous les esclaves. Comment éviter cela ? Perona-5.7.25-28 a introduit le paramètre binlog_skip_flush_commands=1, qui interdit l'écriture de vidage dans les binlogs. Il y en a un établi sur le site mysql.com bug.

Permettez-moi de résumer tout ce qui précède. Si vous ne souhaitez pas encore utiliser Orchestrator en mode basculement, mettez-le en mode observation. Ensuite, vous aurez toujours sous les yeux une carte de l'interaction des machines MySQL et des informations visuelles sur le type de réplication sur chaque machine, si les esclaves sont en retard et, surtout, dans quelle mesure ils sont cohérents avec le maître !

La question évidente est la suivante : « Comment devrait fonctionner Orchestrator ? » Il doit sélectionner un nouveau maître parmi les esclaves actuels, puis y reconnecter tous les esclaves (c'est pour cela que GTID est nécessaire ; si vous utilisez l'ancien mécanisme avec binlog_name et binlog_pos, alors basculer un esclave du maître actuel vers un nouveau est tout simplement impossible !). Avant d’avoir Orchestrator, je devais faire tout cela manuellement. L'ancien maître était bloqué à cause d'un contrôleur Adaptec buggé ; il avait environ 10 esclaves. Je devais transférer VIP du maître vers l'un des esclaves et y reconnecter tous les autres esclaves. Combien de consoles ai-je dû ouvrir, combien de commandes simultanées ai-je saisies... J'ai dû attendre jusqu'à 3 heures du matin, retirer la charge de tous les esclaves sauf deux, rendre la première machine des deux maître, attacher immédiatement la deuxième machine à lui, attachez donc tous les autres esclaves au nouveau maître et renvoyez la charge. Dans l'ensemble, c'est horrible...

Comment fonctionne Orchestrator lorsqu’il passe en mode de basculement ? Ceci est plus facilement illustré par un exemple de situation dans laquelle nous voulons faire d'un maître une machine plus puissante et plus moderne que celle dont nous disposons actuellement.

La figure montre le milieu du processus. Qu'est-ce qui a déjà été fait jusqu'à présent ? Nous avons dit que nous voulions faire d'un esclave le nouveau maître, Orchestrator a simplement commencé à y reconnecter tous les autres esclaves, le nouveau maître agissant comme une machine de transit. Avec ce schéma, aucune erreur ne se produit, tous les esclaves fonctionnent, Orchestrator supprime le VIP de l'ancien maître, le transfère vers le nouveau, rend read_only=0 et oublie l'ancien maître. Tous! Le temps d'arrêt de notre service est le temps de transfert VIP, qui est de 2 à 3 secondes.

C'est tout pour aujourd'hui, merci à tous. Il y aura bientôt un deuxième article sur Orchestrator. Dans le célèbre film soviétique « Garage », un personnage a déclaré : « Je n’irais pas en reconnaissance avec lui ! » Alors, Orchestrator, je t'accompagnerais en reconnaissance !

Source: habr.com