HA pour MySQL et MariaDB - Comparaison de la réplication maître-maître avec Galera Cluster

La réplication Galera est relativement nouvelle par rapport à la réplication MySQL, qui est nativement prise en charge depuis MySQL v3.23. Bien que la réplication MySQL soit conçue pour la réplication unidirectionnelle maître-esclave, elle peut être configurée comme une configuration maître-maître active avec une réplication bidirectionnelle. Bien qu'il soit facile à configurer et que certains cas d'utilisation puissent bénéficier de ce "hack", il existe un certain nombre de mises en garde. D'autre part, le cluster Galera est un type de technologie différent à apprendre et à gérer. Est-ce que ça vaut le coup ?

Dans cet article de blog, nous allons comparer la réplication maître-maître au cluster Galera.

Concepts de réplication

Avant de nous lancer dans la comparaison, expliquons les concepts de base derrière ces deux mécanismes de réplication.

Généralement, toute modification de la base de données MySQL génère un événement au format binaire. Cet événement est transporté vers les autres nœuds en fonction de la méthode de réplication choisie - réplication MySQL (native) ou réplication Galera (corrigée avec l'API wsrep).

Réplication MySQL

Les diagrammes suivants illustrent le flux de données d'une transaction réussie d'un nœud à un autre lors de l'utilisation de la réplication MySQL :

L'événement binaire est écrit dans le journal binaire du maître. Le ou les esclaves via slave_IO_thread extraira les événements binaires du journal binaire du maître et les répliquera dans son journal de relais. Le thread_SQL_esclave appliquera alors l'événement du journal de relais de manière asynchrone. En raison de la nature asynchrone de la réplication, il n'est pas garanti que le serveur esclave dispose des données lorsque le maître effectue la modification.

Idéalement, la réplication MySQL aura l'esclave à configurer en tant que serveur en lecture seule en définissant read_only=ON ou super_read_only=ON. Il s'agit d'une précaution pour protéger l'esclave des écritures accidentelles qui peuvent entraîner une incohérence ou une défaillance des données lors du basculement du maître (par exemple, des transactions errantes). Cependant, dans une configuration de réplication active-active maître-maître, la lecture seule doit être désactivée sur l'autre maître pour permettre le traitement simultané des écritures. Le maître principal doit être configuré pour répliquer à partir du maître secondaire en utilisant l'instruction CHANGE MASTER pour activer la réplication circulaire.

Réplication Galera

Les diagrammes suivants illustrent le flux de réplication de données d'une transaction réussie d'un nœud à un autre pour Galera Cluster :

L'événement est encapsulé dans un ensemble d'écritures et diffusé du nœud d'origine aux autres nœuds du cluster à l'aide de la réplication Galera. Le jeu d'écriture subit une certification sur chaque nœud Galera et s'il réussit, les threads de l'applicateur appliqueront le jeu d'écriture de manière asynchrone. Cela signifie que le serveur esclave finira par devenir cohérent, après accord de tous les nœuds participants dans l'ordre global global. Il est logiquement synchrone, mais l'écriture et la validation réelles dans l'espace de table se produisent indépendamment, et donc de manière asynchrone sur chaque nœud avec une garantie que le changement se propage sur tous les nœuds.

Éviter les collisions de clé primaire

Afin de déployer la réplication MySQL dans une configuration maître-maître, il faut ajuster la valeur d'incrémentation automatique pour éviter une collision de clé primaire pour INSERT entre deux ou plusieurs maîtres de réplication. Cela permet à la valeur de clé primaire sur les maîtres de s'entrelacer et d'empêcher que le même numéro d'incrémentation automatique soit utilisé deux fois sur l'un ou l'autre des nœuds. Ce comportement doit être configuré manuellement, en fonction du nombre de maîtres dans la configuration de la réplication. La valeur de auto_increment_increment est égal au nombre de maîtres de réplication et à auto_increment_offset doit être unique entre eux. Par exemple, les lignes suivantes doivent exister dans le my.cnf correspondant :

Maître1 :

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Maître2 :

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

De même, Galera Cluster utilise cette même astuce pour éviter les collisions de clé primaire en contrôlant la valeur d'incrémentation automatique et le décalage automatiquement avec wsrep_auto_increment_control variable. Si défini sur 1 (valeur par défaut), ajustera automatiquement le auto_increment_increment et auto_increment_offset variables en fonction de la taille du cluster et lorsque la taille du cluster change. Cela évite les conflits de réplication dus à auto_increment. Dans un environnement maître-esclave, cette variable peut être définie sur OFF.

La conséquence de cette configuration est que la valeur d'incrémentation automatique ne sera pas dans un ordre séquentiel, comme indiqué dans le tableau suivant d'un cluster Galera à trois nœuds :

Si une application effectue des opérations d'insertion sur les nœuds suivants dans l'ordre suivant :

• Nœud1, Nœud3, Nœud2, Nœud3, Nœud3, Nœud1, Nœud3 ..

Ensuite, la valeur de la clé primaire qui sera stockée dans la table sera :

• 1, 6, 8, 9, 12, 13, 15 ..

En termes simples, lorsque vous utilisez la réplication maître-maître (réplication MySQL ou Galera), votre application doit être capable de tolérer des valeurs d'auto-incrémentation non séquentielles dans son jeu de données.

Pour les utilisateurs de ClusterControl, notez qu'il prend en charge le déploiement de la réplication maître-maître MySQL avec une limite de deux maîtres par cluster de réplication, uniquement pour une configuration active-passive. Par conséquent, ClusterControl ne configure pas délibérément les maîtres avec auto_increment_increment et auto_increment_offset variable.

Cohérence des données

Galera Cluster est livré avec son mécanisme de contrôle de flux, où chaque nœud du cluster doit suivre le rythme lors de la réplication, sinon tous les autres nœuds devront ralentir pour permettre au nœud le plus lent de rattraper son retard. Cela minimise fondamentalement la probabilité d'un retard d'esclave, bien que cela puisse toujours arriver, mais pas aussi important que dans la réplication MySQL. Par défaut, Galera permet aux nœuds d'avoir au moins 16 transactions de retard dans l'application via la variable gcs.fc_limit . Si vous souhaitez effectuer des lectures critiques (un SELECT qui doit renvoyer les informations les plus récentes), vous souhaitez probablement utiliser la variable de session, wsrep_sync_wait .

Galera Cluster, d'autre part, est livré avec une protection contre l'incohérence des données par laquelle un nœud sera expulsé du cluster s'il ne parvient pas à appliquer un jeu d'écriture pour quelque raison que ce soit. Par exemple, lorsqu'un nœud Galera ne parvient pas à appliquer le jeu d'écriture en raison d'une erreur interne du moteur de stockage sous-jacent (MySQL/MariaDB), le nœud se retirera du cluster avec l'erreur suivante :

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

Pour corriger la cohérence des données, le nœud incriminé doit être resynchronisé avant d'être autorisé à rejoindre le cluster. Cela peut être fait manuellement ou en effaçant le répertoire de données pour déclencher le transfert de l'état de l'instantané (synchronisation complète à partir d'un donneur).

