Tech Blog.

Thoughts, stories, ideas.

MySQL/MariaDB HA: Galera Cluster vs. DRBD replication

20. August 2016
Avis de marques de commerce

DRBD® et LINBIT® sont des marques commerciales ou des marques déposées de LINBIT en Autriche, aux Etats-Unis et dans d’autres pays.

Les autres noms mentionnés dans ce document peuvent être des marques de commerce ou des marques déposées de leurs propriétaires respectifs.

Notes de licence

Le présent document est un document commercial de LINBIT et d’Adfinis SyGroup et est soumis aux conditions générales de distribution. Pour de plus amples informations, veuillez consulter le site http://links.linbit.com/t-and-c.

  1. A propos de DRBD
  2. Introduction
    2.1. Aperçu de la DRBD
    2.2. Vue d’ensemble de la Galera Cluster
  3. Comparaison
    3.1. Trafic réseau
    3.2. Commit delay
    3.3. Réplication
    3.4. Répartition de la charge
    3.5. Failover
    3.6. Resynchronization
  4. résumé
  5. Documentation complémentaire

1. A propos de DRBD

Le logiciel DRBDest une fonction de réplication du noyau Linux au niveau du bloc de données qui est largement utilisée comme un élément de base pour les clusters à rien partagé. Il est inclus dans Vanilla Kernels à partir de la version 2.6.33 et les utilitaires requis pour l’environnement utilisateur sont fournis par la plupart des distributions. De plus, de nombreuses distributions ont des versions DRBD plus récentes que les paquets supplémentaires inclus dans le paquet du noyau.

DRBD est capable de se répliquer sur plusieurs protocoles réseau et (actuellement) en trois modes – de la réplication synchrone pour les clusters HA locaux à la réplication asynchrone pour transférer les données vers un site de reprise après sinistre.

DRBD est développé par LINBIT et distribué dans le monde entier ; cela inclut la plupart des distributions et architectures, avec quelques niveaux de SLA jusqu’à 24/7 email et disponibilité téléphonique.

Galera Cluster est un cluster de base de données multi-maîtres synchrone qui offre une haute disponibilité en répliquant les transactions sur tous les nœuds du cluster. En supprimant la surcharge introduite par un commit en deux phases et en la transférant vers un mécanisme de réplication basé sur un certificat, la solution permet une mise à l’échelle quasi linéaire tout en maintenant une disponibilité et une cohérence élevées.

Galera est développé par Codership et est entièrement intégré et supporté dans les solutions de MariaDB.Adfinis SyGroup est un partenaire de MariaDB et offre son soutien dans la mise en œuvre, le suivi et la maintenance des infrastructures basées sur MariaDB.

2. Introduction

Ce guide technique compare deux solutions de haute disponibilité pour les bases de données MySQL ; l’une est une solution de réplication basée sur un bloc de périphériques, l’autre étend les fonctionnalités internes de MariaDB pour fournir une réplication synchrone.

Certaines différences sont soulignées et les avantages et inconvénients sont discutés.

2.1. Aperçu de la DRBD

DRBD est une solution de réplication basée sur des blocs de périphériques qui garantit simplement qu’une zone de blocs mémoire (partition, disque ou lecteur logique, etc.) sur deux nœuds (ou plus avec DRBD 9) est identique.

Cela signifie une indépendance totale par rapport à l’application qui utilise cette mémoire. Même le système de fichiers n’a pas d’importance – XFS, ext4, BTRFS etc. fonctionnent également bien.

La DRBD est généralement utilisée sur des connexions TCP/IP ; la DRBD 9 assure également le transport RDMA, ce qui réduit le délai réseau et augmente légèrement le nombre d’IOP disponibles.

2.2. Vue d’ensemble des Galera Cluster

Galera Cluster fonctionne avec le programme binaire MariaDB. Via les paramètres de configuration, le programme binaire mysql charge la bibliothèque partagée par Galera, qui permet la communication réseau et la réplication d’autres processus mysql vers des nœuds réseau distants.

Actuellement, Galera Cluster n’est compatible qu’avec l’InnoDB Storage Engine car seul ce moteur fournit le support transactionnel nécessaire. La prise en charge de moteurs de stockage supplémentaires est possible dès que ces transactions sont prises en charge.

3. comparaison

3.1. trafic réseau

