Database Change Protocol (DCP) es el protocolo de replicación central de la versión 3.0 y se utiliza para conectar nodos y clusters a través de centros de datos geo-distribuidos. En este post, vamos a profundizar en su funcionamiento y cómo permite una mayor disponibilidad, rendimiento y escala con Couchbase Server 3.0.  

Empecemos con el por qué la replicación es una parte tan crítica de cualquier base de datos: He aquí el "por qué": 

  • Protección de datos: La replicación se utiliza para proteger contra fallos, manteniendo las réplicas locales y entre centros de datos. La rapidez con la que una base de datos puede replicar los datos a las réplicas decide la ventana de pérdida de datos. Cuanto menos eficiente sea una base de datos en la replicación, mayor será la ventana de pérdida de datos.
  • Proporcionar índices más frescos: La replicación es también el medio de actualizar las vistas en Couchbase. El índice incremental map/reduce que se utiliza para responder a las consultas necesita una alimentación rápida para mantenerse fresco y actualizado. Especialmente las consultas que necesitan una vista consistente de los datos no pueden ser respondidas si la replicación no es rápida y eficiente.

¿Qué hace que DCP sea especial y diferente de los protocolos de replicación de la competencia? Hay 4 propiedades clave: 

  • Pedidos: DCP ordena las mutaciones. Esto es importante para poder registrar dónde se dejaron las cosas. 
  • Reiniciable: DCP optimiza los reinicios tras fallos de corta o larga duración. 
  • Coherente: DCP es capaz de producir eficazmente una instantánea coherente.
  • Alto rendimiento: DCP se basa en la memoria. Transmite los cambios con avidez mientras los clientes puedan seguir el ritmo.

Arquitectura

Hay 3 piezas que componen la mayor parte de la magia de DCP: vbucket UUID, números de secuencia y registro de conmutación por error. Asumiré que ya conoces algunos aspectos como vbuckets. (puedes encontrar más información aquí sobre vbuckets). Veamos en qué consisten:

Un UUID de vbucket y un número de secuencia de mutación identifican de forma única cada mutación en Couchbase Server. Vamos a explicar estos conceptos; vbuckets representan fragmentos dentro de Couchbase Server. Cada vbucket tiene un UUID único asignado. A cada mutación se le asigna un número de secuencia. El número de secuencia es un número monotónicamente creciente y se asigna a cada vbucket. La magia de la consistencia y la reanudación granular se logra a través del registro de conmutación por error. Cada vbucket también mantiene un registro de conmutación por error. El registro de conmutación por error registra múltiples pares de UUID de vbucket y número de secuencia. La primera entrada marca el inicio del tiempo y cada nueva entrada marca una conmutación por error. Los vbuckets maestro y réplica del sistema mantienen el mismo registro de conmutación por error. Cuando ocurre un fallo - digamos que el vbucket maestro falla por ejemplo - un vbucket réplica se actualiza a un vbucket maestro. La nueva entrada del registro de fallos del vbucket maestro registra el UUID del vbucket y el último número de secuencia del nuevo vbucket maestro y lo replica a los vbuckets réplica para marcar la ocasión. Estos mecanismos básicos permiten un montón de magia. En la siguiente sección, vamos a echar un vistazo a algunas de las principales operaciones mejoradas en 3.0 con DCP y explicar cómo estos mecanismos hacen que suceda.

Copias de seguridad incrementales

3.0 puede conseguirte una eficiencia 100 veces mayor en el almacenamiento de copias de seguridad. He aquí cómo: Con 3.0, las copias de seguridad completas pueden complementarse con copias de seguridad incrementales para conseguir una mayor eficiencia en el almacenamiento. Las copias de seguridad incrementales simplemente respaldan sólo los datos que han cambiado desde la última copia de seguridad completa, acumulativa o incremental. Se puede tomar una instantánea completa y crear una cadena de copias de seguridad incrementales o acumulativas, en lugar de tomar instantáneas completas cada vez. El UUID de Vbucket, el número de secuencia y el registro de conmutación por error proporcionan los metadatos necesarios para poder mantener la coherencia entre la cadena de copias de seguridad.

Vistas y procesamiento incremental Map/Reduce

