¿Por qué requerimos bases de datos de múltiples líderes?

1. Admite escrituras en varios centros de datos para aumentar el rendimiento en todos los centros de datos.
2. Tolerancia a los problemas de red en los centros de datos.
3. Operación independiente de todos los demás centros de datos, incluso si un centro de datos deja de funcionar

¿Cómo debemos manejar los conflictos de escritura entre los líderes? Colisión de claves de incremento automático? ¿Arreglar datos desordenados en múltiples líderes debido a algún error o problema? y más

La forma más sencilla de resolver un problema es no tener dolor en primer lugar.

¿Cómo no vamos a tener conflictos en multilíder?

Si nos aseguramos de que escribir a un líder en particular sea siempre a través del mismo líder, entonces no habrá conflictos. Esto está aumentando el rendimiento de escritura en los centros de datos, pero si un centro de datos falla, finalmente tenemos que lidiar con los conflictos :(

Maneras de lidiar con los conflictos.

Ahora hay dos formas de resolver los conflictos.

1. La aplicación resuelve conflictos: la aplicación detecta los conflictos y un fragmento de código los resuelve o la base de datos puede hacerlo. Una de las formas es la técnica del último en escribir gana (LWW).
   Déjame saber en los comentarios si quieres un blog para discutir las diversas técnicas. Yo estaría feliz de hacer eso :)
2. El usuario resuelve conflictos: almacene todas las versiones de conflicto y la próxima vez que el usuario lea los datos, solicite al usuario y escriba el resultado nuevamente en la base de datos.

Cada nodo escribe desde un nodo y reenvía esas escrituras a otro nodo

Un nodo raíz designado reenvía escrituras a todos los demás nodos.

En tales arquitecturas, existe la posibilidad de que conduzca a bucles de replicación infinitos. Están recorriendo infinitamente todos los nodos.

¿Cómo evitar bucles de replicación infinitos?

Cada nodo tiene un identificador único y el registro de replicación está etiquetado con los identificadores de todos los nodos por los que pasa.
Y cada vez que un nodo recibe una replicación que tiene su identificador, el cambio de datos se ignora porque sabe que ya se procesó y se evita el bucle infinito.

Pero hay un problema más aquí, un único punto de falla.

Si un nodo falla, también afectará a otros nodos.

¿Cómo prevenir un único punto de falla?

Entonces aquí la tolerancia a fallas es mejor porque los mensajes pueden viajar a lo largo de una ruta diferente, evitando un único punto de falla.

Pero definitivamente, viene con sus complejidades, como que un enlace de red puede ser más rápido que otros y algunos mensajes pueden superar a otros y, por lo tanto, generar inconsistencias de datos en un entorno concurrente. Podemos usar vectores de versión para estos.

El vector de versión es un blog completamente diferente, por lo tanto, no se discute aquí.

Esto podría haberle dado una buena cantidad de arquitectura de múltiples líderes, entonces, ¿cree que vale la pena todo esto? ¿O deberíamos evitar el multilíder?

Puedes seguirme y suscribirte para mantenerte actualizado conmigo :)

Diseño de aplicaciones con uso intensivo de datos: las grandes ideas detrás de sistemas confiables, escalables y mantenibles: por Martin Kleppmann