Couchbase ofrece una impresionante variedad de herramientas y funciones potentes dentro de sus servicios de plataforma. En particular, Replicación entre centros de datos garantiza una replicación de datos fluida en diversas geografías, mientras que las transacciones ACID respaldan de manera sólida las cargas de trabajo transaccionales, mejorando tanto la confiabilidad como la eficiencia.
Muchos clientes suelen encontrarse con una pregunta común: ¿Por qué hay una diferencia en el recuento de documentos entre los clústeres de origen y destino al utilizar transacciones y la Replicación entre Centros de Datos (XDCR)? Ciertos tipos de documentos nunca aparecen en el clúster de destino, lo que genera confusión sobre si este problema está relacionado con XDCR. Antes de profundizar en los mecanismos subyacentes, aclaremos primero algunos términos clave.
¿Qué es XDCR?
XDCR facilita la replicación de datos entre bases de datos o cubetas que pueden residir en diferentes clústeres, proveedores de nube o centros de datos. XDCR también admite la replicación intraclúster, lo que permite la replicación de datos entre diferentes bases de datos dentro del mismo clúster.
Diseñado para clústeres de bases de datos distribuidos geográficamente, XDCR protege contra fallas de centros de datos y admite alta disponibilidad con configuraciones de clúster activo-activo. El protocolo subyacente utilizado por XDCR es el Protocolo de Cambio de Datos (DCP), que también se emplea para la replicación intraclúster, lo que garantiza una replicación de memoria a memoria de baja latencia.
XDCR ofrece operaciones unidireccionales y bidireccionales y admite la replicación activa-activa con resolución automática de conflictos. También permite la replicación filtrada para replicar subconjuntos de documentos según las necesidades del clúster de destino.
¿Qué son las transacciones?
Una transacción es una única unidad lógica de trabajo que consta de múltiples operaciones de base de datos que se ejecutan en su totalidad o no se ejecutan en absoluto. Las transacciones de Couchbase permiten ÁCIDO acciones (atómicas, consistentes, aisladas y duraderas) en la base de datos. Couchbase admite transacciones ACID distribuidas de múltiples documentos y nodos a gran escala sin sacrificar el rendimiento ni la alta disponibilidad.
¿Qué es un registro de transacción activa?
En Couchbase, los datos dentro de una base de datos o bucket se dividen en contenedores lógicos llamados vbucket, cada uno ubicado en un solo nodo. Cada cubo de servidor Couchbase tiene 1024 vbuckets (64 en MacOS). Los Registros de Transacciones Activas (ATR) son documentos de metadatos en cada vbucket que registran cada intento de transacción activa, indicando si un intento ha sido confirmado. Las entradas ATR sirven como interruptores para marcar las transacciones como confirmadas. Los ATR son creados y mantenidos por Couchbase automáticamente y se pueden identificar fácilmente por su prefijo _txn:atr-. Estos registros se pueden ver, pero no deben ser alterados por los usuarios o las aplicaciones.
¿Cómo replica XDCR los documentos de transacciones?
En Couchbase, las transacciones se limitan a un solo clúster primario y no se admiten transacciones para la configuración activo-activo. Una transacción puede implicar múltiples intentos, cada uno de los cuales crea una entrada en un documento ATR. Estas entradas son cruciales como fuentes únicas de verdad para los intentos. Los ATR residen en la colección predeterminada del segmento del primer documento mutado, a menos que se especifique lo contrario. Cada colección utilizada para los ATR contendrá eventualmente 1,024 documentos ATR. Durante la fase de preparación, las mutaciones dentro de una transacción se almacenan temporalmente en el documento atributos extendidos propiedad (XATTRs), permaneciendo invisible para el clúster de Couchbase hasta la fase de confirmación. La intención de escritura en una transacción se especifica en los XATTRs del documento y actúa como un bloqueo de escritura, impidiendo que otros clientes modifiquen el mismo documento hasta que la transacción sea confirmada o abortada. Estas intenciones de escritura funcionan como bloqueos exclusivamente para el clúster principal.
XDCR replica los datos del clúster de origen al de destino de forma asíncrona, lo que admite la consistencia eventual para las actualizaciones transaccionales. Es por ello que una confirmación (commit) en el clúster de origen no garantiza que la transacción se haya replicado a través de XDCR. Una vez que se confirma una transacción en el clúster de origen, las actualizaciones se replican al clúster de destino una por una. Esto significa que una transacción confirmada en el clúster de origen no garantiza una confirmación inmediata en el clúster de destino. En caso de conmutación por error (failover), una transacción confirmada puede perderse si no se confirma en el destino antes de dicha conmutación por error; por lo tanto, las aplicaciones deben esperar a que se completen todas las solicitudes pendientes o abortarlas antes de pasar al clúster secundario.
Pasos de la replicación transaccional
Los siguientes pasos describen la lógica de las transacciones y la replicación de datos mediante XDCR:
- Inicio de intento de transacciónCada intento de transacción por parte de la aplicación (SDK) crea una entrada en el ATR, funcionando como un bloqueo virtual. Realizado en ambos nodos, pero mostrado en uno en la imagen de abajo por simplicidad.
- Preparar cambiosLos cambios transaccionales se almacenan temporalmente en los XATTRs de los documentos de destino, sin afectar los cuerpos de los documentos. Esto puede abarcar múltiples nodos y documentos. Estos cambios temporales actúan como un bloqueo contra cualquier otra transacción en estos documentos.
- CompromisoUna vez que la lógica de la transacción se ejecuta por completo, el intento de transacción se confirma (commit), actualizando la entrada del intento en el ATR (lo cual se realiza en ambos nodos, pero se muestra en uno en la imagen a continuación por simplicidad) y se actualiza la lista de IDs de documentos involucrados en la transacción. Los actores transaccionales pueden leer la información actualizada desde los XATTRs si es necesario.
- Finalizando cambiosLos cambios transaccionales se trasladan de los XATTRs del documento a los cuerpos de los documentos (realizado por el SDK pero mostrado directamente en la imagen a continuación por simplicidad)
- Finalización y limpieza: El intento de transacción se marca como ‘Completado’ y se elimina del ATR.
- ReplicaciónLos cambios del documento recién actualizado se replican uno por uno en el clúster de destino mediante XDCR.
Conclusión
XDCR es una herramienta potente para la replicación entre diferentes centros de datos y regiones, que admite tanto la replicación unidireccional como la bidireccional con consistencia eventual para los cambios transaccionales. Por diseño, los cambios no confirmados en una transacción y los metadatos para registrar transacciones nunca se envían a los clústeres de destino, lo que garantiza la integridad y la consistencia de los datos en los entornos replicados.
Comprender estos mecanismos puede ayudar a aclarar por qué ciertos documentos podrían no aparecer en el clúster de destino de inmediato, ya que dependen de los estados transaccionales y los procesos de replicación descritos anteriormente.
Deja un comentario
Lo siento, debes estar conectado para publicar un comentario.