Dans CityMobile, nous utilisons la base de données MySQL comme stockage principal pour les données persistantes. Nous avons plusieurs clusters de bases de données pour différents services et objectifs.

La disponibilité constante de l'assistant est un indicateur critique de la santé de l'ensemble du système et de ses différentes parties. La récupération automatique du cluster en cas de défaillance de l'assistant réduit considérablement le temps de réponse aux incidents et les temps d'arrêt du système. Dans cet article, je vais regarder un cluster MySQL HA basé sur MySQL Orchestrator et des adresses IP virtuelles (VIP).

Solution VIP HA

Je vais d'abord parler brièvement de ce à quoi ressemble notre système de stockage de données.

Nous utilisons le schéma de réplication classique avec un assistant en écriture seule et de nombreuses répliques en lecture seule. Un cluster peut contenir un maître intermédiaire - un nœud qui est à la fois une réplique et un maître pour les autres. Les clients accèdent aux répliques via HAProxy, ce qui permet une répartition uniforme de la charge et une évolutivité aisée. L'utilisation de HAProxy est due à des raisons historiques, et maintenant nous sommes en train de migrer vers ProxySQL.

La réplication est semi-synchrone basée surGTID. Cela signifie qu'au moins une réplique doit écrire la transaction dans le journal avant qu'elle ne soit considérée comme réussie. Ce mode de réplication offre un équilibre optimal entre performances et sécurité des données en cas de panne du nœud principal. Fondamentalement, toutes les modifications sont transférées du maître aux répliques à l'aide Row Based Replication (RBR), mais certains nœuds peuvent l'être mixed binlog format.

L'orchestrateur met à jour périodiquement l'état de la topologie du cluster, analyse les informations reçues et, en cas de problème, peut démarrer la procédure de récupération automatique. Le développeur est responsable de la procédure elle-même, car elle peut être implémentée de différentes manières: basée sur VIP, DNS, en utilisant des services de découverte de services ou des mécanismes autonomes.

L'une des façons les plus simples de restaurer un assistant en cas d'échec consiste à utiliser des adresses VIP flottantes.

Ce que vous devez savoir sur cette solution avant de poursuivre:

VIP est une adresse IP qui n'est pas liée à une interface réseau physique spécifique. Lorsqu'un nœud tombe en panne ou pendant un travail planifié, nous pouvons basculer le VIP vers une autre ressource avec un temps d'arrêt minimal.
La publication et la délivrance d'une adresse IP virtuelle est une opération rapide et bon marché.
Pour travailler avec le VIP, il faut accéder au serveur via SSH ou utiliser des outils spéciaux, par exemple keepalived.

Nous examinerons les problèmes possibles avec notre maître et imaginerons comment le mécanisme de récupération automatique devrait fonctionner.

La connectivité réseau au maître a disparu ou un problème est survenu au niveau matériel et le serveur n'est pas disponible

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
Toutes les nouvelles connexions sont immédiatement redirigées vers le nouveau maître. Les anciennes connexions échouent, des appels répétés sont effectués vers la base de données au niveau de l'application.

Le serveur fonctionne en mode normal; une défaillance s'est produite au niveau du SGBD

L'algorithme est similaire au cas précédent: mise à jour de la topologie et démarrage du processus de récupération. Puisque le serveur est disponible, nous libérons avec succès le VIP sur l'ancien maître, le transférons vers le nouveau et envoyons plusieurs requêtes ARP. Le retour possible de l'ancien assistant ne devrait pas affecter le cluster reconstruit et le fonctionnement de l'application.

D'autres problèmes

La défaillance des répliques ou des maîtres intermédiaires ne conduit pas à des actions automatiques et nécessite une intervention manuelle.

L'interface réseau virtuelle est toujours ajoutée temporairement, c'est-à-dire qu'après le redémarrage, le serveur VIP n'est pas automatiquement attribué. Chaque instance de la base de données est lancée par défaut en mode lecture seule, l'orchestrateur bascule automatiquement le nouveau maître en enregistrement et essaie de l'installer read onlysur l'ancien maître. Ces actions visent à réduire la probabilité split brain.

Au cours du processus de récupération, des problèmes peuvent survenir, qui doivent également être notifiés via l'interface utilisateur de l'orchestrateur en plus des outils de surveillance standard. Nous avons étendu l'API REST en ajoutant cette fonctionnalité ( PR est actuellement à l'étude).

Le schéma général de la solution HA est présenté ci-dessous.

Choisir un nouvel assistant

L'orchestre est assez intelligent et essaie de choisir la réplique la plus appropriée en tant que nouveau maître selon les critères suivants:

décalage de la réplique du maître;
Assistant MySQL et version réplique;
type de réplication (RBR, SBR ou mixte);
emplacement dans un ou plusieurs centres de données;
disponibilité errant GTID- transactions effectuées sur la réplique et absentes sur le maître;
des règles de sélection personnalisées sont également prises en compte.

Toutes les répliques ne sont pas un candidat idéal pour le rôle de maître. Par exemple, une réplique peut être utilisée pour sauvegarder des données, ou le serveur a une configuration matérielle plus faible. L'orchestrateur prend en charge les règles manuelles par lesquelles vous pouvez ajuster vos préférences pour choisir un candidat parmi les plus préférés ou ignorés.

Temps de réponse et de récupération

