4 Solutions pour la réplication synchrone active-active MySQL

MySQL est un système de gestion de base de données relationnelles open source largement utilisé pour gérer et stocker des données structurées. Il est connu pour sa simplicité, sa facilité d'utilisation et sa scalabilité, ce qui en fait un choix populaire pour diverses applications allant des petits sites web aux grandes entreprises.

Pour la synchronisation de données en temps réel, l'exigence principale est de l'implémenter à partir des journaux, ce qui permet une synchronisation de données quasi en temps réel. Cela n'impose aucune contrainte supplémentaire sur la conception et la mise en œuvre de la base de données en elle-même. Le but de la réplication synchrone active-active de MySQL synchronous replication est d'assurer une disponibilité continue et une tolérance aux pannes. Voici 4 méthodes pour réaliser la réplication synchrone active-active de MySQL.

Réplication master-master basée sur la fonction de réplication native de la base de données MySQL

Elle est généralement adaptée aux déploiements de petite à moyenne échelle.

Dans cette architecture, deux nœuds peuvent adopter un mode maître-maître simple et utiliser une connexion dédiée. En cas de panne du nœud master_A, les connexions d'application peuvent rapidement basculer vers le nœud master_B, et vice versa.

Pour éviter les scénarios de cerveau divisé, où les deux nœuds écrivent des données contradictoires, il est important de définir des valeurs différentes pour auto-increment-increment et auto-increment-offset sur les deux nœuds. Cela est dû au fait que si le nœud maître s'arrête de manière inattendue ou devient indisponible, il est possible que certains événements binlog ne soient pas répliqués vers le nœud esclave. Dans ces cas, il peut y avoir des conflits entre la valeur auto-incrémentée générée sur l'esclave et la valeur originale sur le maître.

Cependant, si un mécanisme de tolérance aux pannes approprié est en place pour résoudre les conflits d'ID auto-incrémentiels maître-esclave, il est possible d'éviter d'utiliser cette méthode. Dans les versions mises à jour de MySQL 5.7+, l'utilisation de la réplication multi-thread peut réduire considérablement la latence de réplication. De plus, une autre solution alternative qui est particulièrement sensible à la latence de réplication est la réplication semi-synchrone, qui offre pratiquement aucun retard. Cependant, cela peut entraîner une diminution des performances de concurrence des transactions, en particulier en écriture bidirectionnelle. Une évaluation complète est nécessaire pour prendre une décision.

Solution basée sur la réplication Galera

Galera est un mécanisme de réplication de synchronisation de données multi-maître fourni par Codership. Il permet la réplication synchrone des données ainsi que les opérations de lecture et d'écriture entre plusieurs nœuds, assurant une haute disponibilité et une cohérence des données dans la base de données. Les principales solutions de haute disponibilité basées sur Galera sont MariaDB Galera Cluster et Percona XtraDB Cluster (PXC).

Actuellement, le PXC est plus couramment utilisé et offre une stricte cohérence des données, ce qui le rend particulièrement adapté au commerce électronique. Cependant, le PXC présente également ses limitations. Dans les scénarios avec un grand volume de transactions simultanées, il est recommandé d'utiliser un réseau InfiniBand pour réduire la latence du réseau. Cela est dû au fait que le PXC peut subir une amplification des écritures et l'effet de goulot d'étranglement, entraînant une perte importante d'efficacité concurrentielle. De manière similaire à la réplication semi-synchrone, la réplication Galera est généralement limitée à trois nœuds. En outre, les fluctuations du réseau peuvent causer des problèmes de performance et de stabilité.

Solution basée sur la Réplication de Groupe

MGR (MySQL Group Replication) est une solution de haute disponibilité officiellement introduite par MySQL. Elle fournit des garanties de forte cohérence des données entre les nœuds d'un cluster de base de données via le protocole Paxos. MGR repose sur la technologie de réplication native et est proposée sous forme de plugin. Elle permet à tous les nœuds du cluster d'être en écriture, ce qui résout les limitations de performance d'un seul cluster, résout le problème des cerveaux divisés causés par la partition du réseau et améliore la fiabilité des données répliquées.

Cependant, la réalité est quelque peu dure. Actuellement, il n'y a pas beaucoup de premiers adopteurs de MGR. De plus, il ne prend en charge que les tables InnoDB et nécessite que chaque table ait une clé primaire pour la détection des conflits de jeu d'écriture. La fonctionnalité GTID doit être activée et le format du journal binaire doit être défini sur ROW pour l'élection du leader et le jeu d'écriture.

