Procesos de evacuación

Si esto sucede con una tabla de MRSC, no es necesario que haga nada especial. Las tablas de MRSC admiten un objetivo de punto de recuperación (RPO) de cero. Todas las operaciones de escritura correctas que se hagan en la tabla de MRSC en la región sin conexión estarán disponibles en todas las demás tablas de la región, por lo que no habrá ningún riesgo potencial de los datos incluso si la región se desconecta por completo sin previo aviso. Las empresas pueden seguir utilizando las réplicas ubicadas en las demás regiones.

Si esto sucede con una tabla de MREC, las operaciones de escritura en la región A que aún no se haya propagado se retiene y se propaga después de que la región A vuelva a estar en línea. Las operaciones de escritura no se pierden, pero su propagación se retrasa indefinidamente.

La aplicación decide cómo continuar en este caso. Por motivos de continuidad empresarial, es posible que las operaciones de escritura deban continuar hacia la nueva región primaria B. No obstante, si un elemento de la región B recibe una actualización mientras hay una propagación pendiente de una operación de escritura para ese elemento desde la región A, la propagación se suprime según el modelo de último escritor gana. Cualquier actualización en la región B podría suprimir una solicitud de escritura entrante.

Con el modo de escritura en cualquier región, las operaciones de lectura y escritura pueden continuar en la región B, con la confianza de que los elementos de la región A se propagarán finalmente en la región B y la aceptación de la posibilidad de que falten elementos hasta que la región A vuelva a estar en línea. Cuando sea posible, como con las operaciones de escritura de idempotencia, debe considerar la posibilidad de reproducir el tráfico de escritura reciente (por ejemplo, con un origen de eventos ascendente) para completar las operaciones de escritura que puedan faltar y dejar que el último escritor que gane la resolución del conflicto suprima la propagación final de la operación de escritura entrante.

Con los otros modos de escritura, hay que considerar hasta qué punto se puede seguir trabajando con una visión del mundo ligeramente desactualizada. Faltará una pequeña duración de las operaciones de escritura, según el seguimiento de ReplicationLatency, hasta que la región A vuelva a estar en línea. ¿Puede avanzar la actividad? En algunos casos de uso puede que sí, pero en otros puede que no si no hay mecanismos de mitigación adicionales.

Por ejemplo, imagine que tiene que mantener un saldo de crédito disponible sin interrupción incluso después de una interrupción total de la región. Podría dividir el saldo en dos elementos distintos, uno ubicado en la región A y otro en la región B, e iniciar cada uno con la mitad del saldo disponible. De este modo, se utilizaría el modo de escritura en su región. Las actualizaciones transaccionales procesadas en cada región se escribirían según la copia local del saldo. Si la región A se queda totalmente fuera de línea, se podría seguir trabajando con el procesamiento de transacciones en la región B y las operaciones de escritura se limitarían a la parte del saldo que se mantiene en la región B. Dividir el saldo de esta manera conlleva complejidades cuando el saldo baja o hay que reequilibrar el crédito, pero proporciona un ejemplo de recuperación segura de la actividad incluso con operaciones de escritura pendientes inciertas.

Un ejemplo más: imagine que captura datos de un formulario web. Puede utilizar el control de simultaneidad optimista (OCC) para asignar versiones a los elementos de datos e insertar la última versión en el formulario web como un campo oculto. En cada envío, la operación de escritura solo se realiza correctamente si la versión de la base de datos sigue coincidiendo con la versión con la que se creó el formulario. Si las versiones no coinciden, el formulario web puede actualizarse (o combinarse cuidadosamente) en función de la versión actual de la base de datos y el usuario puede continuar de nuevo. El modelo OCC suele proteger contra el hecho de que otro cliente sobrescriba los datos y produzca una nueva versión de ellos, pero también puede ser de ayuda durante la conmutación por error, cuando un cliente puede encontrarse con versiones más antiguas de los datos. Imaginemos que utiliza la marca de tiempo como versión. El formulario se creó por primera vez en la región A a las 12:00, pero (tras la conmutación por error) intenta escribir en la región B y se da cuenta de que la última versión en la base de datos es la de las 11:59. En este escenario, el cliente puede esperar a que la versión de las 12:00 se propague a la región B y escribir en esa versión, o basarse en la de las 11:59 y crear una nueva versión de las 12:01 (que, después de la escritura, suprimiría la versión entrante una vez que se recupere la región A).

Un tercer ejemplo: una empresa de servicios financieros almacena los datos sobre las cuentas de sus clientes y sus transacciones financieras en una base de datos de DynamoDB. En caso de que se produzca una interrupción completa en la región A, quiere asegurarse de que las actividades de escritura relacionadas con sus cuentas estén totalmente disponibles en la región B o bien quiere poner en cuarentena sus cuentas como parciales conocidas hasta que la región A vuelva a estar en línea. En lugar de pausar toda la actividad, decide pausarla solo para la minúscula fracción de cuentas que ha determinado que tienen transacciones no propagadas. Para lograrlo, utilizan una tercera región, a la que llamaremos región C. Antes de procesar cualquier operación de escritura en la región A, incluyen un resumen sucinto de esas operaciones pendientes (por ejemplo, un nuevo recuento de transacciones para una cuenta) en la región C. Este resumen es suficiente para que la región B determine si su vista está totalmente actualizada. Esta acción bloquea de un modo efectivo la cuenta desde el momento de la escritura en la región C hasta que la región A acepta las operaciones de escritura y la región B las recibe. Los datos de la región C no se utilizan excepto como parte de un proceso de conmutación por error, tras el cual la región B puede cruzar sus datos con los de la región C para comprobar si alguna de sus cuentas está desactualizada. Esas cuentas se marcarían como en cuarentena hasta que la recuperación de la región A propague los datos parciales a la región B. Si se produce un error en la región C, se puede crear una nueva región D para utilizarla en su lugar. Los datos de la región C son muy temporales y, al cabo de unos minutos, la región D dispondrá de un registro lo suficientemente actualizado de las operaciones de escritura en tránsito como para ser totalmente útil. Si se produce un error en la región B, la región A puede seguir aceptando solicitudes de escritura en cooperación con la región C. Esta empresa estaba dispuesta a aceptar escrituras de latencia más alta (a dos regiones: C y luego A) y tuvo la suerte de contar con un modelo de datos en el que se podía resumir sucintamente el estado de una cuenta.