Procesos de evacuación para las tablas globales

Evacuar una región es el proceso de migrar una actividad (normalmente actividad de escritura, posiblemente actividad de lectura) fuera de esa región.

Evacuación de una región activa

Puede decidir evacuar una región activa por varios motivos: como parte de la actividad empresarial habitual (por ejemplo, si utiliza el modo escribir en una región)follow-the-sun, debido a la decisión empresarial de cambiar la región actualmente activa, en respuesta a errores en el paquete de software ajeno a DynamoDB o porque se encuentre con problemas generales, como latencias más altas de lo habitual dentro de la región.

Con el modo de escritura en cualquier región, evacuar una región activa es sencillo. Puede dirigir el tráfico a regiones alternativas mediante cualquier sistema de enrutamiento y dejar que las operaciones de escritura que ya se han realizado en la región evacuada se repliquen como de costumbre.

Con los modos escribir en una región y escribir en su región, debe asegurarse de que todas las operaciones de escritura en la región activa se hayan grabado en su totalidad, se hayan procesado en streaming y se hayan propagado globalmente antes de iniciar las operaciones de escritura en la nueva región activa, a fin de garantizar que las future operaciones de escritura se procesen con la última versión de los datos.

Supongamos que la región A es activa y la región B es pasiva (para la tabla completa o para los elementos asignados a la región A). El mecanismo típico para llevar a cabo una evacuación consiste en pausar las operaciones de escritura en A, esperar el tiempo suficiente para que esas operaciones se hayan propagado completamente a B, actualizar la pila de la arquitectura para que reconozca B como activa y, a continuación, reanudar las operaciones de escritura en B. No existe ninguna métrica que indique con absoluta certeza que la región A ha replicado completamente sus datos a la región B. Si la región A está en buen estado, pausar las operaciones de escritura en la región A y esperar diez veces el valor máximo reciente de la métrica ReplicationLatency normalmente sería suficiente para determinar que la replicación se ha completado. Si el estado de la región A no es correcto y muestra otras zonas de latencias aumentadas, elegiría un múltiplo mayor para el tiempo de espera.

Evacuación de una región sin conexión

Hay que tener en cuenta un caso especial: ¿qué pasa si la Región A se desconecta por completo sin previo aviso? Esto es muy poco probable, pero debe tenerse en cuenta de todos modos. Si esto ocurre, cualquier operación 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, confiando en que los elementos de la Región A se propaguen eventualmente a la Región B y reconociendo la posibilidad de que falten objetos hasta que la Región A vuelva a estar en funcionamiento. Siempre que sea posible, como en el caso de las operaciones de escritura idempotentes, debería considerar la posibilidad de reproducir el tráfico de escritura reciente (por ejemplo, utilizando una fuente de eventos ascendente) para llenar el vacío de cualquier operación de escritura que pueda faltar y dejar que el último escritor gane la resolución de conflictos suprima la posible propagación de la operación de escritura entrante.

Con los otros modos de escritura, hay que tener en cuenta el grado en que el trabajo puede continuar con una out-of-date visión ligera del mundo. 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 una región. Puedes dividir el saldo en dos objetos diferentes, uno ubicado en la Región A y otro en la Región B, y empezar 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.

Como otro ejemplo, imagine que está capturando datos de formularios web. Puede utilizar el control de concurrencia optimista (OCC) para asignar versiones a los elementos de datos e incrustar la versión más reciente 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 de la base de datos es a 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).

Como tercer ejemplo, una empresa de servicios financieros guarda datos sobre las cuentas de los clientes y sus transacciones financieras en una base de datos de DynamoDB. En caso de que se produzca una interrupción total de la Región A, quieren asegurarse de que cualquier actividad de escritura relacionada con sus cuentas esté totalmente disponible en la Región B o quieren poner sus cuentas en cuarentena (se sabe que es parcial) hasta que la Región A vuelva a estar en funcionamiento. 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 propagara los datos parciales a la Región B. Si la Región C fallara, se podría crear una nueva Región D para utilizarla en su lugar. Los datos de la Región C eran muy transitorios y, después de unos minutos, la Región D disponía de un up-to-date registro suficiente de las operaciones de escritura durante el vuelo 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.