COMMIT peut potentiellement échouer, de manière similaire aux scénarios d'échec du niveau d'isolation par instantané. Actuellement, un cluster MGR (MySQL Group Replication) prend en charge un maximum de 9 nœuds. Il ne prend pas en charge les clés étrangères et les fonctionnalités de point de sauvegarde, ce qui empêche les vérifications de contraintes globales et les annulations partielles. Le journal binaire ne prend pas en charge le checksum des événements binlog.

Solution basée sur Canal

Pour la synchronisation en temps réel des bases de données, Alibaba a un projet open-source dédié appelé Otter, qui permet la réplication synchrone des bases de données distribuées. L'idée centrale d'Otter repose toujours sur la capture des journaux de données incrémentiels des bases de données pour réaliser une réplication quasi en temps réel. Otter s'appuie lui-même sur un autre projet open-source appelé Canal, qui se concentre sur la capture des informations de journal de synchronisation incrémentielle des bases de données.

Actuellement, Otter se concentre sur l'atteinte de la réplication synchrone entre les bases de données MySQL. Il utilise des technologies similaires pour réaliser la réplication synchrone bidirectionnelle entre deux bases de données MySQL. Il est important de noter que bidirectionnel signifie ici que les données peuvent être synchronisées de A vers B ou de B vers A, mais elle peut être unidirectionnelle à un moment précis.

Le processus de réplication maître-esclave peut être divisé en trois étapes :

1. Le maître enregistre les modifications dans le journal binaire, qui sont connues sous le nom d'événements du journal binaire. Ces événements peuvent être affichés à l'aide de la commande "show binlog events".

2. L'esclave copie les événements du journal binaire du maître vers son propre journal de relais.

3. L'esclave réappliquera séquentiellement les événements enregistrés dans le journal de relais pour appliquer les modifications du maître à ses propres données.

Quant au principe du Canal, il est relativement simple :

1. Canal simule le protocole d'interaction d'un esclave MySQL en se faisant passer pour un esclave MySQL et en envoyant une demande de dump au maître MySQL.

2. À la réception de la demande de dump, le maître MySQL commence à pousser les journaux binaires vers l'esclave (qui est Canal).

3. Canal analyse ensuite les objets du journal binaire (initialement au format flux d'octets) pour extraire les informations pertinentes.

Sauvegarde des bases de données MySQL avec Vinchin Backup & Recovery

Pour mieux protéger les données, il est recommandé de sauvegarder vos bases de données. Vinchin Backup & Recovery offre des fonctionnalités puissantes pour protéger vos bases de données dans les machines virtuelles et les serveurs physiques. En s'associant bien aux sauvegardes au niveau des machines virtuelles, une double assurance est offerte aux utilisateurs d'environnements virtuels pour leurs données commerciales clés et systèmes d'information.

Vinchin Backup & Recovery prend en charge la protection de Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro et MariaDB installés sur des machines physiques et virtuelles avec des fonctionnalités puissantes de sauvegarde et de restauration de bases de données. Il offre également des stratégies de sauvegarde complète, différentielle, incrémentielle et de journal de transactions pour que vous puissiez définir votre propre plan de sauvegarde selon vos besoins.

Vinchin Backup & Recovery prend en charge des sauvegardes chaudes efficaces sans affecter le fonctionnement normal des bases de données et il est facile de créer une tâche de sauvegarde personnalisée pour la base de données.

1 Sélectionnez la base de données cible

2 Sélectionnez le stockage de sauvegarde

3 Sélectionnez les stratégies de sauvegarde

4 Soumettre l'offre d'emploi

Vous pouvez commencer à utiliser ce système puissant avec une période d'essai gratuite complète de 60 jours. Cliquez simplement sur le bouton pour obtenir le package d'installation. Vous pouvez cliquer ici pour en savoir plus sur comment sauvegarder MySQL avec Vinchin Backup & Recovery.

Conclusion

La réplication synchrone active-active de MySQL est conçue pour fournir une haute disponibilité et une flexibilité. Elle permet à plusieurs instances MySQL d'être actives simultanément et de synchroniser les données entre elles, autorisant des opérations de lecture et d'écriture bidirectionnelles. Elle garantit une disponibilité continue, un équilibrage de charge, une cohérence des données et une flexibilité. Cependant, une configuration et une gestion appropriées sont cruciales, et le choix des solutions et des outils d'implémentation dépend des exigences spécifiques.

Pour protéger efficacement les données de la base de données, vous pouvez choisir Vinchin Backup & Recovery pour faciliter la sauvegarde et la restauration des bases de données. Ne manquez pas l'essai gratuit.