MySQL Group Replication (MGR) est un mode de réplication distribuée reposant sur le mécanisme de journal binaire de MySQL et mis en œuvre à l'aide du protocole Paxos. Les instances ApsaraDB RDS for MySQL exécutant la version Cluster Edition de RDS prennent en charge MGR.
La réplication traditionnelle repose sur des modes asynchrone ou semi-synchrone : le nœud principal écrit une transaction dans son journal binaire, puis la propage aux nœuds secondaires, sans garantie que ces derniers aient bien reçu les données avant qu'une panne ne survienne. MGR adopte une approche fondamentalement différente : avant qu'une transaction ne soit validée, une majorité de nœuds doit accuser réception de ses journaux binaires. Ce modèle basé sur l'accusé de réception majoritaire offre des garanties de données plus solides que les modes de réplication traditionnels.
| Fonctionnalité | MGR | Réplication semi-synchrone | Réplication asynchrone |
|---|---|---|---|
| Fiabilité des données | ★★★★★ | ★★★ | ★ |
| Cohérence des données | Garantie | Non garantie | Non garantie |
| Cohérence globale des transactions | Prise en charge | Non prise en charge | Non prise en charge |
Avantages
Fiabilité élevée des données
MGR s'appuie sur la règle de majorité du protocole Paxos : une transaction n'est validée que lorsque la plupart des nœuds du cluster RDS ont reçu ses journaux binaires. Cette approche prévient toute perte de données, même si une minorité de nœuds rencontre des défaillances.
Prenons l'exemple d'un cluster composé de 5 nœuds, dont 3 ont reçu les journaux binaires et 2 non :
Si les 2 nœuds défaillants figurent parmi ceux qui ont reçu les journaux binaires, au moins 1 nœud détenant les données reste opérationnel.
Si les 2 nœuds défaillants figurent parmi ceux qui n'ont pas reçu les journaux binaires, les 3 nœuds détenant les données restent tous opérationnels.
Forte cohérence des données
Dans une réplication primaire-secondaire traditionnelle, si le nœud principal tombe en panne après avoir écrit une transaction dans son journal binaire, mais avant de l'avoir transmise aux nœuds secondaires, une incohérence des données se produit. MGR empêche ce scénario : les transactions sont transmises aux autres nœuds avant d'être écrites dans le journal binaire, de sorte que chaque transaction validée se trouve déjà sur une majorité de nœuds.
En cas de panne et de redémarrage du nœud principal, celui-ci rejoint automatiquement le cluster et synchronise les journaux binaires manquants pour se mettre à jour.
Cohérence globale des transactions
Définissez le paramètre group_replication_consistency pour contrôler le niveau de cohérence des opérations de lecture et d'écriture :
Cohérence de lecture forte (
group_replication_consistency=BEFOREsur les nœuds secondaires) : une requête ne s'exécute qu'après la finalisation de toutes les transactions qui l'ont précédée sur le nœud principal. Cela garantit que les lectures effectuées sur les nœuds secondaires ne renvoient jamais de données obsolètes.Cohérence d'écriture forte (
group_replication_consistency=AFTERsur le nœud principal) : une transaction d'écriture n'est validée qu'après avoir été appliquée avec succès sur tous les nœuds.
Méthodes de déploiement
MGR prend en charge deux modes de déploiement. Le tableau ci-dessous compare leurs capacités et leurs compromis afin de vous aider à choisir le mode adapté à votre charge de travail.
| Leader multiple | Leader unique | |
|---|---|---|
| Nœuds d'écriture | Tous les nœuds | Nœud principal uniquement |
| Nœuds de lecture | Tous les nœuds | Tous les nœuds non principaux |
| Débit d'écriture | Plus élevé (écritures parallèles sur plusieurs nœuds) | Plus faible (chemin d'écriture unique) |
| Débit de lecture | Standard | Plus élevé (nœuds en lecture seule optimisés) |
| Disponibilité en cas de panne d'une minorité de nœuds | Dégradée — les nœuds suivant le nœud défaillant dans l'ordre d'interrogation ne peuvent pas envoyer de données | Inchangée — le cluster continue de fonctionner tant qu'une majorité de nœuds est disponible |
| Basculement primaire/secondaire en cas de panne du primaire | S.O. | Automatique, basé sur le protocole Paxos |
| Garantie de cohérence des données | Forte | Forte |
Leader multiple
Tous les nœuds traitent à la fois les requêtes de lecture et d'écriture. Le mode leader multiple augmente le débit d'écriture en utilisant les mécanismes Paxos pour écrire plusieurs enregistrements simultanément et détecter les conflits au niveau des lignes, garantissant ainsi que tous les nœuds reçoivent les données dans le même ordre.
Limite : Lorsqu'un nœud subit des fluctuations de performance ou une panne, les nœuds listés après lui dans l'ordre d'interrogation ne peuvent pas envoyer de données, rendant le cluster temporairement indisponible. Il s'agit d'une limitation inhérente au mode leader multiple, impossible à éliminer.
Leader unique
Un seul nœud traite les requêtes d'écriture ; tous les autres nœuds traitent les requêtes de lecture. Le mode leader unique utilise la stratégie de réplication à leader unique du protocole Paxos pour maximiser le débit de lecture et maintenir une haute disponibilité :
Si un nœud secondaire tombe en panne et qu'une majorité de nœuds reste disponible, le cluster continue de fonctionner sans interruption.
Si le nœud principal tombe en panne, le cluster effectue automatiquement un basculement primaire/secondaire basé sur le protocole Paxos afin de maintenir une forte cohérence des données.
ApsaraDB RDS for MySQL permet de créer des clusters RDS utilisant MGR en mode leader unique. Dans ce mode, les nœuds en lecture seule sont optimisés pour améliorer les performances du cluster tout en garantissant une fiabilité élevée des données et une forte cohérence.
Architecture
MGR ajoute trois couches sous les couches serveur et réplica de MySQL :
| Couche | Rôle |
|---|---|
| Couche logique de réplication de groupe | Interagit avec la couche serveur de MySQL pour envoyer et recevoir des transactions vers et depuis la couche de système de communication de groupe (GCS), et applique les transactions |
| Couche GCS | Livre les messages, détecte les pannes et gère l'appartenance au cluster |
| Couche XCom | Garantit la cohérence de l'ordre des données et la disponibilité de la majorité des nœuds, sur la base du protocole Paxos |
Protocole Paxos
Le protocole Paxos remplit deux fonctions dans MGR :
Il garantit que tous les nœuds du cluster reçoivent les journaux binaires d'une transaction dans le même ordre, ce qui est essentiel pour le mode leader multiple.
Il veille à ce qu'une transaction ne soit validée qu'après accusé de réception de ses journaux binaires par une majorité de nœuds.
La couche XCom s'appuie sur le protocole Mencius, une variante basée sur Paxos qui remplace l'ordonnancement par verrouillage de Paxos par un mécanisme d'interrogation. Cela permet d'équilibrer la charge entre les nœuds et d'améliorer l'efficacité globale.
Fonctionnement du mode leader multiple
En mode leader multiple, chaque nœud appartient à un groupe Paxos. La couche XCom impose un ordre global cohérent des données à l'aide de deux mécanismes :
Envoi sériel au sein d'un groupe : Les données au sein de chaque groupe sont envoyées de manière sérielle pour garantir la cohérence de l'ordre au sein du groupe.
Interrogation entre groupes : Lorsque plusieurs groupes envoient des données, un mécanisme d'interrogation impose un ordre cohérent à l'échelle globale. Par exemple, les données sont envoyées dans l'ordre (1,1), (1,2), (1,3).
Dans la notation (m,n), n représente le numéro du groupe et m le numéro de séquence de l'enregistrement de données envoyé par ce groupe. Par exemple, (2,1) signifie que le groupe 1 envoie son deuxième enregistrement de données.
Le mécanisme noop gère les nœuds inactifs : si un nœud n'a aucune donnée à envoyer, mais que les données des nœuds listés après lui ont déjà été reçues par une majorité du cluster, le nœud diffuse un état noop pour se sauter lui-même et débloquer le nœud suivant dans l'ordre d'interrogation.
Fonctionnement du mode leader unique
Étant donné qu'un seul nœud envoie des transactions d'écriture en mode leader unique, un seul groupe Paxos doit être actif. Le récepteur ignore tous les autres groupes Paxos lors de l'interrogation. Cela élimine le problème de disponibilité lié aux noop présent dans le mode leader multiple : tant qu'une majorité de nœuds est disponible, le cluster reste opérationnel même si des nœuds individuels tombent en panne.
Les nœuds secondaires en mode leader unique n'envoient pas de transactions ; ils envoient uniquement des informations de gestion du cluster. Avant qu'un nœud secondaire n'envoie des données, il doit demander un créneau d'envoi au nœud principal. La notation <3,1> dans le schéma ci-dessus représente un tel créneau. Étant donné que les messages de gestion du cluster sont peu fréquents, la surcharge de latence induite par ce mécanisme de demande de créneau n'a aucun impact significatif sur le débit du cluster.
Couche logique de réplication de groupe
La couche logique de réplication de groupe gère la propagation des transactions et la détection des conflits sur les nœuds principaux et secondaires.
Flux du nœud principal :
Avant qu'une transaction ne soit validée, la couche logique de réplication de groupe envoie ses journaux binaires à la couche XCom, qui les diffuse à tous les autres nœuds. Après accusé de réception par une majorité de nœuds, la détection des conflits est exécutée :
Succès : la transaction est écrite dans le fichier de journal binaire et validée.
Échec : la transaction est annulée.
Flux du nœud secondaire :
Après accusé de réception d'une transaction par une majorité de nœuds, la couche XCom la transfère à la couche logique de réplication de groupe pour détection des conflits :
Succès : la transaction est écrite dans le fichier de journal de relais et appliquée par le thread d'application.
Échec : les données de la transaction sont supprimées.
Détection des conflits
Cas nécessitant une détection des conflits :
Mode leader multiple : Requis pour chaque opération d'écriture, car plusieurs nœuds peuvent accepter des écritures simultanément.
Mode leader unique : Requis uniquement lors d'un basculement primaire/secondaire, si des transactions d'écriture arrivent sur le nouveau nœud principal avant que ses journaux de relais provenant du nœud principal d'origine n'aient été entièrement appliqués.
Fonctionnement :
Chaque nœud maintient un tableau de hachage contenant les informations d'authentification des transactions :
Clé : La valeur de hachage d'une ligne de données modifiée (basée sur sa clé primaire).
Valeur : L'union de l'identifiant global de transaction (GTID) de la transaction actuelle et de
gtid_executed— l'ensemble de tous les GTID validés sur le nœud source avant la validation de la transaction actuelle.
Avant qu'une transaction ne soit validée, chaque nœud construit un ensemble de dépendances en recherchant les valeurs de hachage de toutes les lignes modifiées par la transaction dans son tableau d'authentification. L'ensemble de dépendances représente toutes les transactions qui doivent avoir été finalisées avant que la transaction actuelle puisse être validée en toute sécurité.
Le système compare ensuite l'ensemble de validation de la transaction (transactions validées avant celle-ci sur le nœud source) avec l'ensemble de dépendances :
Si l'ensemble de validation contient l'ensemble de dépendances, la transaction passe la détection des conflits et est validée sur le nœud source, puis écrite dans les journaux de relais des autres nœuds.
Si l'ensemble de validation ne contient pas l'ensemble de dépendances, la transaction échoue à la détection des conflits, est annulée sur le nœud source et ses données de journal de relais sont supprimées sur les autres nœuds.
Suppression des données d'authentification obsolètes :
Une fois qu'une transaction a été appliquée sur tous les nœuds du cluster, ses lignes peuvent être retirées du tableau d'authentification. MGR purge les données d'authentification obsolètes toutes les 60 secondes.
Optimisations AliSQL pour la stabilité de MGR
Le mode leader unique améliore considérablement la stabilité de MGR, mais un scénario spécifique reste problématique : lorsqu'un nœud secondaire subit une latence élevée, il ne peut pas appliquer les transactions assez rapidement, ce qui entraîne une accumulation des informations d'authentification. Cela provoque deux problèmes :
Une consommation mémoire élevée, avec un risque d'erreurs de manque de mémoire (OOM).
Une surcharge importante liée à la purge périodique des données d'authentification accumulées, ce qui dégrade les performances du cluster.
AliSQL résout ce problème en réduisant le volume d'informations d'authentification maintenues sur chaque nœud :
Nœud principal : Le tableau d'authentification sur le nœud principal n'est jamais utilisé pour la détection des conflits en mode leader unique. AliSQL le supprime entièrement, éliminant ainsi sa surcharge mémoire et de purge.
Nœud secondaire : Les informations d'authentification ne sont nécessaires que lorsque
group_replication_consistencyest défini surEVENTUAL. Le paramètreEVENTUALpermet à un nœud principal nouvellement élu de traiter le trafic externe immédiatement, sans attendre la fin de la lecture des journaux de relais, ce qui peut provoquer des conflits de données et est rarement utilisé en production. LorsqueEVENTUALn'est pas utilisé, AliSQL supprime également le tableau d'authentification des nœuds secondaires, réduisant considérablement la consommation de mémoire et améliorant la stabilité du cluster.