Réplication multi-maîtres - Multi-master replication

La réplication multi-maîtres est une méthode de réplication de base de données qui permet aux données d'être stockées par un groupe d'ordinateurs et mises à jour par n'importe quel membre du groupe. Tous les membres sont réactifs aux requêtes de données des clients. Le système de réplication multimaître est responsable de la propagation des modifications de données apportées par chaque membre au reste du groupe et de la résolution des conflits pouvant survenir entre les modifications simultanées apportées par différents membres.

La réplication multimaître peut être comparée à la réplication de réplication principale, dans laquelle un seul membre du groupe est désigné comme « maître » pour une donnée donnée et est le seul nœud autorisé à modifier cet élément de données. Les autres membres souhaitant modifier la donnée doivent d'abord contacter le nœud maître. Autoriser un seul maître permet d'obtenir plus facilement la cohérence entre les membres du groupe, mais est moins flexible que la réplication multi-maîtres.

La réplication multi-maîtres peut également être comparée au clustering de basculement où les serveurs de répliques passives répliquent les données principales afin de se préparer à la prise de contrôle au cas où le maître cesserait de fonctionner. Le maître est le seul serveur actif pour l'interaction client.

Souvent, la communication et la réplication dans les systèmes multi-maîtres sont gérées via un type d' algorithme de consensus , mais peuvent également être mises en œuvre via des algorithmes personnalisés ou propriétaires spécifiques au logiciel.

Les objectifs principaux de la réplication multi-maîtres sont une disponibilité accrue et un temps de réponse plus rapide du serveur.

Avantages

  • Accessibilité : Si un maître échoue, les autres maîtres continuent de mettre à jour la base de données .
  • Accès distribué : les maîtres peuvent être situés sur plusieurs sites physiques, c'est-à-dire répartis sur le réseau.

Désavantages

  • Cohérence : la plupart des systèmes de réplication multi-maîtres ne sont que faiblement cohérents, c'est-à-dire paresseux et asynchrones, violant les propriétés ACID .
  • Performances : les systèmes de réplication Eager sont complexes et augmentent la latence de communication .
  • Intégrité : des problèmes tels que la résolution des conflits peuvent devenir insolubles à mesure que le nombre de nœuds impliqués augmente et que la latence augmente.

Implémentations

Services d'annuaire

De nombreux serveurs d'annuaire sont basés sur le protocole LDAP ( Lightweight Directory Access Protocol ) et implémentent une réplication multimaître.

Active Directory

L'une des implémentations de réplication multi-maîtres les plus répandues dans les serveurs d'annuaire est l' Active Directory de Microsoft . Dans Active Directory, les objets mis à jour sur un contrôleur de domaine sont ensuite répliqués sur d'autres contrôleurs de domaine via la réplication multimaître. Il n'est pas nécessaire que tous les contrôleurs de domaine se répliquent les uns avec les autres, car cela entraînerait un trafic réseau excessif dans les grands déploiements Active Directory. Au lieu de cela, les contrôleurs de domaine ont un modèle de mise à jour complexe qui garantit que tous les serveurs sont mis à jour en temps opportun sans trafic de réplication excessif. Certains besoins d'Active Directory sont cependant mieux servis par un fonctionnement à maître unique flexible .

Annuaire CA

CA Directory prend en charge la réplication multimaître.

OpenDS/OpenDJ

OpenDS (et son successeur OpenDJ ) a implémenté le multi-maître depuis la version 1.0. La réplication multi-maître OpenDS/OpenDJ est asynchrone, elle utilise un journal avec un mécanisme de publication-abonnement qui permet de s'adapter à un grand nombre de nœuds. La réplication OpenDS/OpenDJ résout les conflits au niveau de l'entrée et des attributs. La réplication OpenDS/OpenDJ peut être utilisée sur un réseau étendu .

OpenLDAP

OpenLDAP , le serveur LDAP open source largement utilisé , implémente la réplication multi-maître depuis la version 2.4 (octobre 2007) [1] .

Systèmes de gestion de bases de données

Aurore amazonienne