En cas d'incident, il est important de minimiser le temps d'arrêt du système, par conséquent, nous considérons les paramètres MySQL qui affectent la construction et la mise à jour de la topologie du cluster par l'orchestre:

slave_net_timeout- le nombre de secondes pendant lesquelles la réplique attend de nouvelles données ou un signal de pulsation du maître avant que la connexion ne soit reconnue comme perdue et que la reconnexion soit effectuée. Plus la valeur est faible, plus la réplique pourra déterminer rapidement que la connexion avec le maître est rompue. Nous définissons cette valeur sur 5 secondes.
MASTER_CONNECT_RETRY- le nombre de secondes entre les tentatives de reconnexion. En cas de problèmes de réseau, une valeur faible de ce paramètre vous permettra de vous reconnecter rapidement et d'empêcher le démarrage du processus de récupération du cluster. La valeur recommandée est de 1 seconde.
MASTER_RETRY_COUNT - Le nombre maximum de tentatives de reconnexion.
MASTER_HEARTBEAT_PERIOD- l'intervalle en secondes après lequel le maître envoie un signal de rythme cardiaque. La valeur par défaut est la moitié de la valeur slave_net_timeout.

Options d'orchestrateur:

DelayMasterPromotionIfSQLThreadNotUpToDate- si égal true, le rôle de l'assistant ne sera pas appliqué sur la réplique candidate tant que le flux SQL de réplique n'aura pas terminé toutes les transactions non appliquées à partir du journal de relais. Nous utilisons cette option afin de ne pas perdre de transactions lorsque toutes les répliques candidates sont en retard.
InstancePollSeconds - la fréquence de construction et de mise à jour de la topologie.
RecoveryPollSeconds- fréquence d'analyse de la topologie. Si un problème est détecté, la récupération de la topologie démarre. Il s'agit d'une constante égale à 1 seconde.

Chaque nœud de cluster est interrogé par l'orchestrateur une fois par InstancePollSecondsseconde. Lorsqu'un problème est détecté, l'état du cluster est mis à jour de force , puis la décision finale est prise pour effectuer la récupération. En expérimentant différents paramètres de la base de données et de l'orchestre, nous avons pu réduire la durée de la réponse et de la récupération à 30 secondes.

Banc d'essai

Nous avons commencé à tester le système HA en développant un banc de test local et en le mettant en œuvre dans un environnement de test et de combat. Le stand local est entièrement automatisé basé sur Docker et vous permet d'expérimenter la configuration de l'orchestre et du réseau, de faire évoluer le cluster de 2-3 serveurs à plusieurs dizaines et de mener des exercices dans un environnement sûr.

Au cours des exercices, nous choisissons l'une des méthodes pour émuler le problème: lancer instantanément l'assistant avec kill -9, terminer doucement le processus et arrêter le serveur ( docker-compose stop), simuler les problèmes de réseau avec iptables -j REJECTou iptables -j DROP. Nous attendons ces résultats:

l'orchestre détectera les problèmes avec le maître et mettra à jour la topologie en moins de 10 secondes;
la procédure de récupération démarre automatiquement: la configuration du réseau va changer, le rôle de l'assistant ira à la réplique, la topologie sera reconstruite;
le nouveau master sera disponible pour l'enregistrement, les répliques live ne seront pas perdues lors du processus de reconstruction;
les données commenceront à être écrites sur le nouveau maître et répliquées;
le temps de récupération total ne dépassera pas 30 secondes.

Comme vous le savez, un système peut se comporter différemment dans les environnements de test et de production en raison des différentes configurations de matériel et de réseau, des différences de charge synthétique et réelle, etc. Par conséquent, nous effectuons périodiquement des exercices en conditions réelles, vérifiant le comportement du système en cas de perte de connectivité réseau ou de dégradation de ses différentes parties. À l'avenir, nous voulons construire une infrastructure complètement identique pour les deux environnements et automatiser ses tests.

résultats

L'opérabilité du nœud principal du système de stockage est l'une des principales tâches de l'équipe SRE et de son fonctionnement. L'introduction de l'orchestre et des solutions HA basées sur VIP a permis d'obtenir les résultats suivants:

détection fiable des problèmes avec la topologie du cluster de base de données;
réponse automatique et rapide aux incidents liés au maître, ce qui réduit les temps d'arrêt du système.

Cependant, la solution a ses limites et ses inconvénients:

l'adaptation du schéma HA à plusieurs centres de données nécessitera un réseau L2 unique entre eux;
avant d'attribuer un VIP au nouveau maître, nous devons le libérer sur l'ancien. Le processus est séquentiel, ce qui augmente le temps de récupération;
VIP SSH- , . , , , VIP . IP- split brain.

Pour éviter cela split brain, vous pouvez utiliser la méthode STONITH («Shoot The Other Node In The Head»), qui isole ou déconnecte complètement le nœud problématique. Il existe d'autres façons d'implémenter la haute disponibilité du cluster: une combinaison de VIP et DNS, de services de découverte et de proxy, de réplication synchrone et d'autres méthodes qui ont leurs inconvénients et leurs avantages.

J'ai parlé de notre approche pour créer un cluster de basculement MySQL. Il est facile à mettre en œuvre et offre un niveau de fiabilité acceptable dans l'environnement actuel. Avec le développement de l'ensemble du système dans son ensemble et des infrastructures en particulier, cette approche évoluera sans aucun doute.

Orchestrator et VIP en tant que solution HA pour le cluster MySQL