Comme la DRBD ne remarque rien au sujet du système de fichiers et des couches d’application au-dessus, elle réplique all écrit au nœud de réseau distant – c’est-à-dire les données d’application, les journaux de transactions, les index et les métadonnées du système de fichiers (comme le journal du système de fichiers, les inodes, les répertoires).

Galera Cluster envoie simplement les logical changes, par exemple le contenu de la transaction sous la forme d’un write-set Galera compressé sur le réseau. Un état UPDATE composé de plusieurs milliers de lignes a approximativement la taille des enregistrements mis à jour. Il n’y a pas d’autres frais généraux pour les index ou les journaux des transactions.

La communication du cluster Galera peut utiliser des connexions Unicast (TCP) ou Multicast (UDP). La multidiffusion est particulièrement adaptée aux environnements étendus afin de réduire davantage le trafic réseau.

3.2. Délai de validation

Avec DRBD, il n’y a qu’un seul maître actif pour cette base de données ; une fois que l’opération finale d’écriture sur le disque dur pour COMMIT est terminée, DRBD peut envoyer une confirmation à l’application. Selon la mémoire de pile[1] le délai peut être inférieur à 100 μsec .

Dans Galera Cluster, le contenu d’une transaction est envoyé à chaque nœud du cluster. Dès que le client confirme la transaction à un nœud, ce nœud envoie write-set aux autres nœuds qui confirment la réception. Chaque nœud certifie ensuite l’ensemble en écriture et exécute la transaction localement. Le nœud source confirme la transaction au client une fois que la certification locale a été effectuée avec succès.

Un délai supplémentaire se produit seulement pendant l’étape d’envoi et correspond au temps d’aller-retour le plus long à l’un des nœuds du cluster. Pour une livraison dans un même lieu de colocation, le délai est généralement inférieur à 400 μsec.

3.3. réplication

La DRBD prend en charge la réplication synchrone et asynchrone ; cette dernière est utile pour la reprise après sinistre sur de longues distances. Dans ce cas, il existe un produit distinct (le DRBD Proxy) qui prend en charge la compression du flux de données de réplication et réduit ainsi la bande passante nécessaire.

Galera Cluster ne peut être utilisé que de manière synchrone. Cependant, les esclaves de réplication MariaDB standard asynchrones peuvent être connectés à n’importe quel nœud du cluster Galera. Cependant, comme chaque livraison est associée à un délai supplémentaire, le nombre de transactions qui peuvent être traitées sur des déploiements WAN est limité. Une règle empirique pour le nombre maximum de transactions est 1/RTT trx/s.

3.4. répartition de la charge

La DRBD est normalement utilisée dans une configuration active/passive, c’est-à-dire que chaque ressource DRBD n’est active que sur un nœud[2]. Cela signifie qu’un seul nœud a accès au système de fichiers dans lequel une base de données est stockée[3] ; ce nœud est responsable de l’ensemble de l’analyse des instructions, de la récupération des données, de la prise de décisions et de la rédaction.

Galera Cluster est une solution multi-maîtres pure – chaque nœud fournit ses propres ressources. Le seul effet sur les performances est d’envoyer la transaction à tous les nœuds. Chaque nœud peut être utilisé pour des requêtes en lecture seule, de sorte que la puissance en lecture s’échelonne linéairement. De manière optimiste, un certain degré d’évolutivité des opérations d’écriture peut être atteint. Cependant, cela dépend de la structure de l’application[4], au mieux la performance d’écriture peut être augmentée d’environ 15 %.

3.5. Failover

Dans un environnement d’AP, il doit également y avoir une planification préalable en cas de problèmes.

Si le nœud actif dans un environnement DRBD tombe en panne (pour quelque raison que ce soit), la pile de clusters (généralement Pacemaker avec Heratbeat ou Corosync) doit détecter le problème et transférer le service vers un autre nœud. Dans le pire des cas, cela entraînera une analyse du système de fichiers, une récupération de la base de données, puis le temps d’attente nécessaire pour rendre les caches à nouveau disponibles[5].

Si un seul nœud tombe en panne dans Galera Cluster, les nœuds restants du cluster continuent à fonctionner sans interruption. Un client actuellement connecté au nœud défaillant tente de se reconnecter à l’aide d’un répartiteur de charge[6], les autres clients ne sont exposés à aucune interruption. Si le nœud défaillant est de nouveau opérationnel, il peut être nécessaire de vérifier le système de fichiers et de restaurer la base de données, de sorte que ce nœud ne soit pas disponible pour l’équilibrage de charge dans ce délai.

