Puedes leer el artículo anterior de la serie aquí: mecanismos de replicación

Hemos estado hablando sobre el log de replicación y flujo de cambios en los últimos dos artículos de esta serie. Este es el mecanismo que el líder usa para comunicar cambios a los seguidores. Como puedes imaginar, hay diferentes implementaciones con sus ventajas y desventajas, y es importante entender la forma en que los cambios fluyen del líder a los seguidores en tu sistema.

Echaremos un vistazo a 3 implementaciones de log de replicación:

• Replicación basada en declaraciones
• Envío WAL
• Replicación basada en lógica

Entonces, empecemos con la primera.

Replicación basada en declaraciones

Esta es la implementación más simple.

El líder mantiene un log con cada solicitud que tiene el potencial de mutar datos. Escrituras, actualizaciones, eliminaciones, y otras operaciones similares se convierten en entradas en el log. El líder periódicamente envía este log a cada seguidor. Cuando un seguidor recibe el log, ejecuta cada declaración en orden.

La ventaja de este método es que es extremadamente simple. La desventaja es que para funcionar, dos restricciones importantes deben ser colocadas en tu sistema:

1. El comportamiento no-determinístico está prohibido: Operaciones/declaraciones no-determinísticas como la generación de un número aleatorio, escribir la hora actual o disparar acciones secundarias están todas prohibidas. El problema con este tipo de operación es que terminarán generando valores diferentes en cada réplica, así rompiendo la consistencia de datos de tu sistema. Si tu sistema necesita realizar este tipo de operación, no podrá realizar replicación basada en declaraciones.

2. La concurrencia no puede ser soportada: Las declaraciones que usan datos ya en la BD deben ser ejecutadas en orden. Las operaciones del tipo UPDATE X WHERE Y pueden tener resultados diferentes si cambias el orden en el que las declaraciones en el log son ejecutadas. Esto te prohíbe ejecutar declaraciones concurrentemente. Esto podría ser un problema si quieres ejecutar transacciones concurrentes para mejorar el rendimiento.

Estas dos restricciones parecen triviales, pero hay muchos casos límite de producción que caen en una de estas dos categorías. Porque tienden a ser comunes, este enfoque raramente se usa para replicación. Sin embargo, si tu implementación de BD requiere que todas tus declaraciones sean completamente determinísticas entonces la replicación basada en declaraciones puede ser usada de manera segura en producción.

Hay sistemas comerciales que imponen determinismo y usan este enfoque. Un ejemplo es VoltDB y sus procedimientos determinísticos impuestos.

Envío WAL (WAL shipping)

Un write-ahead log (también conocido como WAL o redo log) es una estructura de datos adicional en disco que algunas bases de datos incluyen. Este es un archivo de append-only que incluye cada modificación en los archivos de la BD. Cada cambio en los datos se escribe en el log antes de ser aplicado. Las bases de datos cuyo motor de almacenamiento usa B-Trees para representar datos en el disco incluyen un write-ahead log. Otros mecanismos de motor de almacenamiento, como almacenamiento estructurado por log, escriben todos los cambios a un log (que se compacta en segundo plano periódicamente) como su manera de representar datos. Lo importante de saber es que las BDs usualmente tienen un log de append-only que puede ser usado para restaurar datos.

La replicación WAL funciona enviando este archivo a cada seguidor después de que el líder escribe los cambios a su propio disco. Los seguidores entonces usan el log para restaurar sus propias copias de los datos.

Este enfoque tiene (lo adivinaste) una desventaja importante: el log describe los datos a un nivel muy bajo (detalles a nivel de bytes) y está fuertemente acoplado al motor de almacenamiento. Las bases de datos pueden cambiar sus formatos de almacenamiento de una versión a la siguiente, por lo que este enfoque podría no funcionar si tu sistema está ejecutando diferentes versiones de BD.

Replicación basada en lógica

La replicación basada en lógica es un enfoque que soporta diferentes formatos de log para replicación y motor de almacenamiento. Para una BD relacional, los logs lógicos son una secuencia de registros que describen las operaciones realizadas a nivel de fila. Cada entrada en el log describe las operaciones a un nivel más alto de abstracción, algunos ejemplos son:

• Los inserts se representan como una fila que contiene los nuevos valores de todas las columnas del registro.
• Los deletes contienen toda la información necesaria para identificar únicamente la fila eliminada.
• Los updates contienen toda la información necesaria para identificar únicamente la fila actualizada y todas las columnas con los valores actualizados.
• Las transacciones que modifican múltiples filas resultarán en una entrada en el log para cada fila modificada. Una entrada indicadora especial establece que la transacción fue confirmada.

La principal ventaja de este enfoque es el desacoplamiento del motor de almacenamiento. Esto te permite mantener compatibilidad hacia atrás y desplegar múltiples máquinas con diferentes motores de almacenamiento. Si necesitas realizar actualizaciones de software puedes primero actualizar los seguidores, realizar failover y actualizar el líder y finalmente re-unir el líder viejo como un seguidor. Esto te permite realizar actualizaciones de software sin tiempo de inactividad.

Una ventaja extra es que estos logs son más fáciles de entender y analizar. Hay muchas herramientas que te permiten realizar análisis en datos recolectados de logs lógicos.

Ya no es tan mágico

Ahora entiendes cómo los datos fluyen de líderes a seguidores.

Este es uno de esos conceptos que al principio parecen como magia. ¿Qué exactamente está enviando el líder a cada seguidor para notificarles sobre los cambios en los datos? ¿es una serie de declaraciones SQL o es algo más?

Entender cómo funciona la replicación se trata de aprender sobre estos pequeños detalles. Lo que al principio parece un completo misterio usualmente es solo una colección de mecanismos y protocolos muy inteligentes que trabajan juntos para mantener sistemas complejos.

Ahora que entendemos el flujo de datos entre líderes y seguidores es hora de aprender sobre los peligros del retraso de replicación.

Qué hacer después:

• Comparte este artículo con amigos y colegas. Gracias por ayudarme a llegar a personas que podrían encontrar útil esta información.
• Esta serie está basada en Designing Data-Intensive Applications, asegúrate de echar un vistazo a los capítulos 5 y 6 para una explicación más profunda de replicación y sharding.
• Envíame un email con preguntas, comentarios o sugerencias (está en la página Autor)