Amazon Aurora est composé de nœuds d'écriture, qui répliquent les enregistrements de rétablissement, et de 6 nœuds de stockage. Le nœud d'écriture envoie la modification à chaque nœud de stockage, dont chacun vérifie les conflits puis signale la confirmation ou le rejet de la modification.

Apache CouchDB

Apache CouchDB utilise un système de réplication multimaître simple basé sur HTTP, construit à partir de son utilisation d'un magasin de données à ajout uniquement et de l'utilisation du contrôle de simultanéité multiversion (MVCC) .

Chaque document contient un ID de révision, de sorte que chaque enregistrement stocke la chronologie évolutive de tous les ID de révision précédents jusqu'à lui-même, ce qui constitue la base du système MVCC de CouchDB . De plus, il conserve un index par séquence pour l'ensemble de la base de données. "Le processus de réplication copie uniquement la dernière révision d'un document, de sorte que toutes les révisions précédentes qui se trouvaient uniquement sur la base de données source ne sont pas copiées dans la base de données de destination."

Le réplicateur CouchDB agit comme un simple client HTTP agissant à la fois sur une base de données source et cible . Il compare les ID de séquence actuels pour la base de données, calcule les différences de révision et apporte les modifications nécessaires à la cible en fonction de ce qu'il a trouvé dans l'historique de la base de données source . La réplication bidirectionnelle est le résultat d'une simple réplication avec les valeurs source et cible permutées.

ArangoDB

ArangoDB est un système de base de données multi-modèle natif utilisant la réplication multi-maître. Les clusters dans ArangoDB utilisent le modèle maître/maître CP sans point de défaillance unique. Lorsqu'un cluster rencontre une partition réseau, ArangoDB préfère conserver sa cohérence interne à la disponibilité. Les clients bénéficient de la même vue de la base de données, quel que soit le nœud auquel ils se connectent. De plus, le cluster continue de traiter les demandes même lorsqu'une machine tombe en panne.

Cloudant

Cloudant , un système de base de données distribué, utilise en grande partie la même API HTTP qu'Apache CouchDB , et expose la même capacité de réplication à l'aide de Multiversion Concurrency Control (MVCC) . Les bases de données Cloudant peuvent se répliquer entre elles, mais en interne, les nœuds des clusters Cloudant utilisent la réplication multimaître pour rester synchronisés les uns avec les autres et fournir une haute disponibilité aux consommateurs d'API.

Cluster eXtremeDB

eXtremeDB Cluster est le sous-système de clustering de la famille de produits de base de données intégrée eXtremeDB de McObject . Il maintient la cohérence de la base de données sur plusieurs nœuds matériels en répliquant les transactions de manière synchrone (validation en deux phases). Une caractéristique importante d'eXtremeDB Cluster est la réplication des transactions , contrairement aux schémas de réplication basés sur des fichiers journaux, des instructions SQL ou d'autres schémas de réplication qui peuvent ou non garantir le succès ou l'échec de transactions entières. En conséquence, eXtremeDB Cluster est un système compatible ACID (pas BASE ou cohérence éventuelle ) ; une requête exécutée sur n'importe quel nœud de cluster renverra le même résultat que si elle était exécutée sur n'importe quel autre nœud de cluster.

Oracle

Les clusters de bases de données implémentent la réplication multimaître à l'aide de l'une des deux méthodes. La réplication multi-maîtres asynchrone valide les modifications de données dans une file d'attente de transactions différées qui est périodiquement traitée sur toutes les bases de données du cluster. La réplication multimaître synchrone utilise la fonctionnalité de validation en deux phases d'Oracle pour garantir que toutes les bases de données avec le cluster disposent d'un ensemble de données cohérent .

Microsoft SQL

Microsoft SQL fournit une réplication multimaître via une réplication d'égal à égal. Il fournit une solution évolutive et à haute disponibilité en conservant des copies des données sur plusieurs nœuds. Construite sur la base de la réplication transactionnelle, la réplication peer-to-peer propage des changements cohérents sur le plan transactionnel en temps quasi réel.

MySQL / MariaDB

