Orchestrator pour MySQL: pourquoi un projet à sécurité intégrée ne peut pas être construit sans lui

Tout projet majeur a commencé avec une paire de serveurs. Tout d'abord, il y avait un serveur DB, puis des esclaves y ont été ajoutés pour mettre à l'échelle la lecture. Et ici - arrêtez! Un maître, mais beaucoup d'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 dans le soap lèvent le serveur. Que faire? Réservez le maître. Mon collègue Pavel a déjà écrit un article à ce sujet , je ne le répéterai pas. Au lieu de cela, je vais vous expliquer pourquoi vous avez absolument besoin d'un orchestrateur pour MySQL!

Commençons par la question principale: "Comment allons-nous changer le code sur une nouvelle machine lorsque l'assistant quittera?"

• Le schéma avec VIP (Virtual IP) que j'aime le plus, nous en parlerons ci-dessous. C'est le plus simple et le plus évident, bien qu'il ait une limitation évidente: le maître, que nous réserverons, doit être dans le segment L2 avec une nouvelle machine, c'est-à-dire que vous pouvez oublier le deuxième DC. Et, dans le bon sens, si vous suivez la règle selon laquelle les grands L2 sont mauvais, car L2 est uniquement par rack, et entre les racks L3, et un tel schéma a encore plus de restrictions.
• Vous pouvez enregistrer un nom DNS dans le code et le résoudre via / etc / hosts. En fait, il n'y aura pas de résolution. Avantage du schéma: il n'y a pas de caractéristique de restriction de la première méthode, c'est-à-dire qu'il est également possible d'organiser des DC croisés. Mais alors la question évidente se pose, à quelle vitesse grâce à Puppet-Ansible nous pouvons apporter la modification à / etc / hosts.
• Vous pouvez changer un peu la deuxième méthode: sur tous les serveurs Web, nous mettons la mise en cache DNS, par laquelle le code ira à la base de données master. Vous pouvez enregistrer TTL 60 pour cette entrée DNS. Il semble qu'avec une implémentation correcte, la méthode soit bonne.
• Schéma avec découverte de service, impliquant l'utilisation de Consul et etcd.
• Une option intéressante avec ProxySQL . Il est nécessaire d'envelopper tout le trafic vers MySQL via ProxySQL, ProxySQL peut déterminer qui est le maître maintenant. Soit dit en passant, une des options d'utilisation de ce produit se trouve dans mon article .

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

Schéma d'infrastructure typique:

Je décrirai immédiatement les situations évidentes à considérer:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• Tous les esclaves doivent avoir read_only = 1, et dès que vous promouvez l'esclave au maître, il doit avoir read_only = 0.
• N'oubliez pas que tout esclave que nous avons choisi pour cela peut devenir un maître (Orchestrator a tout un mécanisme de préférence, lequel esclave doit être considéré comme candidat à un nouveau maître en premier lieu, lequel en deuxième lieu, et quel esclave ne doit en aucun cas être sélectionné du tout. Maître). Si l'esclave devient maître, la charge esclave y restera et la charge maître sera ajoutée, cela doit être pris en compte.

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

• Orchestrator possède 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 se trouvent derrière et où la réplication est interrompue (nous avons des scripts pour envoyer des SMS à Orchestrator).
• Orchestrator vous indique quelles diapositives présentent une erreur erronée GTID.

Interface de l'orchestrateur:

Qu'est-ce qu'un GTID errant?

Orchestrator a deux exigences de base pour fonctionner:

• 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 que partout où il y a un type de binlogs, vous pouvez déclarer. Nous avions une telle configuration dans laquelle Row était sur le maître et sur la plupart des esclaves, et le mode mixte restait historiquement sur deux. Par conséquent, Orchestrator ne voulait tout simplement pas connecter ces esclaves au nouveau maître.

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

Ainsi, Orchestrator vous montre à travers une erreur erronée GTID qu'il y a des transactions sur l'esclave qui ne sont pas sur l'assistant. Pourquoi ça arrive?

• Read_only = 1 n'est pas activé sur l'esclave, quelqu'un s'est connecté et a exécuté une demande de changement de données.
• Super_read_only = 1 n'est pas activé sur l'esclave, puis l'administrateur, après avoir mélangé le serveur, est entré et y a exécuté une demande.
• Si vous avez pris en compte les deux paragraphes précédents, il y a une astuce de plus: dans MySQL, la demande de vidage des journaux de vol tombe également dans le journal de bord, donc lorsque vous rincez la première fois, un GTID errant apparaîtra sur l'assistant et sur tous les esclaves. Comment éviter cela? Dans perona-5.7.25-28, le paramètre binlog_skip_flush_commands = 1 est apparu, ce qui interdit l'écriture de vidage dans les journaux bin. Il y a un bug dans mysql.com .

Je résume tout ce qui précède. Si vous ne souhaitez pas encore utiliser Orchestrator en mode de basculement, mettez-le en mode de surveillance. Ensuite, vous aurez toujours sous les yeux une carte de l'interaction des machines MySQL et des informations claires sur le type de réplication sur chaque machine, si les esclaves sont derrière, et surtout - combien de cohérence ils ont avec le maître!

La question évidente est: "Comment devrait fonctionner Orchestrator?" Il doit sélectionner un nouveau maître parmi les esclaves actuels, puis reconnecter tous les esclaves à celui-ci (c'est à cela que sert GTID; si vous utilisez l'ancien mécanisme avec binlog_name et binlog_pos, puis commuter l'esclave du maître actuel au nouveau est tout simplement impossible!). Avant qu'Orchestrator ne vienne à nous, j'ai dû faire tout cela manuellement. Le vieux maître s'est écrasé à cause d'un contrôleur Adaptec buggy, il avait environ 10 esclaves. Je devais transférer le VIP du maître à l'un des esclaves et reconnecter tous les autres esclaves à celui-ci. Combien de consoles j'ai dû ouvrir, combien de commandes simultanées pour entrer ... J'ai dû attendre jusqu'à 3 heures du matin, retirer la charge de tous les esclaves, sauf deux, faire la première voiture sur deux maîtres, y brancher immédiatement la deuxième voiture,par conséquent, ramassez tous les autres esclaves vers le nouveau maître et renvoyez la charge. En général, l'horreur ...

Comment fonctionne Orchestrator lorsqu'il passe en mode de basculement? Cela est plus facilement démontré par l'exemple d'une situation où nous voulons faire d'un maître une machine plus puissante et plus moderne que maintenant.

La figure montre le milieu du processus. Qu'est-ce qui a déjà été fait jusqu'à présent? Nous avons dit que nous voulons faire d'une sorte d'esclave un nouveau maître, Orchestrator vient de commencer à reconnecter tous les autres esclaves et le nouveau maître agit comme une machine de transit. Avec ce schéma, les erreurs ne se produisent pas, tous les esclaves fonctionnent, Orchestrator supprime le VIP de l'ancien maître, transfère vers le nouveau, fait read_only = 0 et oublie l'ancien maître. Tout! Le temps d'arrêt de notre service est le temps de transfert VIP, c'est 2-3 secondes.

C'est tout pour aujourd'hui, merci à tous. Bientôt, il y aura un deuxième article sur Orchestrator. Dans le célèbre film soviétique "The Garage", un héros a dit: "Je n'irais pas en reconnaissance avec lui!" Alors, Orchestrator, je t'accompagne pour faire du scoutisme!