Práticas recomendadas e requisitos para gerenciar tabelas globais
Ao usar as tabelas globais do Amazon DynamoDB, você pode replicar os dados da tabela nas regiões da AWS. É importante que as tabelas de réplica e índices secundários na tabela global tenham configurações idênticas de capacidade de gravação para garantir a replicação apropriada dos dados.
Para esclarecimento futuro, pode ser útil não colocar a região no nome de nenhuma tabela que um dia possa ser transformada em uma tabela global.
Atenção
O nome de cada tabela global deve ser exclusivo dentro da conta da AWS.
Versão de tabelas globais
Para determinar a versão da tabela global que você está usando, consulte Determinar a versão da tabela global que você está usando.
Requisitos de gerenciamento de capacidade
Uma tabela global deve ter a capacidade de throughput configurada de uma duas maneiras:
-
Modo de capacidade sob demanda, medido em unidades de solicitação de gravação replicadas (RWRUs)
-
Modo de capacidade provisionada com Auto Scaling, medido em unidades de capacidade de gravação replicada (rWCUs)
Usar o modo de capacidade provisionada com Auto Scaling ou o modo de capacidade sob demanda garante que a tabela global tenha capacidade suficiente para realizar gravações replicadas para todas as regiões da tabela global.
nota
Mudar de um modo de capacidade de tabela para outro modo de capacidade em qualquer região alterna o modo para todas as réplicas.
Implantar tabelas globais
No AWS CloudFormation, cada tabela global é controlada por uma única pilha em uma só região. Isso independe do número de réplicas. Quando seu modelo for implantado, o CloudFormation criará/atualizará todas as réplicas como parte de uma única operação de pilha. Por isso, você não deve implantar o mesmo recurso AWS::DynamoDB::GlobalTable em várias regiões. Essa operação não é compatível e resultará em erros.
Se você implantar o modelo de aplicação em várias regiões, poderá usar condições para criar o recurso em uma única região. Se quiser, você pode 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. Para obter mais informações, consulte Tabelas globais no CloudFormation.
Uma tabela do DynamoDB é referida como AWS::DynamoDB::Table, e uma tabela global como AWS::DynamoDB::GlobalTable. No que diz respeito ao CloudFormation, isso as torna dois recursos diferentes. Por isso, uma abordagem é criar todas as tabelas que possam ser globais usando a estrutura GlobalTable. Você pode mantê-las como tabelas independentes para começar, depois adicioná-las às regiões, se necessário.
Se você tem uma tabela normal e deseja convertê-la enquanto usa o CloudFormation, um método recomendado é o seguinte:
Defina a política de exclusão a ser mantida.
Remova a tabela da pilha.
Converta a tabela em uma tabela global no console.
Importe a tabela global como um novo recurso para a pilha.
nota
No momento, a replicação entre contas não é compatível.
Usar tabelas globais para lidar melhor com uma possível interrupção da região
Tenha ou crie rapidamente cópias independentes da pilha de execução em regiões alternativas, cada uma acessando o respectivo endpoint local do DynamoDB.
Use o Route53 ou o AWS Global Accelerator a fim de rotear para a região íntegra mais próxima. Uma alternativa é garantir que o cliente conheça os vários endpoints que ele pode usar.
Use verificações de integridade em cada região que possam determinar com segurança se há algum problema com a pilha, inclusive se o DynamoDB está degradado. Por exemplo, não se limite a verificar se o endpoint do DynamoDB está ativo. Faça uma chamada que garanta um fluxo de banco de dados completo e bem-sucedido.
Se a verificação de integridade falhar, o tráfego poderá ser direcionado para outras regiões (atualizando a entrada de DNS com o Route53 ao fazer com que o Global Accelerator roteie de maneira diferente ou ao fazer com que o cliente escolha um endpoint diferente). As tabelas globais têm um bom objetivo de ponto de recuperação (RPO) porque os dados são sincronizados continuamente e um bom objetivo de tempo de recuperação (RTO) porque ambas as regiões sempre mantêm uma tabela pronta para o tráfego de leitura e gravação.
Para obter mais informações sobre verificações de integridade, consulte Tipos de verificação de integridade.
nota
Como o DynamoDB é um serviço central no qual outros serviços frequentemente baseiam suas operações de ambiente de gerenciamento, é improvável que você encontre um cenário em que o DynamoDB tenha degradado o serviço em uma região e outros serviços não tenham sido afetados.
Fazer backup de tabelas globais
Ao fazer backup de tabelas globais, basta fazer backup das tabelas em uma região, e não de todas as tabelas em todas as regiões. Se o objetivo for recuperar dados excluídos ou modificados erroneamente, o PITR em uma região será suficiente. Da mesma forma, ao preservar um snapshot para fins históricos, como requisitos regulatórios, o backup em uma região deve ser suficiente. Os dados de backup podem ser replicados para várias regiões via AWS Backup.
Réplicas e cálculo de unidades de gravação
Para planejamento, você deve pegar o número de gravações que uma região realizará e somá-lo com o número de gravações que ocorrem para cada região. Isso é essencial, pois cada gravação realizada em uma região também deve ser realizada em cada região de réplica. Se você não tiver capacidade suficiente para lidar com todas as gravações, ocorrerão exceções de capacidade. Além disso, os tempos de espera de replicação inter-regional aumentarão.
Por exemplo, suponha que você espere 5 gravações por segundo para a tabela-réplica em Ohio, 10 gravações por segundo para a tabela-réplica no Norte da Virgínia e 5 gravações por segundo na tabela de réplica na Irlanda. Nesse caso, você deve esperar consumir 20 rWCU ou rWRUs em cada região: Ohio, Norte da Virgínia e Irlanda. Em outras palavras, você deve esperar consumir 60 RWCU no total para todas as três regiões.
Para obter detalhes sobre a capacidade provisionada com Auto Scaling e o DynamoDB, consulte Gerenciar a capacidade de throughput automaticamente com o Auto Scaling do DynamoDB.
nota
Se uma tabela estiver sendo executada no modo de capacidade provisionada com autoescalabilidade, a capacidade de gravação provisionada poderá flutuar dentro das configurações de autoescalabilidade de cada região.
