Replicación optimista

La replicación optimista , también conocida como replicación perezosa , ^{[ 1 ] [ 2 ]} es una estrategia de replicación en la que se permite que las réplicas diverjan. ^{[ 3 ]}

Los sistemas de replicación pesimistas tradicionales intentan garantizar desde el principio que todas las réplicas sean idénticas entre sí, como si siempre hubiera existido una única copia de los datos. La replicación optimista prescinde de esto y opta por la consistencia eventual , lo que significa que las réplicas solo convergen cuando el sistema ha estado inactivo durante un período de tiempo. Como resultado, ya no es necesario esperar a que todas las copias se sincronicen al actualizar los datos, lo que favorece la concurrencia y el paralelismo . La desventaja es que las diferentes réplicas pueden requerir una reconciliación explícita posteriormente, lo que podría resultar difícil o incluso insoluble.

Un algoritmo de replicación optimista consta de cinco elementos:

1. Envío de operaciones : Los usuarios envían operaciones en sitios independientes.
2. Propagación : Cada sitio comparte las operaciones que conoce con el resto del sistema.
3. Planificación : Cada centro decide el orden de las operaciones que conoce.
4. Resolución de conflictos : Si existen conflictos entre las operaciones programadas en un sitio, este debe modificarlas de alguna manera.
5. Compromiso : Las partes involucradas acuerdan un cronograma final y un resultado para la resolución de conflictos, y las operaciones se hacen permanentes.

Existen dos estrategias de propagación: la transferencia de estado, en la que los sitios propagan una representación del estado actual, y la transferencia de operaciones, en la que los sitios propagan las operaciones que se realizaron (esencialmente, una lista de instrucciones sobre cómo alcanzar el nuevo estado).

La planificación y la resolución de conflictos pueden ser sintácticas o semánticas. Los sistemas sintácticos se basan en información general, como cuándo o dónde se envió una operación. Los sistemas semánticos pueden utilizar información específica de la aplicación para tomar decisiones más acertadas. Cabe destacar que los sistemas de transferencia de estado generalmente carecen de información sobre la semántica de los datos que se transfieren, por lo que deben utilizar la planificación y la resolución de conflictos sintácticas.

Un ejemplo bien conocido de un sistema basado en la replicación optimista es el sistema de control de versiones CVS , o cualquier otro sistema de control de versiones que utilice el paradigma de copiar-modificar-fusionar . CVS abarca cada uno de los cinco elementos:

1. Envío de operaciones: Los usuarios editan versiones locales de los archivos.
2. Propagación: Los usuarios descargan manualmente las actualizaciones de un servidor central o envían los cambios cuando consideran que están listos.
3. Planificación: Las operaciones se planifican en el orden en que las recibe el servidor central.
4. Resolución de conflictos: Cuando un usuario envía o descarga archivos del repositorio central, cualquier conflicto se marcará para que ese usuario lo solucione manualmente.
5. Compromiso: Una vez que el servidor central acepta los cambios que un usuario envía, estos quedan confirmados de forma permanente.

Un caso especial de replicación es la sincronización , donde solo existen dos réplicas. Por ejemplo, las agendas electrónicas (PDA) permiten a los usuarios editar datos tanto en la PDA como en un ordenador y, posteriormente, combinar ambos conjuntos de datos. Cabe destacar, sin embargo, que la replicación es un problema más amplio que la sincronización, ya que puede haber más de dos réplicas.

Otros ejemplos incluyen:

• Usenet y otros sistemas que utilizan la regla de escritura de Thomas (véase RFC 677 ).
• Replicación de bases de datos multi-maestro ^{[ 4 ]}
• El sistema de archivos distribuido Coda
• Transformación operacional , un marco teórico para la edición de grupos
• Wikis entre pares
• Tipos de datos replicados sin conflictos
• La base de datos distribuida de Bayou ^{[ 5 ]}
• IceCube ^{[ 6 ]}

Las aplicaciones desarrolladas sobre bases de datos replicadas optimistas deben tener cuidado de garantizar que las actualizaciones retardadas observadas no perjudiquen la corrección de la aplicación.

Como ejemplo sencillo, si una aplicación permite visualizar y editar parte del estado de la base de datos, los usuarios podrían editar dicho estado sin ver los cambios reflejados en la visualización. Alarmados porque su edición "no funcionó", podrían intentarlo de nuevo, incluso varias veces. Si las actualizaciones no son idempotentes (por ejemplo, incrementan un valor), esto puede provocar un desastre. Incluso si son idempotentes, las actualizaciones erróneas de la base de datos pueden generar cuellos de botella en el rendimiento, especialmente cuando los sistemas de bases de datos procesan cargas pesadas; esto puede convertirse en un círculo vicioso.

Las pruebas de aplicaciones suelen realizarse en un entorno de prueba, de menor tamaño (quizás un solo servidor) y con menor carga que el entorno de producción. El comportamiento de replicación de dicha instalación puede diferir del de un entorno de producción, lo que implica que es improbable que se observe un retraso en la replicación durante las pruebas, enmascarando así errores sensibles a la replicación. Los desarrolladores de aplicaciones deben ser muy cuidadosos con las suposiciones que hacen sobre el efecto de una actualización de la base de datos y deben asegurarse de simular el retraso en sus entornos de prueba.

Las bases de datos replicadas de forma optimista deben ser muy cuidadosas al ofrecer características como restricciones de validez de datos. Si una actualización determinada puede o no aceptarse según el estado actual del registro, entonces dos actualizaciones (A y B) pueden ser válidas individualmente con respecto al estado inicial del sistema, pero una o más de ellas pueden no ser válidas con respecto al estado del sistema después de la otra actualización (por ejemplo, A y B son válidas, pero AB o BA son inválidas). Si A y B se inician casi simultáneamente en la base de datos, A puede aplicarse correctamente en algunos nodos y B en otros, pero tan pronto como A y B "encuentren" y se intente aplicar una en un nodo que ya haya aplicado la otra, se producirá un conflicto. En este caso, el sistema debe decidir qué actualización "prevalece" finalmente y revertirla en los nodos que ya hayan aplicado la actualización perdedora. Sin embargo, algunos nodos pueden exponer temporalmente el estado con la actualización revertida, y puede que no haya forma de informar al usuario que inició la actualización de su fallo, sin obligarlo a esperar (potencialmente para siempre) la confirmación de aceptación en cada nodo.

• Saito, Yasushi; Shapiro, Marc (septiembre de 2003). "Replicación optimista" (PDF) . Microsoft.