# Lista de comprobación de preparación para tablas globales de DynamoDB
<a name="bp-global-table-design.prescriptive-guidance.checklist-and-faq"></a>

Utilice la siguiente lista de comprobación para tomar decisiones y realizar tareas cuando despliegue tablas globales.
+ Determine si su caso de uso se beneficia más de un modo de coherencia MRSC o MREC. ¿Necesita una coherencia sólida, incluso con una latencia más alta y otras desventajas?
+ Determine cuántas y qué regiones deben participar en la tabla global. Si planea utilizar MRSC, decida si quiere que la tercera región sea una réplica o un testigo.
+ Determine el modo de escritura de la aplicación. No es lo mismo que el modo de coherencia. Para obtener más información, consulte [Modos de escritura con tablas globales de DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md).
+ Planifique su estrategia de [Estrategias de enrutamiento de DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) en función de su modo de escritura.
+ Defina [ Procesos de evacuación  Evacuación de una región con tablas globales   Evacuar una región es el proceso de migrar la actividad (en general la actividad de lectura y escritura) fuera de esa región.  Evacuación de una región activaRegiones activas  Evacuación de una región activa   Es posible que decida evacuar una región activa por varios motivos: como parte de la actividad empresarial habitual (por ejemplo, si utiliza un modo de seguimiento del sol, escritura en una región), debido a una decisión empresarial de cambiar la región activa en ese momento, en respuesta a errores en la pila de software fuera de DynamoDB, o porque se encuentra con problemas generales como latencias más altas de lo habitual en 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 con cualquier sistema de enrutamiento y permitir que las operaciones de escritura en la región evacuada se repliquen como de costumbre. Los modos escribir en una región y escribir en su región se utilizan, por lo general, con las tablas de MREC. Por lo tanto, asegúrese de que todas las operaciones de escritura en la región activa se hayan registrado por completo, procesado por flujo y propagado de manera global antes de iniciar las operaciones de escritura en la nueva región activa, para garantizar que las operaciones de escritura futuras 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ónRegiones sin conexión  Evacuación de una región sin conexión   Hay que considerar un caso especial: ¿qué pasaría si la región A se desconectara por completo sin previo aviso? Esto es muy poco probable, pero se debe tener en cuenta de todos modos.  

Evacuación de una tabla de MRSC desconectada  
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. 

Evacuación de una tabla de MREC desconectada  
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)](DynamoDBMapper.OptimisticLocking.md) 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.   ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [Procesos de evacuación](bp-global-table-design.prescriptive-guidance.evacuation.md), según el modo de coherencia, el modo de escritura y la estrategia de enrutamiento.
+ Capture métricas sobre el estado, la latencia y los errores de cada región. Para obtener una lista de las métricas de DynamoDB, consulte la entrada de blog de AWS [Supervisión de Amazon DynamoDB para el reconocimiento operativo](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/), donde encontrará una lista de las métricas que debe examinar. También debe utilizar [valores controlados sintéticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (solicitudes artificiales diseñadas para detectar errores; en inglés se llama “canary”, por el uso que se hacía de los canarios en las minas de carbón), así como la observación en directo del tráfico de los clientes. En las métricas de DynamoDB no aparecerán todas las incidencias.
+ Si utiliza MREC, establezca alarmas para los aumentos sostenidos de `ReplicationLatency`. Un aumento podría indicar un error de configuración accidental en el que la tabla global tiene diferentes opciones de escritura en distintas regiones, lo que da lugar a solicitudes replicadas con errores y a un aumento de las latencias. También podría indicar que existe una interrupción regional. Un [buen ejemplo](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) sería generar una alerta si el promedio reciente supera los 180 000 milisegundos. También puede vigilar si `ReplicationLatency` cae a 0, lo que indica que la replicación se ha estancado.
+ Asigne una configuración máxima de lectura y escritura suficiente para cada tabla global.
+ Identifique con antelación las razones para evacuar una región. Si la decisión implica una evaluación manual, documente todas las consideraciones. Este trabajo debe realizarse cuidadosamente con antelación, no bajo estrés.
+ Mantenga un manual de procedimientos para cada acción que deba llevarse a cabo cuando evacúe una región. Normalmente se requiere muy poco trabajo para las tablas globales, pero trasladar el resto de la pila puede resultar complejo. 
**nota**  
Con los procedimientos de conmutación por error, es una práctica recomendada confiar solo en las operaciones del plano de datos y no en las del plano de control, porque algunas operaciones del plano de control pueden deteriorarse durante los errores de la región.

   Para obtener más información, consulte la entrada del blog de AWS [Crear aplicaciones resilientes con tablas globales de Amazon DynamoDB: parte 4](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/).
+ Pruebe periódicamente todos los aspectos del manual de procedimientos, incluidas las evacuaciones de región. Un manual de procedimientos no probado es un manual poco fiable.
+ Considere la posibilidad de utilizar [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) para evaluar la resiliencia de toda la aplicación (incluidas las tablas globales). Proporciona una visión completa del estado de resiliencia general de su cartera de aplicaciones a través de su panel.
+ Considere la posibilidad de utilizar las comprobaciones de preparación de ARC para evaluar la configuración actual de la aplicación y realizar un seguimiento de cualquier desviación de las prácticas recomendadas.
+ Al escribir comprobaciones de estado para utilizarlas con Route 53 o Global Accelerator, haga una serie de llamadas que cubran todo el flujo de base de datos. Si limita la comprobación para confirmar únicamente que el punto de conexión de DynamoDB está activo, no se podrán cubrir muchos modos de error, como los errores de configuración de AWS Identity and Access Management (IAM), los problemas de implementación del código, los errores en la pila fuera de DynamoDB, las latencias de lectura o escritura superiores al promedio, etc.

## Preguntas frecuentes sobre el despliegue de tablas globales
<a name="bp-global-table-design.prescriptive-guidance.faq"></a>

**Cuál es el precio de las tablas globales?**
+ El precio de una operación de escritura en una tabla de DynamoDB tradicional se calcula en unidades de capacidad de escritura (WCU, para tablas aprovisionadas) o unidades de solicitud de escritura (WRU) para tablas bajo demanda. Si escribe un elemento de 5 KB, se genera un cargo de 5 unidades. Una operación de escritura en una tabla global se cobra en unidades de capacidad de escritura replicada (rWCU, para las tablas aprovisionadas) o en unidades de solicitud de escritura replicada (rWRU, para las tablas bajo demanda). Las rWCU y las rWRU tienen el mismo precio que las WGU y las WRU.
+ Los cargos por rWCU y rWRU se producen en cada región en la que se escribe el elemento de manera directa o mediante replicación. Se aplican tarifas de transferencia de datos entre regiones.
+ La escritura en un índice secundario global (GSI) se considera una operación de escritura local y utiliza unidades de escritura normales.
+ No hay capacidad reservada disponible para las rWCU ni rWRU de momento. Adquirir capacidad reservada para WCU puede ser beneficioso para las tablas con GSI que consumen unidades de escritura.
+ Al agregar una nueva región a una tabla global, DynamoDB inicia la nueva región automáticamente y le cobra como si se tratara de una restauración de tabla, en función del tamaño de GB de la tabla. También cobra tarifas de transferencia de datos entre regiones.

**Qué regiones admiten las tablas globales?**

[Las tablas globales versión 2019.11.21 (actual)](GlobalTables.md) admiten todas las Regiones de AWS para las tablas de MREC y los siguientes conjuntos de regiones para las tablas de MRSC:
+ Conjunto de regiones de EE. UU.: Este de EE. UU. (Norte de Virginia), Este de EE. UU. (Ohio), Oeste de EE. UU. (Oregón)
+ Conjunto de regiones de la Unión Europea: Europa (Irlanda), Europa (Londres), Europa (París), Europa (Fráncfort)
+ Conjunto de regiones de Asia-Pacífico: Asia-Pacífico (Tokio), Asia-Pacífico (Seúl) y Asia-Pacífico (Osaka).

**Cómo se gestionan los GSI con las tablas globales?**

En la [versión 2019.11.21 (actual) de las tablas globales](GlobalTables.md), cuando se crea un GSI en una región, se crea automáticamente en otras regiones participantes y se repone de forma automática. 

**Cómo detengo la replicación de una tabla global?** 
+ Puede eliminar una tabla de réplica del mismo modo que eliminaría cualquier otra tabla. Al eliminar la tabla global se detiene la replicación en esa región y se elimina la copia de la tabla guardada en dicha región. No obstante, no se puede detener la replicación mientras se mantienen copias de la tabla como entidades independientes, ni tampoco se puede pausar.
+ Una tabla de MRSC se debe implementar exactamente en tres regiones. Para eliminar las réplicas, debe eliminar todas las réplicas y el testigo para que la tabla de MRSC pase a ser una tabla local.

**Cómo interactúan los flujos de DynamoDB con las tablas globales?**
+ Cada tabla global produce un flujo independiente basado en todas sus operaciones de escritura, independientemente de dónde hayan comenzado. Puede elegir consumir el flujo de DynamoDB en una región o en todas las regiones (de forma independiente). Si desea procesar operaciones de escritura locales pero no replicadas, puede agregar su propio atributo de región a cada elemento para identificar la región de escritura. A continuación, puede utilizar un filtro de eventos Lambda para llamar la función de Lambda solo para las operaciones de escritura en la región local. Esta acción ayuda en las operaciones de inserción y actualización, pero no en las de eliminación.
+ Las tablas globales configuradas para una coherencia final de varias regiones (MREC) replican los cambios al leer esos cambios desde un flujo de DynamoDB en una tabla de réplica y aplicarlos a todas las demás tablas de réplica. Por lo tanto, DynamoDB está habilitado de forma predeterminada en todas las réplicas de una tabla global de MREC y no se puede desactivar en esas réplicas. El proceso de replicación de MREC puede combinar varios cambios en un periodo breve en una sola operación de escritura replicada. Como resultado, el flujo de cada réplica puede contener registros ligeramente distintos. Los registros de DynamoDB Streams en las réplicas de MREC siempre se ordenan por elemento, pero el orden entre los elementos podría variar entre las réplicas.
+ Las tablas globales configuradas para una coherencia alta de varias regiones (tablas de MRSC) no utilizan DynamoDB Streams para la replicación, por lo que esta característica no está habilitada de manera predeterminada en las réplicas de MRSC. Puede habilitar DynamoDB Streams en una réplica de MRSC. Los registros de DynamoDB Streams en las réplicas de MRSC son idénticos para todas las réplicas y siempre se ordenan por elemento, pero el orden entre los elementos podría variar entre las réplicas.

**Cómo gestionan las transacciones las tablas globales?** 
+ Las operaciones transaccionales en las tablas de la MRSC generarán errores.
+ Las operaciones transaccionales en las tablas de MREC proporcionan garantías de atomicidad, coherencia, aislamiento y durabilidad (ACID) solo en la región en la que se creó la operación de escritura originalmente. No se admiten las transacciones entre regiones en las tablas globales. Por ejemplo, si tiene una tabla global de MREC con réplicas en las regiones Este de EE. UU. (Ohio) y Oeste de EE. UU. (Oregón) y hace una operación `TransactWriteItems` en la región Este de EE. UU. (Ohio), puede observar transacciones completadas de manera parcial en la región Oeste de EE. UU. (Oregón) a medida que los cambios se replican. Los cambios se replican en otras regiones solo cuando se han confirmado en la región de origen.

** Cómo interactúan las tablas globales con la memoria caché de DynamoDB Accelerator (DAX)?**

Las tablas globales eluden DAX mediante la actualización directa de DynamoDB, por lo que DAX no tiene constancia de que está almacenando datos obsoletos. La memoria caché de DAX solo se actualiza cuando caduca el TTL de la memoria caché.

**Se propagan las etiquetas de las tablas?**

No, las etiquetas no se propagan automáticamente.

**Debo hacer copias de seguridad de las tablas de todas las regiones o solo de una?**

La respuesta depende de la finalidad de la copia de seguridad.
+ Si desea garantizar la durabilidad de los datos, DynamoDB ya proporciona esa protección. El servicio garantiza la durabilidad.
+ Si desea conservar una instantánea para los registros históricos (por ejemplo, para cumplir los requisitos normativos), la copia de seguridad en una región debería ser suficiente. Puede copiar la copia de seguridad a más regiones mediante AWS Backup.
+ Si desea recuperar datos eliminados o modificados erróneamente, utilice la [recuperación en un momento dado (PITR) de DynamoDB](PointInTimeRecovery_Howitworks.md) en una región.

**Cómo puedo desplegar tablas globales con CloudFormation?**
+ CloudFormation representa una tabla de DynamoDB y una tabla global como dos recursos independientes: `AWS::DynamoDB::Table` y `AWS::DynamoDB::GlobalTable`. Un enfoque consiste en crear todas las tablas que puedan ser potencialmente globales mediante el constructo `GlobalTable`, mantenerlas inicialmente como tablas independientes y agregar regiones después, si es necesario. 
+ En CloudFormation, cada tabla global está controlada por una sola pila, en una sola región, independientemente del número de réplicas. Cuando implemente la plantilla, CloudFormation crea y actualiza todas las réplicas como parte de una sola operación de pila. No debe desplegar el mismo recurso [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) en varias regiones. Se producirán errores y no se admite. Si despliega la plantilla de aplicación en varias regiones, puede usar condiciones para crear el recurso `AWS::DynamoDB::GlobalTable` en una sola región. O bien, puede optar por definir recursos `AWS::DynamoDB::GlobalTable` en una pila que sea independiente de la pila de aplicaciones y asegurarse de que despliega en una sola región. 
+ Si tiene una tabla normal y desea convertirla en una tabla global sin que CloudFormation deje de administrarla, establezca la política de eliminación en `Retain`, elimine la tabla de la pila, conviértala en una tabla global en la consola y, a continuación, importe la tabla global como un nuevo recurso a la pila. Para más información, consulte el [repositorio de GitHub de AWS](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk).
+ En este momento no se admite la replicación entre cuentas.