Couchbase DCP Rollback y cómo QA los prueba

Introducción

En este post voy a describir cómo el equipo de control de calidad de Couchbase hace todo lo posible para probar los productos de Couchbase, utilizando DCP Rollbacks como ejemplo, y primero dando antecedentes sobre lo que es DCP y lo que es un rollback DCP.

¿Qué es DCP?

DCP significa Database Change Protocol (Protocolo de Cambio de Base de Datos) entre nodos Couchbase como réplicas o vistas, o a clientes externos como XDCR o FTS. Sigue un modelo productor/consumidor y proporciona un alto rendimiento y baja latencia. Los datos se transmiten por vbucket. Se describe como aquí.

De particular interés en el número de secuencia. El número de secuencia es un número monotónicamente creciente asociado a las mutaciones en un vbucket y se utiliza para mantener sincronizados al productor y al consumidor.

¿Qué es un rollback?

No, no estos retrocesos

Un rollback de Couchbase se produce cuando un cliente se conecta a un productor con un número de secuencia mayor que el que tiene el productor, o dicho de otra forma el cliente tiene mutaciones más recientes pero como estas no son la "verdad" debe hacer un rollback o deshacer algunas mutaciones para alinearlas con la nueva verdad.

Esto no es habitual, pero ocurre y, a efectos de integridad de los datos, es importante que se gestione correctamente.

En un entorno real esto podría ocurrir en los siguientes escenarios:

Failover con mutaciones en vuelo (puede ocurrir con un hard failover)

1. El cliente está conectado al nodo activo A
2. Las mutaciones con número de secuencia 100 llegan al cliente y están en vuelo hacia el nodo de réplica B
3. Antes de que la mutación con el número de secuencia 100 llegue al nodo B se produce una conmutación por error, el nodo B sólo tiene el número de secuencia 90
4. El cliente, al reconocer la conmutación por error, se conecta al nuevo nodo activo B con el número de secuencia 100.
5. El nodo B, que sólo tiene el número de secuencia 90, responde al cliente pidiéndole que vuelva a la secuencia 90.
6. El cliente deshace los efectos de las mutaciones para los números de secuencia 91-100, y solicita una conexión con el productor con el número de secuencia 90.

Choque con datos no persistentes

1. El cliente está conectado al nodo activo A
2. Se han mantenido mutaciones hasta el número de secuencia 90
3. Las mutaciones hasta el número de secuencia 100 llegan al cliente y aún no se han registrado
4. Memcached se bloquea y se reinicia, sin conmutación por error
5. El cliente se vuelve a conectar al nodo A con el número de secuencia 100
6. Similar a los pasos 5 y 6 anteriores

Pruebas para y con DCP Rollbacks (y cómo se rompen)

La organización de control de calidad de Couchbase prueba las reversiones de tres maneras:

Productor

 El productor solicita rollbacks en los casos en que el cliente solicita un número de secuencia mayor que el conocido por el productor. Verificamos que el productor realmente solicita al cliente la reversión y devuelve datos coherentes a partir de ese momento.

  Hemos desarrollado un cliente DCP personalizado. Realiza mutaciones y crea en paralelo conexiones DCP y ejercita escenarios específicos. Puede manipular el número de secuencia solicitada, y desencadenar otra interacción característica como la compactación, y supervisar el estado de persistencia

Consumidores

Al recibir una solicitud de reversión, verifique que el cliente deshace correctamente las mutaciones posteriores y aplica correctamente las nuevas mutaciones.

El siguiente escenario causará de forma determinista que un cliente reciba una petición de rollback:

1. Detener la persistencia
2. Kill memcached y memcached se reinicia
3. Las conexiones DCP se revertirán al número de secuencia anterior a la interrupción de la persistencia.

Los redactores de pruebas utilizan el escenario anterior para activar la reversión y verificar que el cliente deshace correctamente las mutaciones revertidas.

Los problemas típicos encontrados en el lado del consumidor tienen que ver con que el consumidor retenga información asociada con las mutaciones revertidas.

Prueba del sistema

Realice hard failovers a altas tasas de mutación (lo que provoca que los vbuckets activos se adelanten a la réplica) durante views y 2i. Como resultado, habrá pérdida de datos mientras se promocionan los vbuckets de réplica a activos y se retroceden los números de secuencia, pero el clúster debería seguir siendo estable. Los errores típicos encontrados incluyen que la réplica recién promovida tenga datos inconsistentes, y que los clientes no manejen el rollback correctamente.