La réplication maître-maître MySQL n'applique pas la protection de la cohérence des données et un esclave est autorisé à diverger, par exemple, répliquer un sous-ensemble de données ou être en retard, ce qui rend l'esclave incohérent avec le maître. Il est conçu pour répliquer les données en un seul flux - du maître vers les esclaves. Les vérifications de cohérence des données doivent être effectuées manuellement ou via des outils externes tels que Percona Toolkit pt-table-checksum ou mysql-replication-check.

Résolution des conflits

Généralement, la réplication maître-maître (ou multi-maître ou bidirectionnelle) permet à plusieurs membres du cluster de traiter les écritures. Avec la réplication MySQL, en cas de conflit de réplication, le thread SQL de l'esclave arrête simplement d'appliquer la requête suivante jusqu'à ce que le conflit soit résolu, soit en sautant manuellement l'événement de réplication, en corrigeant les lignes incriminées ou en resynchronisant l'esclave. En termes simples, il n'y a pas de prise en charge automatique de la résolution des conflits pour la réplication MySQL.

Galera Cluster offre une meilleure alternative en réessayant la transaction incriminée lors de la réplication. En utilisant wsrep_retry_autocommit variable, on peut demander à Galera de réessayer automatiquement une transaction ayant échoué en raison de conflits à l'échelle du cluster, avant de renvoyer une erreur au client. S'il est défini sur 0, aucune tentative ne sera tentée, tandis qu'une valeur de 1 (valeur par défaut) ou plus spécifie le nombre de tentatives tentées. Cela peut être utile pour aider les applications utilisant la validation automatique à éviter les blocages.