A un niveau basique, il est possible de réaliser un schéma de réplication multi-maître à partir de MySQL version 3.23 avec une réplication circulaire. À partir de là, MariaDB et MySQL sont livrés avec une prise en charge de la réplication, chacun avec des nuances différentes.

En termes de soutien direct, nous avons :

MariaDB : prend en charge nativement la réplication multi-maîtres depuis la version 10.0, mais la résolution des conflits n'est pas prise en charge, donc chaque maître doit contenir des bases de données différentes. Sur MySQL, cela se nomme multi-source disponible depuis la version 5.7.6 .

MySQL : MySQL Group Replication, un plugin pour multi-maître synchrone virtuel avec gestion des conflits et récupération distribuée a été publié avec 5.7.17 .

Projets de cluster :

MySQL Cluster prend en charge la détection et la résolution des conflits entre plusieurs maîtres depuis la version 6.3 pour une véritable capacité multi-maîtres pour le serveur MySQL.

Il existe également un projet externe, Galera Cluster créé par codership , qui fournit une véritable capacité multi-maîtres, basée sur un fork du moteur de stockage InnoDB et des plug-ins de réplication personnalisés. La réplication est synchrone, donc aucun conflit n'est possible.

Percona XtraDB Cluster est également une combinaison de la bibliothèque de réplication Galera et de MySQL prenant en charge le multi-maître.

PostgreSQL

Il existe différentes options pour la réplication multi-maîtres synchrone. Postgres-XL qui est disponible sous la licence publique Mozilla, et PostgresXC (maintenant connu sous le nom de Postgres-X2 ) qui est disponible sous la même licence que PostgreSQL lui-même sont des exemples. A noter que le projet PgCluster ( Archivé 2017-07-05 à la Wayback Machine ) a été abandonné en 2007.

La documentation de réplication pour PostgreSQL classe les différents types de réplication disponibles. Il existe diverses options pour le multi-maître distribué, y compris Bucardo , rubyrep et BDR bi-directionnel de réplication .

BDR PostgreSQL

BDR vise à une inclusion éventuelle dans le noyau PostgreSQL et a été évalué comme démontrant des performances considérablement améliorées par rapport aux options précédentes. BDR inclut la réplication des écritures de données (DML), ainsi que les modifications apportées à la définition des données (DDL) et aux séquences globales. Les nœuds BDR peuvent être mis à niveau en ligne à partir de la version 0.9. 2ndQuadrant a développé BDR en continu depuis 2012, avec le système utilisé en production depuis 2014. La dernière version BDR 3.6 fournit la détection des conflits au niveau des colonnes, les CRDT, la réplication rapide, la cohérence des requêtes multi-nœuds et de nombreuses autres fonctionnalités.

Ingres

Dans Ingres Replicator, les objets mis à jour sur un serveur Ingres peuvent ensuite être répliqués sur d'autres serveurs, qu'ils soient locaux ou distants via une réplication multimaître. Si un serveur tombe en panne, les connexions client peuvent être redirigées vers un autre serveur. Il n'est pas nécessaire que tous les serveurs Ingres d'un environnement se répliquent les uns avec les autres, car cela pourrait entraîner un trafic réseau excessif dans les grandes implémentations. Au lieu de cela, Ingres Replicator permet de répliquer les données appropriées sur les serveurs appropriés sans trafic de réplication excessif. Cela signifie que certains serveurs de l'environnement peuvent servir de candidats au basculement tandis que d'autres serveurs peuvent répondre à d'autres exigences telles que la gestion d'un sous-ensemble de colonnes ou de tables pour une solution départementale, un sous-ensemble de lignes pour une région géographique ou une réplication unidirectionnelle pour un reporting. serveur. En cas de défaillance d'une source, d'une cible ou d'un réseau, l'intégrité des données est assurée via ce protocole de validation en deux phases en garantissant que l'intégralité de la transaction est répliquée ou qu'aucune d'entre elles ne l'est. De plus, Ingres Replicator peut fonctionner sur les SGBDR de plusieurs fournisseurs pour les connecter.

Voir également

Les références

Liens externes