Types de réplication MySQL
MySQL est l’une des bases de données open source les plus populaires au monde. Il est très facile de commencer à utiliser MySQL pour votre application ou votre site Web. Par exemple, MySQL est l’option par défaut des solutions CMS populaires telles que WordPress et Magento.
Cependant, il n’est pas trivial de rendre MySQL totalement fiable et disponible en cas de charge élevée. La réplication de la base de données et le clustering peuvent vous aider à atteindre cet objectif.
MySQL étant l’une des premières bases de données open source, les capacités de réplication de MySQL ont évolué au fil du temps. Voici la liste des types de réplication les plus utilisés pour MySQL :
- Réplication maître-esclave
- Réplication maître-maître
- Réplication de groupe
- Cluster multi-maître (disponible pour MariaDB, qui est le fork de MySQL)
Examinons de plus près chacun d’entre eux.
MySQL Réplication maître-esclave
Laréplication MySQL maître-esclave a été la toute première option de réplication pour la base de données MySQL. Elle suppose que vous disposez d’un seul serveur maître qui accepte les lectures et les écritures et d’un ou plusieurs serveurs esclaves en lecture seule. Les données du serveur maître sont répliquées de manière asynchrone sur les serveurs esclaves.
Pour
- Il est très rapide car il n’impose aucune restriction aux performances.
- Vous pouvez répartir les demandes de lecture et d’écriture sur différents serveurs. Par exemple, toutes les requêtes analytiques peuvent être effectuées sur des nœuds esclaves.
Contre
- Il n’est pas très fiable à cause de la réplication asynchrone. Cela signifie que certaines transactions engagées sur le maître peuvent ne pas être disponibles sur l’esclave si le maître tombe en panne.
- Les demandes d’écriture peuvent difficilement être mises à l’échelle. La seule option pour faire évoluer les demandes d’écriture est d’augmenter la capacité de calcul (RAM et CPU) du nœud maître.
- Le processus de basculement est manuel dans un cas général. Vous devez vous occuper de la promotion du nœud réplique vers le nœud maître.
Réplication MySQL Master-Master
Laréplication MySQL maître-maîtrea évolué à partir de la réplication maître-esclave et résout ses principaux problèmes. Ce type de réplication suppose que vous disposiez d’au moins deux nœuds maîtres capables d’accepter des requêtes en lecture et en écriture. En outre, vous pouvez avoir plusieurs nœuds esclaves pour chacun de vos maîtres. La réplication entre les nœuds maîtres est asynchrone.
Pour
- Vous avez la possibilité de faire évoluer les demandes d’écriture non seulement en augmentant la capacité de calcul d’un seul nœud maître, mais aussi en ajoutant des nœuds maîtres supplémentaires.
- Le basculement est semi-automatique car vous avez plusieurs nœuds maîtres. Le risque que tous les nœuds maîtres tombent en panne simultanément est très faible. Si l’un des nœuds maîtres tombe en panne, il y a au moins un autre nœud maître qui peut traiter ses demandes.
Contre
- En raison de la réplication asynchrone entre tous les nœuds maîtres, vous pouvez perdre certaines transactions en cas de défaillance d’un des nœuds maîtres.
- En raison de la réplication asynchrone, vous ne pouvez pas être sûr que les sauvegardes effectuées sur chaque nœud maître contiennent les mêmes données.
- Le basculement n’est toujours pas entièrement automatisé dans le cas où vous devez promouvoir un nœud esclave en nœud maître.
Réplication MySQL MGR
La fonction deréplication de groupe MySQL est mise en œuvre par un plugin MySQL Server et fournit une réplication d’une manière totalement nouvelle basée sur une architecture de machine à états distribuée.
La réplication MySQL de groupe permet de créer des systèmes tolérants aux pannes avec une redondance qui garantit que même si certains des serveurs tombent en panne (tant que ce n’est pas la majorité), le cluster sera toujours disponible. La caractéristique unique de la réplication MGR est qu’elle vous offre une récupération automatique intégrée et une résolution des conflits.
Comment la réplication de groupe MySQL peut-elle vous aider ?
- Il n’est plus nécessaire de procéder à une commutation manuelle en cas de défaillance de l’un des serveurs.
- Assure la tolérance aux pannes.
- Permet de construire un système avec la possibilité de modifier les données sur n’importe quel serveur.
- Permet une reconfiguration automatique.
Pour
- Basculement automatique en cas de défaillance du nœud maître. Les serveurs qui appartiennent au même groupe élisent automatiquement le nouveau maître. Par conséquent, la réplication MySQL MGR peut être considérée comme une solution en grappe.
- Il s’agit d’une réplication synchrone en général, vous pouvez donc être sûr que vous ne perdrez pas de données engagées en cas de défaillance du nœud maître.
- Vous pouvez faire évoluer les lectures et les écritures en ajoutant de nouveaux nœuds maîtres et esclaves.
- Il n’impose pas de grandes restrictions de performance car il suffit de n’avoir que 2 nœuds maîtres pour un cluster MySQL à part entière.
Contre
- Il est disponible uniquement pour MySQL, mais pas pour ses forks : MariaDB et Percona.
- Un groupe est limité à 9 nœuds.
Galera Cluster (réplication MySQL multi-maître)
Galera Cluster est un cluster synchrone de bases de données avec plusieurs nœuds maîtres, basé sur la réplication synchrone. Galera joue le rôle de multi-maître et vous permet de diriger les requêtes de lecture et d’écriture vers n’importe quel nœud à tout moment. En cas de perte d’un des nœuds individuels, il n’y a pas d’interruption des opérations. Les nœuds sont initialisés automatiquement et il n’est pas nécessaire de sauvegarder manuellement la base de données et de la copier sur le nouveau nœud. Galera est une solution très sûre car elle fournit une réplication synchrone, c’est-à-dire qu’il n’y a pas de décalage visible du côté de l’esclave, les données ne sont pas perdues lorsqu’un nœud est perdu.
Pour
- Il est fiable car il garantit la sécurité des données grâce au protocole de quorum.
- Galera vous offre de véritables capacités de mise en grappe, y compris le basculement automatique.
- Les demandes de lecture sont très rapides et peuvent être mises à l’échelle efficacement.
Contre
- Il entraîne un surcoût important en termes de performances car il suppose que toutes les transactions seront validées sur au moins trois serveurs. Si vous avez des demandes d’écriture massives, cela peut entraîner une dégradation des performances même pour les requêtes de lecture.
- Il est uniquement pris en charge pour MariaDB et Percona XtraDB, mais pas pour la base de données MySQL.
Architecture MySQL HA dans Hidora
Lorsque nous avons décidé de mettre en œuvre le site support de haute disponibilité MySQL sur Hidora, nous avons pris en compte différentes considérations, notamment la fiabilité, l’évolutivité, la facilité d’installation, la facilité de configuration et de surveillance.
Par conséquent, notre architecture MySQL comprend les composants suivants :
- ProxySQL – un équilibreur de charge léger pour les bases de données alimentées par MySQL. Nous mettons en place 2 nœuds de ProxySQL pour des raisons de haute disponibilité. Il offre les fonctionnalités suivantes :
- Mise en cache des requêtes
- Acheminement des requêtes
- Intégration avec Orchestrator pour support failover
- Orchestrator – est un outil de gestion de la haute disponibilité et de la réplication de MySQL qui offre différentes fonctionnalités telles que la visualisation des topologies, la configuration de la réplication et l’audit des problèmes de réplication. Il est également capable de détecter la défaillance du maître et de vous proposer des options de basculement manuel ou automatique.
- Nœuds MySQL/MariaDB répliqués
- Nous support toutes les options de réplication les plus courantes, notamment Master-Slave, Master-Master, Group replication pour MySQL et Galera pour MariaDB.
La principale fonctionnalité disponible sur Hidora est le clustering automatique et la mise à l’échelle horizontale des nœuds MySQL/MariaDB. Cela signifie que vous pouvez gérer ces bases de données via une interface utilisateur simple sur la couche PaaS, mais pas seulement comme des machines virtuelles. Par exemple, vous pouvez augmenter le nombre de nœuds esclaves en un seul clic, et ils rejoindront automatiquement votre cluster de bases de données. Et vice versa, vous pouvez réduire le cluster en toute sécurité et supprimer facilement les nœuds inutiles.
De plus, en plus de l’interface utilisateur intégrée de Hidora, vous pouvez accéder au panneau de contrôle Orchestrator pour visualiser et surveiller le processus de réplication MySQL/MariaDB.
Comment installer les solutions MySQL HA sur Hidora ?
Comment activer la mise en grappe automatique pour les bases de données MySQL ?
- Cliquez sur NOUVEL ENVIRONNEMENT dans le tableau de bord et choisissez la base de données MySQL.
- Ensuite, vous devez appuyer sur le bouton Auto-Clustering afin d’afficher différentes options de réplication pour la base de données MySQL dans la liste déroulante correspondante. Vous pouvez choisir l’une des options suivantes :
- Maître-Esclave
- Master-Master
- Réplication de groupe à un seul primaire
- Réplication de groupes multi-primaires
Votre base de données répliquée sera créée et configurée dès que vous aurez appuyé sur le bouton « Créer ». Toute la magie sera faite derrière la scène, vous n’avez donc pas besoin d’effectuer d’actions supplémentaires.
Une fois que vous avez créé l’instance de la base de données, vous pouvez vous connecter au panneau de contrôle Orchestrator à l’aide des informations d’accès figurant dans le courriel reçu.