Consensus de nœud et basculement

Galera utilise le système de communication de groupe (GCS) pour vérifier le consensus et la disponibilité des nœuds entre les membres du cluster. Si un nœud n'est pas sain, il sera automatiquement expulsé du cluster après gmcast.peer_timeout valeur, par défaut à 3 secondes. Un nœud Galera sain dans l'état "Synchré" est considéré comme un nœud fiable pour servir les lectures et les écritures, tandis que les autres ne le sont pas. Cette conception simplifie grandement les procédures de vérification de l'état des niveaux supérieurs (équilibreur de charge ou application).

Dans la réplication MySQL, un maître ne se soucie pas de son ou ses esclaves, alors qu'un esclave n'a qu'un consensus avec son seul maître via le slave_IO_thread processus lors de la réplication des événements binaires à partir du journal binaire du maître. Si un maître tombe en panne, cela interrompra la réplication et une tentative de rétablissement du lien sera effectuée tous les slave_net_timeout (par défaut à 60 secondes). Du point de vue de l'application ou de l'équilibreur de charge, les procédures de vérification de l'état de l'esclave de réplication doivent au moins impliquer la vérification de l'état suivant :

• Seconds_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• Variable en lecture seule
• Variable super_read_only (MySQL 5.7.8 et versions ultérieures)

