Couchbase ofrece una impresionante gama de potentes herramientas y funciones dentro de su plataforma de servicios. En particular, Replicación entre centros de datos garantiza una replicación de datos sin fisuras en distintas geografías, mientras que las transacciones ACID soportan con solidez las cargas de trabajo transaccionales, mejorando tanto la fiabilidad como la eficiencia.
Muchos clientes se encuentran a menudo con una pregunta común: ¿Por qué hay una diferencia en el recuento de documentos entre los clústeres de origen y destino cuando se utilizan transacciones y Replicación entre Centros de Datos (XDCR)? Ciertos tipos de documentos nunca aparecen en el clúster de destino, lo que lleva a la confusión sobre si este problema está relacionado con XDCR. Antes de profundizar en los mecanismos subyacentes, aclaremos algunos términos clave.
¿Qué es XDCR?
XDCR facilita la replicación de datos entre bases de datos o cubos 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 replicar 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 frente a fallos del centro de datos y admite una alta disponibilidad con configuraciones de clúster activo-activo. El protocolo subyacente utilizado por XDCR es el Data Change Protocol (DCP), que también se emplea para la replicación intraclúster, garantizando 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 en función de las necesidades del clúster de destino.
¿Qué son las transacciones?
Una transacción es una única unidad lógica de trabajo que consiste en múltiples operaciones de base de datos que se ejecutan como un todo o no se ejecutan en absoluto. Las transacciones de Couchbase permiten ÁCIDO (atómicas, consistentes, aisladas y duraderas) en la base de datos. Couchbase admite transacciones ACID distribuidas multidocumento y multinodo a escala sin sacrificar el rendimiento ni la alta disponibilidad.
¿Qué es un Registro de Transacciones Activas?
En Couchbase, los datos de una base de datos o bucket se dividen en contenedores lógicos denominados vbucketcada uno de los cuales reside en un único nodo. Cada bucket del servidor Couchbase tiene 1024 vbucket (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 comprometido. Las entradas ATR sirven como interruptores para marcar transacciones como comprometidas. Los ATRs son creados y mantenidos por Couchbase automáticamente y pueden ser fácilmente identificados por su prefijo _txn:atr-. Estos registros pueden ser visualizados pero no deben ser alterados por usuarios o aplicaciones.
¿Cómo replica XDCR los documentos de transacción?
En Couchbase, las transacciones están limitadas a un único cluster primario y las transacciones no están soportadas para la configuración activo-activo. Una transacción puede involucrar múltiples intentos, cada uno creando una entrada en un documento ATR. Estas entradas son cruciales como fuentes únicas de verdad para los intentos. Las ATRs residen en la colección por defecto del bucket del primer documento mutado a menos que se especifique lo contrario. Cada colección utilizada para las RTAs contendrá finalmente 1.024 documentos RTA. Durante la fase de preparación, las mutaciones dentro de una transacción se escenifican en la colección de un documento atributos ampliados (XATTRs), permaneciendo invisible al cluster de Couchbase hasta la fase de commit. 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. Estos intentos de escritura funcionan como bloqueos exclusivamente para el cluster primario.
XDCR replica los datos del clúster de origen al de destino de forma asíncrona, soportando la consistencia eventual para actualizaciones transaccionales. Por eso, una confirmación en el clúster de origen no garantiza que la transacción se haya replicado en XDCR. Una vez confirmada una transacción en el clúster de origen, las actualizaciones se replican en el clúster de destino de una en una. Esto significa que una transacción confirmada en el clúster de origen no garantiza la confirmación inmediata en el clúster de destino. En caso de conmutación por error, una transacción comprometida puede perderse si no se compromete en el destino antes de la conmutación por error, por lo que las aplicaciones deben esperar a que se completen todas las solicitudes pendientes o abortar las solicitudes antes de conmutar al clúster secundario.
Pasos de la replicación de transacciones
Los siguientes pasos describen la lógica de la transacción y la replicación de datos utilizando XDCR:
-
- Inicio del intento de transacción: Cada intento de transacción por parte de la aplicación (SDK) crea una entrada en el ATR, que funciona como un bloqueo virtual. Se hace en ambos nodos pero se muestra en uno en la imagen de abajo para simplificar.
- Cambios de etapa: Los cambios transaccionales se escalonan en las XATTR de los documentos de destino, sin afectar a los cuerpos de los documentos. Esto puede ocurrir en varios nodos y documentos. Estos cambios de etapa actúan como un bloqueo contra cualquier otra transacción en estos documentos.
- Compromiso: Una vez que la lógica de la transacción se ejecuta completamente, el intento de transacción se confirma, actualizando la entrada del intento en el ATR (se hace en ambos nodos pero se muestra en uno en la imagen de abajo para simplificar) y se actualiza la lista de ids de documentos involucrados en la transacción. Los actores transaccionales pueden leer la información actualizada de los XATTR si es necesario.
- Finalización de los cambios: Los cambios transaccionales se trasladan de los XATTR del documento a los cuerpos del documento (lo hace el SDK pero se muestra directamente en la imagen de abajo para simplificar).
- Finalización y limpieza: El intento de transacción se marca como "Completado" y se elimina de la ATR.
- Replicación: Los cambios en los documentos recién actualizados se replican uno a uno en el clúster de destino mediante XDCR.
Conclusión
XDCR es una potente herramienta para la replicación a través de diferentes centros de datos y geografías, soportando tanto la replicación unidireccional como la bidireccional con consistencia eventual para los cambios transaccionales. Por diseño, los cambios no comprometidos en una transacción y los metadatos para el registro de transacciones nunca se envían a los clústeres de destino, lo que garantiza la integridad y coherencia de los datos en todos los entornos replicados.
Comprender estos mecanismos puede ayudar a aclarar por qué determinados documentos pueden no aparecer inmediatamente en el clúster de destino, ya que dependen de los estados transaccionales y los procesos de replicación descritos anteriormente.
