# Lista de verificação de preparação para tabelas globais do DynamoDB
<a name="bp-global-table-design.prescriptive-guidance.checklist-and-faq"></a>

Use a lista de verificação a seguir para decisões e tarefas ao implantar tabelas globais.
+ Determine se seu caso de uso se beneficia mais de um modo de consistência MRSC ou MREC. Você precisa de alta consistência, mesmo com a latência mais alta e outras concessões?
+ Determine quantas e quais regiões devem participar da tabela global. Se você planeja usar MRSC, decida se deseja que a terceira região seja uma réplica ou uma testemunha.
+ Determine o modo de gravação da sua aplicação. Isso não é o mesmo que o modo de consistência. Para obter mais informações, consulte [Modos de gravação com tabelas globais do DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md).
+ Planeje sua estratégia de [Estratégias de roteamento do DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) com base no seu modo de gravação.
+ Defina seu [ Processos de evacuação  Evacuar uma região com tabelas globais   A evacuação de uma região é o processo de migrar a atividade, normalmente a gravação, e possivelmente a atividade de leitura, para fora dessa região.  Evacuar uma região ativaRegiões ativas  Evacuar uma região ativa   É possível que você decida evacuar uma região ativa por vários motivos: como parte da atividade comercial normal (por exemplo, se estiver usando um modo de gravação em uma região com o modelo follow-the-sun) por causa de uma decisão comercial de mudar a região atualmente ativa, em resposta a falhas na pilha de software fora do DynamoDB ou porque está enfrentando problemas gerais, como latências mais altas do que o normal na região. Com o modo de *gravação em qualquer região*, é fácil evacuar uma região ativa. Você pode direcionar o tráfego para regiões alternativas por meio de qualquer sistema de roteamento e permitir que as operações de gravação na região evacuada sejam replicadas como de costume. Os modos gravar para uma região e gravar para sua região geralmente são usados com tabelas MREC. Portanto, é necessário garantir que todas as operações de gravação na região ativa tenham sido totalmente gravadas, processadas no fluxo e propagadas globalmente antes de iniciar as operações de gravação na nova região ativa, para garantir que as operações de gravação futuras sejam processadas com a versão mais recente dos dados. Digamos que a região A esteja ativa e a região B seja passiva (seja para a tabela inteira ou para itens hospedados na região A). O mecanismo típico para realizar uma evacuação é pausar as operações de gravação em A, esperar tempo suficiente para que essas operações sejam totalmente propagadas para B, atualizar a pilha de arquitetura para reconhecer B como ativa e, depois, retomar as operações de gravação em B. Não há métrica que indique com certeza absoluta que a região A replicou totalmente seus dados para a região B. Se a região A estiver íntegra, pausar as operações de gravação na região A e esperar 10 vezes o valor máximo recente da métrica `ReplicationLatency` normalmente será suficiente para determinar que a replicação foi concluída. Se a região A não estiver íntegra e mostrar outras áreas com latência mais alta, escolha um múltiplo maior para o tempo de espera.   Evacuar uma região off-lineRegiões off-line  Evacuar uma região off-line   Há um caso especial a considerar: e se a região A ficar totalmente offline sem aviso prévio? Isso é extremamente improvável, mas deve ser considerado.  

Evacuação de uma tabela MRSC offline  
Caso isso aconteça com uma tabela MRSC, não há nada de especial que você precise fazer. As tabelas MRSC comportam um objetivo de ponto de recuperação (RPO) de zero. Todas as operações de gravação bem-sucedidas feitas na tabela MRSC na região offline estarão disponíveis em todas as outras tabelas da região, portanto, não há nenhuma lacuna possível nos dados, mesmo que a região fique totalmente offline sem aviso prévio. Os negócios podem continuar usando réplicas localizadas em outras regiões. 

Evacuar uma tabela MREC offline  
Se isso acontecer com uma tabela MREC, todas as operações de gravação na região A que ainda não foram propagadas serão mantidas e propagadas depois que a região A voltar a ficar on-line. As operações de gravação não serão perdidas, mas a propagação será adiada indefinidamente.  
A aplicação decidirá como proceder nesse caso. Para a continuidade dos negócios, talvez seja necessário prosseguir para a nova região primária B. No entanto, se um item na região B receber uma atualização enquanto houver uma propagação pendente de uma operação de gravação para esse item da região A, a propagação será suprimida no modelo *último gravador vence*. Qualquer atualização na região B pode suprimir uma solicitação de gravação recebida.  
Com o modo de *gravação em qualquer região*, as leituras e gravações podem continuar na região B, confiando que os itens na região A serão, em algum momento, propagados para a região B, e considerando a possibilidade de haver itens perdidos até que a região A volte a ficar on-line. Quando possível, como em operações de gravação idempotentes, você deve considerar o reprocessamento do tráfego de gravação recente (por exemplo, usando uma fonte de eventos upstream) para preencher a lacuna de quaisquer operações de gravação potencialmente ausentes e permitir que a resolução de conflitos do tipo última gravação prevalece suprima a eventual propagação da operação de gravação de entrada.  
Com os outros modos de gravação, você deve considerar até que ponto o trabalho pode continuar com uma visão de mundo ligeiramente desatualizada. Uma pequena duração das operações de gravação, conforme monitoradas por `ReplicationLatency`, será perdida até que a região A volte a ficar on-line. Os negócios podem prosseguir? Em alguns casos de uso, sim, mas, em outros, talvez não seja possível sem mecanismos adicionais de mitigação.  
Por exemplo, imagine que você precise manter um saldo de crédito disponível sem interrupções, mesmo após uma interrupção total na região. Você pode dividir o saldo em dois itens diferentes: um hospedado na região A e outro na região B, cada um começando com metade do saldo disponível. Isso usa o modo de *gravação em sua região*. As atualizações transacionais processadas em cada região são gravadas com base na cópia local do saldo. Se a região A ficar totalmente off-line, o trabalho ainda poderá prosseguir com o processamento de transações na região B, e as operações de gravação serão limitadas à parte do saldo mantida na região B. Dividir o saldo dessa forma introduz complexidades quando o saldo fica baixo ou o crédito precisa ser reajustado, mas fornece um exemplo de recuperação segura dos negócios, mesmo com operações de gravação pendentes e incertas.  
Em outro exemplo, imagine que você está capturando dados de formulários da web. Você pode usar o [Controle de Simultaneidade Otimista (OCC)](DynamoDBMapper.OptimisticLocking.md) para atribuir versões aos itens de dados e incorporar a versão mais recente ao formulário da web como um campo oculto. Em cada envio, a operação de gravação será bem-sucedida somente se a versão no banco de dados ainda corresponder à versão com a qual o formulário foi criado. Se as versões não corresponderem, o formulário da web poderá ser atualizado (ou mesclado cuidadosamente) com base na versão atual no banco de dados, e o usuário poderá prosseguir novamente. O modelo OCC geralmente protege contra a substituição e a produção de uma nova versão dos dados por outro cliente, mas também pode ajudar durante um failover, quando um cliente pode encontrar versões mais antigas dos dados. Vamos imaginar que você está usando o carimbo de data/hora como a versão. O formulário foi gerado primeiro na região A às 12:00. Após o failover, ao tentar gravar na região B, o sistema descobre que a versão mais recente no banco de dados é das 11:59. Nesse cenário, o cliente pode aguardar até a versão das 12h ser propagada para a região B, depois gravar em cima dessa versão, ou se basear na das 11h59 para criar uma versão das 12h01 (que, depois de ser gravada, vai suprimir a versão recebida após a recuperação da região A).  
Como um terceiro exemplo, uma empresa de serviços financeiros mantém dados sobre contas de clientes e suas transações financeiras em um banco de dados do DynamoDB. Em caso de interrupção completa da região A, a empresa quer garantir que toda atividade de gravação relacionada às contas esteja totalmente disponível na região B, ou deseja colocar em quarentena suas contas como incompletas até que a região A voltar a ficar on-line. Em vez de pausar toda a atividade comercial, a empresa decidiu pausar os negócios apenas na pequena fração de contas que determinaram ter transações não propagadas. Para isso, a empresa usou uma terceira região, que chamaremos de região C. Antes de processar qualquer operação de gravação na região A, a empresa incluiu um resumo sucinto dessas operações pendentes (por exemplo, uma nova contagem de transações para uma conta) na região C. Esse resumo foi suficiente para que a região B determinasse se sua visualização estava totalmente atualizada. Essa ação bloqueou efetivamente a conta desde o momento da gravação na região C até a região A aceitar as operações de gravação e a região B recebê-las. Os dados na região C não foram usados, exceto como parte de um processo de failover, após o qual a região B conseguiu comparar seus dados com a região C para verificar se alguma conta estava desatualizada. Essas contas serão colocadas em quarentena até que a recuperação da região A propague os dados parciais para a região B. Se a região C falhar, uma nova região D poderá ser criada para ser usada em seu lugar. Os dados na região C eram muito transitórios e, após alguns minutos, a região D já teria um registro suficientemente atualizado das operações de gravação em andamento para ser totalmente útil. Se a região B falhasse, a região A poderia continuar aceitando solicitações de gravação em cooperação com a região C. Essa empresa estava disposta a aceitar gravações com latência mais alta (em duas regiões: C e, depois, A) e teve a sorte de ter um modelo de dados em que o estado de uma conta pudesse ser resumido sucintamente.   ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [Processos de evacuação](bp-global-table-design.prescriptive-guidance.evacuation.md) com base no modo de consistência, no modo de gravação e na estratégia de roteamento.
+ Capture métricas sobre integridade, latência e erros em cada região. Para obter uma lista das métricas do DynamoDB, consulte a postagem do blog da AWS [Monitoramento do Amazon DynamoDB para conscientização operacional](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) para obter uma lista de métricas a serem observadas. Você também deve usar [canários sintéticos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (solicitações artificiais projetadas para detectar falhas, nomeadas em referência aos canários nas minas de carvão), bem como a observação ao vivo do tráfego de clientes. Nem todos os problemas aparecerão nas métricas do DynamoDB.
+ Se você estiver usando MREC, defina alarmes para qualquer aumento sustentado em `ReplicationLatency`. Um aumento pode indicar uma configuração incorreta acidental na qual a tabela global tem diferentes configurações de gravação em regiões diferentes, o que leva à falha nas solicitações replicadas e ao aumento das latências. Também pode indicar que há uma interrupção regional. Um [bom exemplo](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) é gerar um alerta se a média recente exceder 180 mil milissegundos. Você também pode observar a queda de `ReplicationLatency` para 0, o que indica uma replicação paralisada.
+ Atribua configurações máximas de leitura e gravação suficientes para cada tabela global.
+ Identifique os motivos para evacuar uma região com antecedência. Se a decisão envolver julgamento humano, documente todas as considerações. Esse trabalho deve ser feito com cuidado e com antecedência, não sob pressão.
+ Mantenha um runbook para cada ação que deve ser tomada ao evacuar uma região. Normalmente, as tabelas globais exigem muito pouco trabalho, mas mover o restante da pilha pode ser complexo. 
**nota**  
Em procedimentos de failover, a prática recomendada é contar apenas com as operações do plano de dados e não com as operações do ambiente de gerenciamento, pois algumas operações do ambiente de gerenciamento podem estar degradadas durante falhas de região.

   Para obter mais informações, consulte a postagem do blog da AWS [Desenvolver aplicações resilientes com tabelas globais do Amazon DynamoDB: parte 4](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/).
+ Teste todos os aspectos do runbook periodicamente, incluindo evacuações de região. Um runbook não testado é um runbook não confiável.
+ Considere usar o [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) para avaliar a resiliência de toda a sua aplicação (incluindo tabelas globais). Ele fornece uma visão abrangente do status geral de resiliência do seu portfólio de aplicações por meio de seu painel.
+ Considere usar as verificações de prontidão do ARC para avaliar a configuração atual da aplicação e rastrear quaisquer desvios das práticas recomendadas.
+ Ao escrever verificações de integridade para uso com o Route 53 ou o Global Accelerator, faça um conjunto de chamadas que abranja todo o fluxo do banco de dados. Se você limitar sua verificação para confirmar apenas se o endpoint do DynamoDB está ativo, não poderá cobrir vários modos de falha, como erros de configuração do AWS Identity and Access Management (IAM), problemas de implantação de código, falha em uma pilha fora do DynamoDB, latências de leitura ou gravação acima da média e assim por diante.

## Perguntas frequentes (FAQ) sobre a implantação de tabelas globais
<a name="bp-global-table-design.prescriptive-guidance.faq"></a>

**Qual é o preço das tabelas globais?**
+ O preço de uma operação de gravação em uma tabela tradicional do DynamoDB é definido em unidades de capacidade de gravação (WCUs, para tabelas provisionadas) ou unidades de solicitação de gravação (WRUs) para tabelas sob demanda. Se você gravar um item de 5 KB, serão cobradas 5 unidades. O preço de uma gravação em uma tabela global é definido em unidades de capacidade de gravação replicada (rWCUs, para tabelas provisionadas), ou unidades de solicitação de gravação replicada (rWRUs, para tabelas sob demanda). As rWCUs e rWRUs têm o mesmo preço que as WCUs e WRUs.
+ As alterações de rWCU e rWRU ocorrem em todas as regiões em que o item é gravado diretamente ou gravado por meio de replicação. Taxas de transferência de dados entre regiões se aplicam.
+ A gravação em um índice secundário global (GSI) é considerada uma operação de gravação local e usa unidades de gravação regulares.
+ Não há nenhuma capacidade reservada disponível para rWCUs ou rWRUs no momento. A compra de capacidade reservada para WCUs ainda pode ser benéfica para tabelas com GSIs que consomem unidades de gravação.
+ Quando você adiciona uma nova região a uma tabela global, o DynamoDB realiza o bootstrap da nova região automaticamente e cobra como se fosse uma restauração de tabela, com base no tamanho em GB da tabela. Ela também cobra taxas de transferência de dados entre regiões.

**Quais regiões são compatíveis com tabelas globais?**

[As tabelas globais versão 2019.11.21 (atual)](GlobalTables.md) comportam todas as Regiões da AWS para tabelas MREC e os seguintes conjuntos de regiões para tabelas MRSC:
+ Conjunto de regiões dos EUA: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon)
+ Conjunto de regiões da Europa: Europa (Irlanda), Europa (Londres), Europa (Paris), Europa (Frankfurt)
+ Conjunto de regiões da AP: Ásia-Pacífico (Tóquio), Ásia-Pacífico (Seul) e Ásia-Pacífico (Osaka).

**Como os GSIs são tratados com tabelas globais?**

Em [Global Tables versão 2019.11.21 (atual)](GlobalTables.md), ao criar um GSI em uma região, ele é criado e preenchido automaticamente em outras regiões participantes. 

**Como faço para interromper a replicação de uma tabela global?** 
+ Você pode excluir uma tabela de réplica da mesma forma que excluiria qualquer outra tabela. A exclusão de uma tabela global interromperá a replicação nessa região e excluirá a cópia da tabela mantida nessa região. No entanto, você não pode interromper a replicação enquanto mantém cópias da tabela como entidades independentes nem pode pausar a replicação.
+ Uma tabela MRSC deve ser implantada em exatamente três regiões. Para excluir as réplicas, você deve excluir todas as réplicas e a testemunha para que a tabela MRSC se torne uma tabela local.

**Como o DynamoDB Streams interage com as tabelas globais?**
+ Cada tabela global produz um fluxo independente com base em todas as operações de gravação, independentemente de onde começaram. Você pode optar por consumir o fluxo do DynamoDB em uma região ou em todas as regiões (de forma independente). Se você quiser processar operações de gravações locais, mas não gravações replicadas, poderá adicionar seu próprio atributo de região a cada item para identificar a região de gravação. Depois, você pode usar um filtro de eventos do Lambda para chamar a função do Lambda somente para gravações na região local. Isso ajuda nas operações de inserção e atualização, mas não ajuda nas operações de exclusão.
+ As tabelas globais configuradas para consistência eventual multirregional (tabelas MREC) replicam as alterações lendo-as de um DynamoDB Stream em uma tabela de réplica e aplicando-as a todas as outras tabelas de réplica. Portanto, o DynamoDB é habilitado por padrão em todas as réplicas em uma tabela MREC global e não pode ser desabilitado nessas réplicas. O processo de replicação do MREC pode combinar várias alterações em um curto período de tempo em uma única operação de gravação replicada. Como resultado, o fluxo de cada réplica pode conter registros ligeiramente diferentes. Os registros do DynamoDB Streams em réplicas de MREC são sempre ordenados por item, mas a ordenação entre itens pode ser diferente entre as réplicas.
+ As tabelas globais configuradas para consistência forte multirregional (tabelas MRSC) não usam o DynamoDB Streams para replicação, portanto, esse recurso não é habilitado por padrão nas réplicas MRSC. Você pode habilitar o DynamoDB Streams em uma réplica do MRSC. Os registros do DynamoDB Streams em réplicas do MRSC são sempre ordenados por item, mas a ordenação entre itens pode ser diferente entre as réplicas.

**Como as tabelas globais lidam com as transações?** 
+ As operações transacionais nas tabelas MRSC gerarão erros.
+ As operações transacionais nas tabelas MREC fornecem garantia de atomicidade, consistência, isolamento e durabilidade (ACID) somente na região em que a operação de gravação ocorreu originalmente. As transações não são compatíveis entre regiões em tabelas globais. Por exemplo, se você tiver uma tabela MREC global com réplicas nas regiões do Leste dos EUA (Ohio) e do Oeste dos EUA (Oregon) e realizar uma operação `TransactWriteItems` na região do Leste dos EUA (Ohio), poderá observar transações parcialmente concluídas na região do Oeste dos EUA (Oregon) à medida que as alterações forem replicadas. As alterações só são replicadas para outras regiões quando forem confirmadas na região de origem.

** Como as tabelas globais interagem com o cache do DynamoDB Accelerator (DAX)?**

As tabelas globais ignoram o DAX ao atualizar o DynamoDB diretamente, por isso o DAX não sabe que está armazenando dados obsoletos. O cache do DAX só é atualizado quando a TTL do cache expira.

**As etiquetas nas tabelas são propagadas?**

Não, as etiquetas não são propagadas automaticamente.

**Devo fazer backup de tabelas em todas as regiões ou em apenas uma?**

A resposta depende da finalidade do backup.
+ Se sua intenção é garantir a durabilidade dos dados, o DynamoDB já fornece essa proteção. O serviço garante a durabilidade.
+ Se você quiser manter um snapshot para registros históricos (por exemplo, para atender aos requisitos regulatórios), o backup em uma única região deverá ser suficiente. Você pode copiar o backup para outras regiões usando o AWS Backup.
+ Se você quiser recuperar dados excluídos ou modificados incorretamente, use a [recuperação para um ponto no tempo (PITR) do DynamoDB](PointInTimeRecovery_Howitworks.md) em uma região.

**Como faço para implantar tabelas globais usando o CloudFormation?**
+ O CloudFormation representa uma tabela do DynamoDB e uma tabela global como dois recursos separados: `AWS::DynamoDB::Table` e `AWS::DynamoDB::GlobalTable`. Uma abordagem é criar todas as tabelas que possam ser globais usando o constructo `GlobalTable`, mantê-las como tabelas independentes inicialmente e adicionar regiões posteriormente, se necessário. 
+ No CloudFormation, cada tabela global é controlada por uma única pilha, em uma só região, independentemente do número de réplicas. Quando seu modelo for implantado, o CloudFormation criará e atualizará todas as réplicas como parte de uma única operação de pilha. Você não deve implantar o mesmo atributo [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) em várias regiões. Isso não é compatível e resultará em erros. Se você implantar seu modelo de aplicação em várias regiões, poderá usar condições para criar o recurso `AWS::DynamoDB::GlobalTable` em uma única região. Se quiser, você poderá optar por definir recursos `AWS::DynamoDB::GlobalTable` em uma pilha separada da pilha de aplicações e garantir que ela seja implantada apenas em uma região. 
+ Se você tiver uma tabela regular e quiser convertê-la em uma tabela global enquanto a mantém gerenciada pelo CloudFormation, defina a política de exclusão como `Retain`, remova a tabela da pilha, converta-a em global no console e importe a tabela global como um novo atributo para a pilha. Para acessar mais informações, consulte o [repositório do GitHub da AWS](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk).
+ No momento, a replicação entre contas não é compatível.