La replicación multimaestro es un método de replicación de bases de datos que permite almacenar datos en un grupo de computadoras y actualizarlos por cualquier miembro del grupo. Todos los miembros responden a las consultas de datos de los clientes. El sistema de replicación multimaestro es responsable de propagar las modificaciones de datos realizadas por cada miembro al resto del grupo y de resolver cualquier conflicto que pueda surgir entre los cambios simultáneos realizados por diferentes miembros.
La replicación multimaestro se puede contrastar con la replicación de réplica principal , en la que un único miembro del grupo se designa como "maestro" para un determinado elemento de datos y es el único nodo al que se le permite modificar ese elemento de datos. Los demás miembros que deseen modificar el elemento de datos deben ponerse en contacto primero con el nodo maestro. Permitir un único maestro facilita la coherencia entre los miembros del grupo, pero es menos flexible que la replicación multimaestro.
La replicación multimaestro también se puede contrastar con la agrupación en clústeres de conmutación por error , donde los servidores de réplica pasivos replican los datos maestros a fin de prepararse para la toma de control en caso de que el maestro deje de funcionar. El maestro es el único servidor activo para la interacción con el cliente.
A menudo, la comunicación y la replicación en sistemas multimaestro se gestionan a través de un tipo de algoritmo de consenso , pero también pueden implementarse mediante algoritmos personalizados o propietarios específicos del software.
Los objetivos principales de la replicación multimaestro son una mayor disponibilidad y un tiempo de respuesta más rápido del servidor. [1]
Muchos servidores de directorio se basan en el Protocolo ligero de acceso a directorios (LDAP) e implementan replicación multimaestro.
Una de las implementaciones de replicación multimaestro más frecuentes en los servidores de directorio es Active Directory de Microsoft . Dentro de Active Directory, los objetos que se actualizan en un controlador de dominio se replican a otros controladores de dominio a través de la replicación multimaestro. 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 de maestro único flexible .
CA Directory admite la replicación multimaestro.
OpenDS (y su producto sucesor OpenDJ ) implementaron la replicación multimaster desde la versión 1.0. La replicación multimaster de OpenDS/OpenDJ es asincrónica, utiliza un registro con un mecanismo de publicación-suscripción que permite escalar a una gran cantidad de nodos. La replicación de OpenDS/OpenDJ resuelve conflictos en el nivel de entrada y atributo. La replicación de OpenDS/OpenDJ se puede utilizar en una red de área amplia .
OpenLDAP , el servidor LDAP de código abierto ampliamente utilizado , implementa la replicación multimaestro desde la versión 2.4 (octubre de 2007) [1].
Amazon Aurora se compone de nodos de escritura, que replican registros de rehacer, y 6 nodos de almacenamiento. El nodo de escritura envía cambios a cada nodo de almacenamiento, cada uno de los cuales verifica si hay conflictos y luego informa la confirmación o el rechazo del cambio. [2]
Apache CouchDB utiliza un sistema de replicación multimaestro simple basado en HTTP, creado a partir del uso de un almacén de datos de solo anexión y el uso del Control de concurrencia de múltiples versiones (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 que lo anteceden, lo que constituye la base del sistema MVCC de CouchDB . Además, mantiene un índice por secuencia 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 en la base de datos de destino". [3]
El replicador de CouchDB actúa como un cliente HTTP simple que actúa tanto en una base de datos de origen como en una 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 en función de lo que encontró en el historial de la base de datos de origen . La replicación bidireccional es el resultado de simplemente realizar otra replicación con los valores de origen y destino intercambiados.
ArangoDB es un sistema de base de datos multimodelo nativo que utiliza replicación multimaestro. Los clústeres de ArangoDB utilizan el modelo maestro/maestro de CP sin un único punto de falla. Cuando un clúster encuentra una partición de red, ArangoDB prefiere mantener su consistencia interna por sobre la disponibilidad. Los clientes experimentan la misma vista de la base de datos independientemente del nodo al que se conecten. Y el clúster continúa atendiendo solicitudes incluso cuando falla una máquina. [4]
Cloudant , un sistema de base de datos distribuida, utiliza en gran medida la misma API HTTP que Apache CouchDB y ofrece la misma capacidad de replicación mediante el control de concurrencia de múltiples versiones (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 multimaestro para mantenerse sincronizados entre sí y brindar alta disponibilidad a los consumidores de API.
eXtremeDB Cluster es el subsistema de agrupamiento de la familia de productos de bases de datos integradas eXtremeDB de McObject . Mantiene la coherencia de la base de datos en varios nodos de hardware mediante la replicación de transacciones de manera sincrónica (confirmación en dos fases). Una característica importante de eXtremeDB Cluster es la replicación de transacciones , en contraste con los esquemas de replicación basados en archivos de registro, en sentencias SQL u otros que pueden o no garantizar el éxito o el fracaso de transacciones completas. En consecuencia, eXtremeDB Cluster es un sistema compatible con ACID (no 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 multimaestro mediante uno de dos métodos. La replicación multimaestro asincrónica 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 multimaestro sincrónica 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 ofrece replicación multimaestro mediante replicación peer-to-peer. Proporciona una solución escalable y de alta disponibilidad al mantener copias de datos en varios nodos. Basada en la replicación transaccional, la replicación peer-to-peer propaga cambios transaccionalmente consistentes casi en tiempo real. [5]
En un nivel básico, es posible lograr un esquema de replicación multimaster a partir de la versión MySQL 3.23 con replicación circular. A partir de ahí, MariaDB y MySQL se entregan con cierto soporte de replicación, cada uno de ellos con diferentes matices.
En términos de apoyo directo contamos con:
MariaDB: admite de forma nativa la replicación multimaster desde la versión 10.0, pero no admite la resolución de conflictos, por lo que cada master debe contener bases de datos diferentes. En MySQL, esto se denomina multifuente y está disponible desde la versión 5.7.6.
MySQL: MySQL Group Replication, un complemento para multimaestro sincrónico virtual con manejo de conflictos y recuperación distribuida, se lanzó con la versión 5.7.17.
Proyectos de clúster:
MySQL Cluster admite la detección y resolución de conflictos entre múltiples maestros desde la versión 6.3 para una verdadera capacidad multimaestro para MySQL Server.
También existe un proyecto externo, Galera Cluster, creado por codership. Archivado el 27 de septiembre de 2011 en Wayback Machine , que ofrece una verdadera capacidad multimaster, basada en una bifurcación del motor de almacenamiento InnoDB y complementos de replicación personalizados. La replicación es sincrónica, por lo que no es posible que haya conflictos.
Percona XtraDB Cluster también es una combinación de la biblioteca de replicación Galera y MySQL que admite múltiples maestros.
Existen varias opciones para la replicación sincrónica de múltiples maestros. Postgres-XL , que está disponible bajo la licencia pública de Mozilla, y PostgresXC (ahora conocido como Postgres-X2), que está disponible bajo la misma licencia que PostgreSQL, son algunos ejemplos. Tenga en cuenta que el proyecto PgCluster (archivado el 5 de julio de 2017 en Wayback Machine ) se abandonó en 2007.
La documentación de replicación para PostgreSQL [6] clasifica los diferentes tipos de replicación disponibles. Existen varias opciones para replicación multimaster distribuida, incluidas Bucardo, rubyrep y BDR Bi-Directional Replication.
BDR está pensado para su inclusión en el núcleo de PostgreSQL y se ha evaluado como un sistema que demuestra un rendimiento significativamente mejorado [7] en comparación con las opciones anteriores. BDR incluye replicación de escrituras de datos (DML), así como cambios en la definición de datos (DDL) y secuencias globales. Los nodos BDR se pueden actualizar en línea a partir de la versión 0.9 en adelante. 2ndQuadrant ha desarrollado BDR de forma continua desde 2012, y el sistema se utiliza en producción desde 2014. La última versión BDR 3.6 proporciona detección de conflictos a nivel de columna, CRDT, replicación ansiosa, coherencia de consultas de múltiples nodos y muchas otras funciones.
Dentro de Ingres Replicator, los objetos que se actualizan en un servidor Ingres pueden replicarse a otros servidores, ya sean locales o remotos, a través de la replicación multimaestro. Si falla un servidor, las conexiones de los clientes pueden redirigirse a otro servidor. No es necesario que todos los servidores Ingres de un entorno se repliquen entre sí, ya que esto podría causar un tráfico de red excesivo en implementaciones de gran tamaño. En cambio, Ingres Replicator permite que los datos apropiados se repliquen en los servidores apropiados sin un tráfico de replicación excesivo. Esto significa que algunos servidores del entorno pueden servir como candidatos para la conmutación por error, mientras que otros servidores pueden cumplir con otros requisitos, como administrar un subconjunto de columnas o tablas para una solución departamental, un subconjunto de filas para una región geográfica o una replicación unidireccional para un servidor de informes. En caso de una falla de origen, destino o red, la integridad de los datos se aplica a través de este protocolo de confirmación de dos fases al garantizar que se replique toda la transacción o que no se replique ninguna. Además, Ingres Replicator puede operar sobre RDBMS de múltiples proveedores [ ¿cuáles? ] para conectarlos.
Escalable en escritura significa que Postgres-XC se puede configurar con tantos servidores de bases de datos como desee y manejar muchas más escrituras (actualización de declaraciones SQL) en comparación con lo que un solo servidor de bases de datos no puede hacer.