Replicación multi-maestro

Una de las implementaciones de replicación multimaster más comunes en servidores de directorio es Active Directory de Microsoft . En Active Directory, los objetos que se actualizan en un controlador de dominio se replican a otros controladores de dominio mediante replicación multimaster. No es necesario que todos los controladores de dominio se repliquen entre sí, ya que esto causaría un tráfico de red excesivo en grandes implementaciones de Active Directory. En cambio, los controladores de dominio tienen un patrón de actualización complejo que garantiza que todos los servidores se actualicen de manera oportuna sin un tráfico de replicación excesivo. Sin embargo, algunas necesidades de Active Directory se satisfacen mejor con la operación flexible de un solo maestro .

CA Directory admite la replicación multi-maestro.

OpenDS (y su sucesor, OpenDJ ) implementaron la replicación multi-maestro desde la versión 1.0. La replicación multi-maestro de OpenDS/OpenDJ es asíncrona y utiliza un registro con un mecanismo de publicación-suscripción que permite escalar a un gran número de nodos. La replicación de OpenDS/OpenDJ resuelve los conflictos a nivel de entrada y atributo. Además, puede utilizarse en redes de área amplia .

OpenLDAP , el servidor LDAP de código abierto ampliamente utilizado , implementa la replicación multi-maestro desde la versión 2.4 (octubre de 2007)..

Amazon Aurora se compone de nodos de escritura, que replican los registros de rehacer, y 6 nodos de almacenamiento. El nodo de escritura envía el cambio a cada nodo de almacenamiento, cada uno de los cuales comprueba si hay conflictos y luego informa si se confirma o se rechaza el cambio. ^{[ 2 ]}

Apache CouchDB utiliza un sistema de replicación multi-maestro simple basado en HTTP, construido a partir del uso de un almacén de datos de solo escritura y el uso de Control de Concurrencia Multiversión (MVCC) .

Cada documento contiene un ID de revisión, por lo que cada registro almacena la cronología evolutiva de todos los ID de revisión anteriores hasta llegar a él mismo, lo que constituye la base del sistema MVCC de CouchDB . Además, mantiene un índice secuencial para toda la base de datos. «El proceso de replicación solo copia la última revisión de un documento, por lo que todas las revisiones anteriores que solo estaban en la base de datos de origen no se copian a la base de datos de destino». ^{[ 3 ]}

El replicador de CouchDB actúa como un cliente HTTP simple que opera tanto en la base de datos de origen como en la de destino . Compara los identificadores de secuencia actuales de la base de datos, calcula las diferencias de revisión y realiza los cambios necesarios en la base de datos de destino basándose en el historial de la base de datos de origen . La replicación bidireccional se logra simplemente intercambiando los valores de origen y destino .

ArangoDB es un sistema de base de datos multimodelo nativo que utiliza replicación multimaestro. Los clústeres en ArangoDB utilizan el modelo maestro/maestro CP sin un único punto de fallo. Cuando un clúster encuentra una partición de red, ArangoDB prioriza mantener su consistencia interna sobre la disponibilidad. Los clientes experimentan la misma vista de la base de datos independientemente del nodo al que se conecten. Además, el clúster continúa atendiendo solicitudes incluso cuando falla una máquina. ^{[ 4 ]}

Cloudant , un sistema de base de datos distribuida, utiliza prácticamente la misma API HTTP que Apache CouchDB y ofrece la misma capacidad de replicación mediante el Control de Concurrencia Multiversión (MVCC) . Las bases de datos de Cloudant pueden replicarse entre sí, pero internamente, los nodos dentro de los clústeres de Cloudant utilizan la replicación multi-maestro para mantenerse sincronizados y proporcionar alta disponibilidad a los consumidores de la API.

eXtremeDB Cluster es el subsistema de clúster para la familia de productos de bases de datos integradas eXtremeDB de McObject . Mantiene la consistencia de la base de datos en múltiples nodos de hardware mediante la replicación síncrona de transacciones (confirmación en dos fases). Una característica importante de eXtremeDB Cluster es la replicación de transacciones , a diferencia de los esquemas de replicación basados ​​en archivos de registro, sentencias SQL u otros, que pueden o no garantizar el éxito o el fracaso de transacciones completas. Por consiguiente, eXtremeDB Cluster es un sistema compatible con ACID (no con BASE ni consistencia eventual ); una consulta ejecutada en cualquier nodo del clúster devolverá el mismo resultado que si se ejecutara en cualquier otro nodo del clúster.