En termes de basculement, généralement, la réplication maître-maître et les nœuds Galera sont égaux. Ils détiennent le même ensemble de données (bien que vous puissiez répliquer un sous-ensemble de données dans la réplication MySQL, mais c'est rare pour le maître-maître) et partagent le même rôle que les maîtres, capables de gérer les lectures et les écritures simultanément. Par conséquent, il n'y a en fait aucun basculement du point de vue de la base de données en raison de cet équilibre. Uniquement du côté de l'application qui nécessiterait un basculement pour ignorer les nœuds non opérationnels. Gardez à l'esprit que la réplication MySQL étant asynchrone, il est possible que toutes les modifications effectuées sur le maître ne se soient pas propagées à l'autre maître.

Provisionnement de nœud

Le processus de synchronisation d'un nœud avec le cluster avant le démarrage de la réplication est appelé provisionnement. Dans la réplication MySQL, le provisionnement d'un nouveau nœud est un processus manuel. Il faut faire une sauvegarde du maître et la restaurer sur le nouveau nœud avant de configurer le lien de réplication. Pour un nœud de réplication existant, si les journaux binaires du maître ont subi une rotation (sur la base de expire_logs_days , la valeur par défaut sur 0 signifie qu'il n'y a pas de suppression automatique), vous devrez peut-être reprovisionner le nœud à l'aide de cette procédure. Il existe également des outils externes tels que Percona Toolkit pt-table-sync et ClusterControl pour vous aider à ce sujet. ClusterControl prend en charge la resynchronisation d'un esclave en seulement deux clics. Vous avez la possibilité de resynchroniser en effectuant une sauvegarde à partir du maître actif ou d'une sauvegarde existante.

Dans Galera, il existe deux façons de procéder :le transfert d'état incrémentiel (IST) ou le transfert d'instantané d'état (SST). Le processus IST est la méthode préférée où seules les transactions manquantes sont transférées à partir du cache d'un donneur. Le processus SST est similaire à la prise d'une sauvegarde complète du donateur, il est généralement assez gourmand en ressources. Galera déterminera automatiquement le processus de synchronisation à déclencher en fonction de l'état du participant. Dans la plupart des cas, si un nœud ne parvient pas à rejoindre un cluster, effacez simplement le répertoire de données MySQL du nœud problématique et démarrez le service MySQL. Le processus de provisionnement Galera est beaucoup plus simple, il est très pratique lors de la mise à l'échelle de votre cluster ou de la réintroduction d'un nœud problématique dans le cluster.

Lâchement couplé vs étroitement couplé

La réplication MySQL fonctionne très bien même sur des connexions plus lentes et avec des connexions qui ne sont pas continues. Il peut également être utilisé sur différents matériels, environnements et systèmes d'exploitation. La plupart des moteurs de stockage le supportent, notamment MyISAM, Aria, MEMORY et ARCHIVE. Cette configuration faiblement couplée permet à la réplication MySQL maître-maître de bien fonctionner dans un environnement mixte avec moins de restrictions.

Les nœuds Galera sont étroitement couplés, où les performances de réplication sont aussi rapides que le nœud le plus lent. Galera utilise un mécanisme de contrôle de flux pour contrôler le flux de réplication entre les membres et éliminer tout décalage d'esclave. La réplication peut être entièrement rapide ou entièrement lente sur chaque nœud et est ajustée automatiquement par Galera. Ainsi, il est recommandé d'utiliser des spécifications matérielles uniformes pour tous les nœuds Galera, en particulier en ce qui concerne le processeur, la RAM, le sous-système de disque, la carte d'interface réseau et la latence du réseau entre les nœuds du cluster.

Conclusion

En résumé, Galera Cluster est supérieur par rapport à la réplication MySQL maître-maître en raison de sa prise en charge de la réplication synchrone avec une forte cohérence, ainsi que des fonctionnalités plus avancées telles que le contrôle automatique des membres, le provisionnement automatique des nœuds et les esclaves multithreads. En fin de compte, cela dépend de la façon dont l'application interagit avec le serveur de base de données. Certaines applications héritées conçues pour un serveur de base de données autonome peuvent ne pas fonctionner correctement sur une configuration en cluster.

Pour simplifier nos points ci-dessus, les raisons suivantes justifient l'utilisation de la réplication maître-maître MySQL :

• Choses qui ne sont pas prises en charge par Galera :
  • Réplication pour les tables non-InnoDB/XtraDB telles que MyISAM, Aria, MEMORY ou ARCHIVE.
  • Transactions XA.
  • Réplication basée sur des instructions entre les maîtres (par exemple, lorsque la bande passante est très chère).
  • S'appuyer sur un verrouillage explicite comme l'instruction LOCK TABLES.
  • Le journal des requêtes générales et le journal des requêtes lentes doivent être dirigés vers une table plutôt que vers un fichier.
• Configuration faiblement couplée où les spécifications matérielles, la version du logiciel et la vitesse de connexion sont très différentes sur chaque maître.
• Lorsque vous disposez déjà d'une chaîne de réplication MySQL et que vous souhaitez ajouter un autre maître actif/de secours pour la redondance afin d'accélérer le temps de basculement et de récupération au cas où l'un des maîtres serait indisponible.
• Si votre application ne peut pas être modifiée pour contourner les limitations de Galera Cluster et qu'un équilibreur de charge compatible MySQL comme ProxySQL ou MaxScale n'est pas une option.

Raisons de choisir Galera Cluster plutôt que la réplication maître-maître MySQL :

• Capacité à écrire en toute sécurité sur plusieurs maîtres
• Cohérence des données automatiquement gérée (et garantie) entre les bases de données.
• Nouveaux nœuds de base de données facilement introduits et synchronisés.
• Échecs ou incohérences automatiquement détectés.
• En général, fonctionnalités de haute disponibilité plus avancées et plus robustes.