Tout grand projet a démarré avec quelques serveurs. Au départ, il y avait un serveur de base de données, puis des esclaves ont été ajoutés pour optimiser la lecture. Et puis… stop ! Il y a un maître, mais de nombreux esclaves ; si l'un des esclaves quitte le serveur, tout ira bien, mais si le maître quitte le serveur, ce sera un désastre : interruption de service, les administrateurs, dans leurs bulles de savon, relancent le serveur. Que faire ? Sauvegarder le maître. Mon collègue Pavel a déjà écrit à ce sujet. Je ne vais pas le répéter. Je vais plutôt vous expliquer pourquoi vous avez absolument besoin d'Orchestrator pour MySQL !
Commençons par la question principale : « Comment allons-nous transférer le code vers une nouvelle machine lorsque le maître partira ? »
- J'apprécie particulièrement le schéma VIP (IP virtuelle), dont nous parlerons plus loin. C'est le plus simple et le plus évident, même s'il présente une limite évidente : le maître à sauvegarder doit se trouver dans le segment L2 d'une nouvelle machine ; autrement dit, on peut oublier le second contrôleur de domaine. Et, dans le bon sens du terme, si l'on suit la règle selon laquelle un L2 trop grand est néfaste, car L2 est réservé au rack, et L3 entre les racks, ce schéma présente encore plus de limites.
- Vous pouvez écrire le nom DNS dans le code et le résoudre via /etc/hosts. En réalité, il n'y aura aucune résolution. L'avantage de cette méthode est qu'elle ne présente aucune limitation typique de la première méthode, ce qui permet une organisation inter-DC. Mais une question évidente se pose alors : à quelle vitesse pouvons-nous apporter la modification à /etc/hosts via Puppet-Ansible ?
- La deuxième méthode peut être légèrement modifiée : sur tous les serveurs web, nous installons un DNS de mise en cache, via lequel le code sera transmis à la base de données principale. Vous pouvez spécifier une durée de vie de 60 % pour cette entrée dans le DNS. Il semble que, si elle est correctement implémentée, cette méthode soit efficace.
- Un schéma avec découverte de services, qui implique l'utilisation de Consul et etcd.
- Option intéressante avec Tout le trafic vers MySQL doit être encapsulé via ProxySQL. ProxySQL lui-même peut désormais déterminer qui est le maître. D'ailleurs, vous trouverez une description de l'une des options d'utilisation de ce produit dans mon article. .
L'auteur d'Orchestrator, travaillant chez Github, a d'abord implémenté le premier schéma avec VIP, puis l'a converti en schéma avec consul.
Schéma d'infrastructure typique :
Je vais décrire immédiatement les situations évidentes dont il faut tenir compte :
- L'adresse VIP ne doit être spécifiée dans la configuration d'aucun serveur. Imaginons une situation : le maître a redémarré et, pendant son chargement, Orchestrator est passé en mode de basculement et a fait de l'un des esclaves le maître ; l'ancien maître est alors revenu, et le VIP est maintenant sur deux machines. C'est un problème.
- Pour l'orchestrateur, vous devrez écrire un script pour contacter l'ancien et le nouveau maître. Sur l'ancien maître, vous devrez exécuter ifdown, et sur le nouveau maître, ifup vip. Il serait également judicieux d'inclure dans ce script qu'en cas de basculement, le port du commutateur de l'ancien maître est simplement désactivé afin d'éviter tout splitbrain.
- Une fois qu'Orchestrator a appelé votre script pour d'abord supprimer le VIP et/ou fermer le port sur le commutateur, puis a appelé le script VIP-up sur le nouveau maître, n'oubliez pas d'effectuer un arping pour dire à tout le monde que le nouveau VIP est maintenant là.
- Tous les esclaves doivent avoir read_only=1, et dès que vous promouvez un esclave en maître, il doit avoir read_only=0.
- N'oubliez pas que tout esclave choisi peut devenir maître (Orchestrator dispose d'un mécanisme de préférence complet : quel esclave choisir en premier, quel esclave en second, et quel esclave ne doit en aucun cas être choisi comme maître). Si un esclave devient maître, la charge de l'esclave restera sur lui et la charge du maître sera ajoutée ; il faut en tenir compte.
Pourquoi avez-vous besoin d'Orchestrator si vous ne l'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 les esclaves qui ont pris du retard et ceux où la réplication est complètement interrompue (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 GTID errant ?
Il y a deux exigences principales pour qu'Orchestrator fonctionne :
- Il est nécessaire que le pseudo GTID soit activé sur toutes les machines du cluster MySQL ; nous avons activé le GTID.
- Il est nécessaire qu'il existe un seul type de journaux binaires partout, ce qui est possible. Nous avions une configuration où le maître et la plupart des esclaves étaient en mode ligne, et deux d'entre eux 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 l'élément le plus important pour un esclave de production est sa cohérence avec le maître ! Si l'ID de transaction global (GTID) est activé sur le maître et l'esclave, vous pouvez utiliser la fonction gtid_subset pour vérifier si les mêmes demandes de modification de données ont été exécutées sur ces machines. Pour en savoir plus, consultez ce lien. .
Orchestrator vous indique, via un GTID erroné, que des transactions sont présentes sur l'esclave et non sur le maître. Pourquoi cela se produit-il ?
- L'esclave n'a pas read_only=1 activé, quelqu'un s'est connecté et a effectué une demande de modification des données.
- L'esclave n'a pas super_read_only=1 activé, donc l'administrateur, ayant confondu le serveur, est entré et a exécuté la requête là-bas.
- Si vous avez pris en compte les deux points précédents, il existe une autre astuce : dans MySQL, une requête de vidage des journaux binaires est également enregistrée dans le journal binaire. Ainsi, le premier vidage sur le maître et tous les esclaves entraînera une erreur de GTID. Comment éviter cela ? Dans perona-5.7.25-28, un paramètre binlog_skip_flush_commands=1 est apparu, interdisant l'écriture de vidages dans les journaux binaires. Une configuration est disponible sur le site web mysql.com. .
Pour résumer, si vous ne souhaitez pas encore utiliser Orchestrator en mode de basculement, configurez-le en mode de surveillance. Vous disposerez ainsi en permanence d'une carte des interactions entre les machines MySQL et d'informations visuelles sur le type de réplication sur chaque machine, les retards éventuels des esclaves et, surtout, leur cohérence avec le maître !
La question évidente est : « Comment Orchestrator devrait-il fonctionner ? » Il devrait sélectionner un nouveau maître parmi les esclaves actuels, puis y reconnecter tous les esclaves (c'est à cela que sert le GTID ; si vous utilisez l'ancien mécanisme avec binlog_name et binlog_pos, il est tout simplement impossible de basculer un esclave du maître actuel vers un nouveau !). Avant Orchestrator, je devais faire tout cela manuellement. L'ancien maître plantait à cause d'un contrôleur Adaptec buggé, il avait environ 10 esclaves. Je devais transférer le VIP du maître vers l'un des esclaves et y reconnecter tous les autres. Combien de consoles devais-je ouvrir, combien de commandes simultanées devais-je saisir… J'ai dû attendre jusqu'à 3 h du matin, déconnecter tous les esclaves sauf deux, faire de la première machine le maître, y connecter immédiatement la deuxième machine, puis connecter tous les autres esclaves au nouveau maître et reconnecter la charge. En général, c'était épouvantable…
Comment Orchestrator fonctionne-t-il lorsqu'il passe en mode de basculement ? L'exemple le plus simple est celui où l'on souhaite doter le maître d'une machine plus puissante et plus moderne que celle dont il dispose actuellement.
L'image montre le milieu du processus. Qu'a-t-on déjà fait jusqu'à présent ? Nous avons indiqué que nous souhaitions transformer un esclave en nouveau maître. Orchestrator a simplement commencé à reconnecter tous les autres esclaves à ce dernier, le nouveau maître faisant office de 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 au nouveau, définit read_only=0 et oublie l'ancien maître. Et voilà ! Le temps d'arrêt de notre service correspond au temps de transfert du VIP, soit 2 à 3 secondes.
C'est tout pour aujourd'hui, merci à tous. Bientôt un deuxième article sur Orchestrator. Dans le célèbre film soviétique « Garage », un personnage disait : « Je n'irais pas en reconnaissance avec lui ! » Eh bien, Orchestrator, j'irais en reconnaissance avec toi !
Source: habr.com