Los clústeres de bases de datos implementan la replicación multi-maestro mediante uno de dos métodos. La replicación multi-maestro asíncrona confirma los cambios de datos en una cola de transacciones diferidas que se procesa periódicamente en todas las bases de datos del clúster. La replicación multi-maestro síncrona utiliza la funcionalidad de confirmación en dos fases de Oracle para garantizar que todas las bases de datos del clúster tengan un conjunto de datos coherente .

Microsoft SQL proporciona replicación multi-maestro mediante replicación punto a punto. Ofrece una solución de escalabilidad horizontal y alta disponibilidad al mantener copias de datos en múltiples nodos. Basada en la replicación transaccional, la replicación punto a punto propaga cambios transaccionalmente consistentes prácticamente en tiempo real. ^{[ 5 ]}

A nivel básico, es posible implementar un esquema de replicación multi-maestro a partir de MySQL versión 3.23 con replicación circular. Más allá de esto, MariaDB y MySQL incluyen soporte para replicación, cada uno con sus propias particularidades.

En cuanto al apoyo directo, contamos con:

MariaDB: admite de forma nativa la replicación multi-maestro desde la versión 10.0, pero no admite la resolución de conflictos, por lo que cada maestro debe contener bases de datos diferentes. En MySQL, esto se denomina multi-source y está disponible desde la versión 5.7.6 .

MySQL: MySQL Group Replication, un complemento para la replicación multi-maestro síncrona virtual con manejo de conflictos y recuperación distribuida, se lanzó con la versión 5.7.17 .

Proyectos en clúster:

MySQL Cluster admite la detección y resolución de conflictos entre múltiples maestros desde la versión 6.3, lo que proporciona una verdadera capacidad multi-maestro para el servidor MySQL.

También existe un proyecto externo, Galera Cluster, creado por codership ( archivado el 27 de septiembre de 2011 en Wayback Machine) , que ofrece verdadera capacidad multi-maestro, basada en una bifurcación del motor de almacenamiento InnoDB y complementos de replicación personalizados. La replicación es síncrona, por lo que no es posible que se produzcan conflictos.

Percona XtraDB Cluster también es una combinación de la biblioteca de replicación Galera y MySQL, que admite la arquitectura multi-maestro.

Existen diversas opciones para la replicación síncrona multi-maestro. Postgres-XL , disponible bajo la Licencia Pública de Mozilla, y PostgresXC (ahora conocido como Postgres-X2 ), disponible bajo la misma licencia que PostgreSQL, son algunos ejemplos. Cabe destacar que el proyecto PgCluster ( archivado el 5 de julio de 2017 en Wayback Machine ) fue abandonado en 2007.

La documentación de replicación para PostgreSQL ^{[ 6 ]} clasifica los diferentes tipos de replicación disponibles. Existen varias opciones para la replicación distribuida multi-maestro, incluyendo Bucardo , rubyrep y la replicación bidireccional BDR .

En Ingres Replicator, los objetos actualizados en un servidor Ingres se pueden replicar en otros servidores, tanto locales como remotos, mediante replicación multimaster. Si un servidor falla, las conexiones de los clientes se redirigen a otro. No es necesario que todos los servidores Ingres de un entorno se repliquen entre sí, ya que esto podría generar un tráfico de red excesivo en implementaciones de gran tamaño. En cambio, Ingres Replicator permite replicar los datos adecuados en los servidores correspondientes sin generar un tráfico de replicación excesivo. Esto significa que algunos servidores del entorno pueden funcionar como candidatos para la conmutación por error, mientras que otros pueden cumplir con otros requisitos, como la gestión de un subconjunto de columnas o tablas para una solución departamental, un subconjunto de filas para una región geográfica o la replicación unidireccional para un servidor de informes. En caso de fallo de origen, destino o red, la integridad de los datos se garantiza mediante este protocolo de confirmación en dos fases, asegurando que se replique la transacción completa o ninguna. Además, Ingres Replicator puede operar sobre sistemas de gestión de bases de datos relacionales (RDBMS) de múltiples proveedores para conectarlos.