3.6. Resynchronization

Après une panne, le nœud défaillant doit s’assurer qu’il reçoit les dernières données.

La DRBD située dans la couche de périphérique de bloc contient un bitmap des blocs de données dirty et prend simplement le relais dès que la connexion DRBD est rétablie après la panne. L’opération de copie est effectuée dans l’ordre sur le disque dur ; la performance est limitée uniquement par le stockage et le matériel réseau. Avec un réseau de 10 Go et des cartes FusionIO, il devrait être possible d’atteindre 1,2 Go/sec.

Galera Cluster a deux façons de mettre à jour un nœud suivant. Si le nœud était précédemment membre du cluster et n’a quitté le cluster que pour une courte période[7], le nœud tente d’effectuer un transfert d’état incrémentiel (IST) en retirant les modifications du cache en écriture d’un autre nœud du cluster.

Si aucun autre nœud du cluster ne peut fournir les modifications requises pour l’IST à partir de son cache en écriture, ou si un nouveau nœud est ajouté au cluster, un transfert d’état snapshot (SST) est effectué. Cela signifie que toutes les données de la base de données sont transférées au nœud connecté. Galera sélectionne un nœud donneur, qui représente la source du transfert. Parce qu’un donateur peut avoir un impact important sur la performance, les nœuds de donateur sont souvent exclus de l’équilibrage de charge pour assurer une performance cohérente en lecture et en écriture au sein du cluster.

4. résumé

Le tableau suivant est un tableau de conclusion basé sur les sujets discutés ci-dessus.

  DRBD Galera Cluster Advantage
Trafic de réseau Tous les blocs de données modifiés Contenu de la transaction uniquement Galera
Retard μsec jusque msec, selon le système de mémoire msec, en raison des transitions entre l’espace utilisateur et le noyau DRBD
Replication synchronisé ou asynchrone (Disaster-Recovery) synchronisé ou asynchrone DRBD/Galera
Équilibrage de charge Les données au niveau du bloc de données peuvent être lues par d’autres nœuds. Multi-Master complet Galera
Failover Par pile de clusters ; temps d’arrêt en secondes ou minutes les autres nœuds continuent de fonctionner sans interruption Galera
Resynchronization Uniquement les blocs de données modifiés, bloc de données de l’appareil Séquence IST/SST –

 

5. documentation supplémentaire

La page du projet DRBD Sur http://drbd.linbit.org, avec de nombreuses informations, dont un manuel d’utilisation de 172 pages (au dernier décompte) en format PDF – l’une des documentations de projet les plus complètes du monde open source!

La page d’accueil de LINBIT Le site http://www.linbit.com, répond à toutes vos questions sur le support payant des développeurs. Vous trouverez un aperçu des plates-formes prises en charge, des SLA et des prix à l’adresse http://www.linbit.com/en/products-and-services/drbd-support/pricing?id=358

La page d’accueil d’Adfinis SyGroup. “We are the Linux Engineers” est le fier slogan sur https://adfinis.com. Avec plus de 15 ans d’expérience Linux, le SyGroup d’Adfini est la première adresse en Suisse.

The MariaDB Home Page. MariaDB Corporation https://mariadb.com est le moteur du développement de MariaDB et, avec ses partenaires, apporte soutien et assistance aux produits MariaDB.

  1. Contrôleur RAID avec BBU, cartes FusionIO et quelques SSDs ↩

  2. La disponibilité d’un cluster cluster en répartissant les ressources actives entre les nœuds est recommandée.↩

  3. Le fractionnement d’une base de données a ne fonctionne pas. Cependant, vous pouvez exécuter plusieurs processus MySQL dans un cluster DRBD, chacun avec sa propre base de données et ses adresses IP de service séparées. ↩

  4. par ex. base de données Hot Spots. ↩

  5. Tout cela peut être migré à partir d’un bon système de stockage. Un de nos clients a pu réduire ce temps d’environ 45 minutes à 30 secondes en passant du stockage sur disque dur aux cartes FusionIO ↩

  6. par exemple MariaDB MaxScale ↩

  7. Par exemple, à cause d’un redémarrage ou d’une mise à niveau puis du redémarrage de MariaDB. ↩