Las consultas de vista de baja latencia son clave para una aplicación ágil y vemos una mejora de 50 veces en las latencias de las consultas de vista con 3.0. Map/Reduce existe desde hace tiempo en el mundo Hadoop, pero Couchbase proporciona procesamiento incremental de map/reduce para permitir el pre-cálculo de tus consultas en una vista. Así es como Couchbase Server consigue consultas de baja latencia. El motor de procesamiento incremental es alimentado por un flujo DCP. A medida que las mutaciones llegan a la memoria, se transmiten para su procesamiento a los documentos de diseño y a las vistas que contienen. El flujo mejora la frescura de los índices en más de 50 veces en comparación con las versiones anteriores. Muchas consultas requieren consistencia. El desarrollador de Couchbase tiene opciones sobre la consistencia de la vista - Uno puede consultar lo que el índice ha procesado en cualquier punto (stale=ok) O puede pedir consultar la vista que contiene toda la mutación hasta el punto de la consulta (stale=false). DCP brilla especialmente para este último tipo de consultas, ya que tiene la capacidad de transmitir cambios a una velocidad vertiginosa al procesador de vistas. 

Recuperación Delta para un reequilibrio más rápido

Si está reintegrando al clúster un nodo que falló debido a un problema, ya no necesita retroceder horas o días y reenviar los cambios al nodo. Con el UUID de vbucket, el número de secuencia y el registro de conmutación por error, DCP tiene la capacidad de reiniciar con gran granularidad desde donde lo dejó. Si el nodo entrante ha estado ausente del clúster durante unos minutos, puede recuperarse simplemente recibiendo las mutaciones que faltan de los últimos minutos con la opción de recuperación de nodo delta. Hemos visto mejoras de 100s en los tiempos de reequilibrio con la recuperación del nodo delta, especialmente cuando el tamaño de los datos es masivo por nodo.

Garantía de durabilidad con "ReplicateTo 

Couchbase Server tiene consistencia incorporada - puedes "leer tu propia escritura" sin problemas incluso cuando escribes mutaciones en memoria. Sin embargo, muchos desarrolladores necesitan garantías de durabilidad para sus aplicaciones para que puedan sobrevivir a fallos de nodo sin perder datos. Algunos dependen de la clásica persistencia en disco pero para una mejor disponibilidad y recuperabilidad, muchos desarrolladores en Couchbase eligen la replicación como garantía de durabilidad de los datos. Eso se hace a través del método ReplicateTo en los SDKs nativos de Couchbase. ReplicateTo asegura el reconocimiento de tu mutación para volver DESPUÉS de que haya sido replicada a 1 o más réplicas. Con la replicación de streaming de alto rendimiento de DCP, puede replicar la mutación a una réplica hasta 180 veces más rápido. He visto latencias dentro de 1-2 ms con "ReplicateTo" en mis pruebas en la nube. Sin embargo, estos números absolutos dependen de la calidad de la infraestructura y HW que estoy ejecutando en lo que tomar con un grano de sal. 

Replicación entre centros de datos

XDCR -replicación entre centros de datos- también depende de DCP. La replicación en streaming directamente desde la memoria a otro centro de datos significa que podemos proteger mejor sus datos. Imagine una replicación bidireccional entre 2 clusters. Si falla el clúster #1, la cantidad de mutaciones perdidas vendrá determinada por la mayor latencia de replicación. Una replicación rápida significa que en una catástrofe regional como ésta, ¡la exposición a la pérdida de datos se reduce al mínimo! Hemos visto 4 veces más latencia de replicación con XDCR en Couchbase Server 3.0. 

XDCR también es propenso a sufrir errores de red y contratiempos, por lo que es importante poder recuperarse rápidamente de estos problemas y volver a la normalidad. Los metadatos DCP nos permiten retomarlos rápidamente desde donde se quedaron en caso de fallos de comunicación. 

Estos son sólo algunos ejemplos de cómo DCP amplía las capacidades de Couchbase Server. Hay mucho más... De hecho, hay 200 características más en Couchbase Server 3.0 y la mayoría están ahí gracias a la sólida base que proporciona DCP. 

Si desea profundizar en la gestión de fallos y la mecánica detrás de DCP rápido presumiblemente, puede ver la charla detallada que cubre DCP en Couchbase Connecto consulte los detalles de la aplicación aquí en sitio github.

Feliz prueba.

Autor

Publicado por Cihan Biyikoglu, Director de Gestión de Productos, Couchbase

Cihan Biyikoglu es director de gestión de productos en Couchbase, responsable del producto Couchbase Server. Cihan es un entusiasta de los grandes datos que aporta más de veinte años de experiencia al equipo de productos de Redis Labs. Cihan comenzó su carrera como desarrollador de C/C++.

2 Comentarios

  1. Chian,

    buen artículo. Una pregunta rápida: ¿dónde se almacena el registro de conmutación por error?

    Gracias,
    Dani

    1. Cihan Biyikoglu enero 27, 2015 a 12:47 am

      Hi failover log se almacena por vbucket en el vbucket.

Dejar una respuesta