La replicación multimaestro es un método de replicación de la base de datos que permite que los datos sean almacenados por un grupo de computadoras y actualizados 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 resolver los conflictos que puedan surgir entre cambios simultáneos realizados por diferentes miembros.
La replicación multimaestro se puede contrastar con la replicación de réplica primaria , en la que un solo miembro del grupo se designa como "maestro" para una determinada pieza de datos y es el único nodo al que se le permite modificar ese elemento de datos. Otros miembros que deseen modificar el elemento de datos deben comunicarse primero con el nodo principal. Permitir un solo maestro facilita lograr la coherencia entre los miembros del grupo, pero es menos flexible que la replicación de múltiples maestros.
La replicación multimaestro también se puede contrastar con la agrupación en clústeres de conmutación por error, en la que los servidores de réplica pasivos replican los datos maestros para 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 manejan a través de un tipo de algoritmo de consenso , pero también se pueden implementar a través de algoritmos personalizados o propietarios específicos del software.
Los propósitos principales de la replicación multimaestro son una mayor disponibilidad y un tiempo de respuesta del servidor más rápido. [1]
Ventajas
- Accesibilidad : si un maestro falla, otros maestros continúan actualizando la base de datos .
- Acceso distribuido: los maestros pueden estar ubicados en varios sitios físicos, es decir, distribuidos a través de la red.
Desventajas
- Coherencia : la mayoría de los sistemas de replicación multimaestro son sólo vagamente coherentes, es decir, perezosos y asincrónicos, violando las propiedades de ACID .
- Rendimiento : los sistemas de replicación ávidos son complejos y aumentan la latencia de la comunicación .
- Integridad : problemas como la resolución de conflictos pueden volverse intratables a medida que aumenta la cantidad de nodos involucrados y aumenta la latencia.
Implementaciones
Directorio de Servicios
Muchos servidores de directorio se basan en el Protocolo ligero de acceso a directorios (LDAP) e implementan la replicación multimaestro.
Directorio Activo
Una de las implementaciones de replicación con varios maestros más prevalentes en los servidores de directorio es Microsoft 's Active Directory . Dentro de Active Directory, los objetos que se actualizan en un controlador de dominio luego se replican en 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 provocarí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 tráfico de replicación excesivo. Sin embargo, algunas necesidades de Active Directory se satisfacen mejor con la operación de maestro único flexible .
Directorio de CA
CA Directory admite la replicación multimaestro.
OpenDS / OpenDJ
OpenDS (y su producto sucesor OpenDJ ) implementó multimaestro desde la versión 1.0. La replicación multimaestro de OpenDS / OpenDJ es asíncrona, 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 a nivel de entrada y de atributo. La replicación de OpenDS / OpenDJ se puede utilizar en una red de área amplia .
OpenLDAP
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] .
Sistemas de gestión de bases de datos
Amazonas Aurora
Amazon Aurora se compone de nodos de escritura, que replican los registros de rehacer, y 6 nodos de almacenamiento. El nodo escritor envía el cambio 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
Apache CouchDB utiliza un sistema de replicación multimaestro simple, basado en HTTP, construido a partir de su uso de un almacén de datos de solo adición y el uso de Control de concurrencia multiversion (MVCC) .
Cada documento contiene un ID de revisión, por lo que cada registro almacena la línea de tiempo evolutiva de todos los ID de revisión anteriores que conducen a sí mismo, lo que proporciona 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 estaban solo en la base de datos de origen no se copian en la base de datos de destino". [3]
El replicador CouchDB actúa como un simple cliente HTTP que actúa tanto en una fuente como base de datos de destino . Compara los ID de secuencia actuales para la base de datos, calcula las diferencias de revisión y realiza los cambios necesarios en la base de datos. objetivo basado en lo que encontró en la historia de la base de datos fuente . La replicación bidireccional es el resultado de simplemente hacer otra replicación con el fuente y valores objetivo intercambiados.
ArangoDB
ArangoDB es un sistema nativo de base de datos multimodelo que utiliza replicación multimaestro. Los clústeres en ArangoDB utilizan el modelo CP maestro / maestro sin un solo punto de falla. Cuando un clúster encuentra una partición de red, ArangoDB prefiere 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. Y el clúster continúa atendiendo solicitudes incluso cuando falla una máquina. [4]
Cloudant
Cloudant , un sistema de base de datos distribuido, utiliza en gran medida la misma API HTTP que Apache CouchDB y expone la misma capacidad de replicación mediante el control de simultaneidad multiversion (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.
Clúster eXtremeDB
eXtremeDB Cluster es el subsistema de agrupación en clúster para la familia de productos de base de datos incorporada eXtremeDB de McObject . Mantiene la consistencia de la base de datos en múltiples nodos de hardware replicando transacciones de manera síncrona (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, basados en sentencias SQL u otros esquemas que pueden garantizar o no 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.
Oráculo
Los clústeres de bases de datos implementan la replicación multimaestro mediante uno de dos métodos. La replicación multimaestro 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 multimaestro sincrónica utiliza la funcionalidad de confirmación en dos fases de Oracle para garantizar que todas las bases de datos con el clúster tengan un conjunto de datos coherente .
Microsoft SQL
Microsoft SQL proporciona replicación multimaestro a través de la replicación de igual a igual. Proporciona una solución de escalabilidad horizontal y alta disponibilidad al mantener copias de datos en varios nodos. Construida sobre la base de la replicación transaccional, la replicación peer-to-peer propaga cambios transaccionales consistentes casi en tiempo real. [5]
MySQL / MariaDB
En un nivel básico, es posible lograr un esquema de replicación multimaestro comenzando con MySQL versión 3.23 con replicación circular. Partiendo de eso, MariaDB y MySQL se envían con algún soporte de replicación, cada uno de ellos con diferentes matices.
En términos de soporte directo tenemos:
MariaDB: admite de forma nativa la replicación multimaestro desde la versión 10.0, pero no se admite la resolución de conflictos, por lo que cada maestro debe contener diferentes bases de datos. En MySQL, esto se denomina fuente múltiple disponible desde la versión 5.7.6 .
MySQL: MySQL Group Replication, un complemento para multimaestro síncrono virtual con manejo de conflictos y recuperación distribuida se lanzó con 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 hay un proyecto externo, Galera Cluster creado por codificación , que proporciona una verdadera capacidad multimaestro, 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 ningún conflicto.
Percona XtraDB Cluster también es una combinación de la biblioteca de replicación Galera y el soporte multimaestro de MySQL.
PostgreSQL
Existen varias opciones para la replicación multimaestro síncrona. 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 el propio PostgreSQL, son 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] categoriza los diferentes tipos de replicación disponibles. Existen varias opciones para la distribución multi-master, incluyendo Bucardo , rubyrep y BDR bidireccional de replicación .
PostgreSQL BDR
BDR tiene como objetivo la inclusión eventual en el núcleo de PostgreSQL y ha sido evaluado por demostrar un rendimiento significativamente mejorado [7] con respecto a opciones anteriores. BDR incluye la 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. 2ndQuadrant ha desarrollado BDR continuamente desde 2012, con el sistema utilizado en producción desde 2014. La última versión BDR 3.6 proporciona detección de conflictos a nivel de columna, CRDT, replicación ávida, consistencia de consultas de múltiples nodos y muchas otras características.
Ingres
Dentro de Ingres Replicator, los objetos que se actualizan en un servidor Ingres pueden luego replicarse en otros servidores, ya sean locales o remotos, mediante la replicación multimaestro. Si un servidor falla, las conexiones del cliente se pueden redirigir a otro servidor. No es necesario que todos los servidores Ingres de un entorno se repliquen entre sí, ya que esto podría provocar un tráfico de red excesivo en grandes implementaciones. En cambio, Ingres Replicator permite que los datos adecuados se repliquen en los servidores adecuados sin tráfico de replicación excesivo. Esto significa que algunos servidores en el 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 replicación unidireccional para un informe. servidor. En el caso de una falla en la fuente, el destino o la red, la integridad de los datos se aplica a través de este protocolo de compromiso de dos fases, asegurando que la transacción completa se replica o ninguna. Además, Ingres Replicator puede operar sobre RDBMS de múltiples proveedores [ ¿cuál? ] para conectarlos.
Ver también
- Operación de maestro único flexible
- Directorio Activo
- Sistema de gestión de bases de datos distribuidas
- Transferencia de zona DNS
- Replicación optimista
Referencias
- ^ Postgres-XC Archivado 2012-07-01 en Wayback Machine bajo ¿Qué es Postgres-XC? :
Escritura escalable significa que Postgres-XC se puede configurar con tantos servidores de base de datos como desee y manejar muchas más escrituras (actualización de declaraciones SQL) en comparación con lo que no puede hacer un solo servidor de base de datos
- ^ "Cree aplicaciones MySQL de alta disponibilidad con Amazon Aurora Multi-Master" .
- ^ "Replicación de Apache CouchDB" . Fundación Apache - Proyecto Apache CouchDB.
- ^ "Arquitectura de clúster de ArangoDB" . ArangoDB - Arquitectura de ArangoDB.
- ^ Replicación transaccional de igual a igual
- ^ Comparación de diferentes soluciones de replicación para PostgreSQL Como se encuentra en la documentación de PostgreSQL 9. Consultado el 8 de mayo de 2012.
- ^ Rendimiento de BDR Petr Jelinek, 2ndQuadrant. Consultado el 10 de julio de 2014.
enlaces externos
- Modelo de replicación de Active Directory
- Términos y definiciones para la replicación de bases de datos
- SymmetricDS es un software de sincronización de datos independiente de la base de datos . Utiliza tecnologías web y de bases de datos para replicar tablas entre bases de datos relacionales casi en tiempo real. El software se diseñó para adaptarse a una gran cantidad de bases de datos, funcionar en conexiones de ancho de banda bajo y soportar períodos de interrupción de la red. Es compatible con MySQL , Oracle , SQL Server , PostgreSQL , DB2 , Firebird , Interbase , HSQLDB , H2 , Apache Derby , Informix , Greenplum , SQLite , Sybase ASE y Sybase ASA . Con licencia tanto de código abierto ( GPL ) como comerciales.
- Daffodil Replicator es una herramienta de Java para la sincronización de datos , la migración de datos y la copia de seguridad de datos entre varios servidores de bases de datos. Daffodil Replicator funciona sobre el controlador JDBC estándar y admite la replicación en bases de datos heterogéneas. En la actualidad, admite las siguientes bases de datos: Microsoft SQL Server , Oracle , base de datos Daffodil, DB2 , Apache Derby , MySQL y PostgreSQL . Daffodil Replicator está disponible en versiones empresariales (comerciales) y de código abierto (con licencia GPL ).
- Proyecto de directorio abierto de DMOZ: página de replicación de base de datos