Como funcionam as tabelas globais do DynamoDB - Amazon DynamoDB
Monitoramento

Como funcionam as tabelas globais do DynamoDB

As tabelas globais de várias contas estendem os recursos totalmente gerenciados, multirregionais, sem servidor e multiativos das tabelas globais do DynamoDB para abranger várias contas da AWS. As tabelas globais de várias contas replicam dados entre regiões e contas da AWS, oferecendo a mesma funcionalidade ativa-ativa das tabelas globais da mesma conta. Quando você grava em qualquer réplica, o DynamoDB replica os dados em todas as outras réplicas.

As principais diferenças em relação às tabelas globais da mesma conta incluem:

  • É possível usar a replicação multirregional com tabelas globais com consistência final multirregional (MREC).

  • Só é possível adicionar réplicas começando com uma tabela de região única. Não é possível converter uma tabela global existente da mesma conta em uma configuração de várias contas. Para migrar e criar uma tabela global de várias contas, primeiro é necessário excluir as réplicas existentes para retornar a uma tabela de região única.

  • Cada réplica deve residir em uma conta da AWS separada. Para uma tabela global de várias contas com N réplicas, é necessário ter N contas.

  • Por padrão, as tabelas globais de várias contas usam configurações de tabela unificadas em todas as réplicas. Todas as réplicas compartilham automaticamente a mesma configuração (como modo de throughput e TTL) e, diferentemente das tabelas globais da mesma conta, essas configurações não podem ser substituídas por réplicas.

  • Os clientes devem fornecer permissões de replicação à entidade principal do serviço de tabelas globais do DynamoDB em suas políticas de recursos.

As tabelas globais de várias contas usam a mesma tecnologia de replicação subjacente das tabelas globais da mesma conta. As configurações da tabela são replicadas automaticamente em todas as réplicas regionais e os clientes não podem substituí-las por réplicas nem personalizá-las. Isso garante uma configuração consistente e um comportamento previsível em várias contas da AWS que compartilham a mesma tabela global.

As configurações nas tabelas globais do DynamoDB definem como uma tabela se comporta e como os dados são replicados nas regiões. Essas configurações são definidas por meio de APIs do ambiente de gerenciamento do DynamoDB durante a criação da tabela ou ao adicionar uma nova réplica regional.

Ao criar uma tabela global de várias contas, os clientes devem definir GlobalTableSettingsReplicationMode = ENABLED para cada réplica regional. Isso garante que as alterações de configuração feitas em uma região se propaguem automaticamente para todas as outras regiões que compartilham a tabela global.

É possível habilitar a replicação das configurações após a criação da tabela. Isso é adequado para o cenário em que uma tabela é criada originalmente como uma tabela regional e depois atualizada para uma tabela global de várias contas.

Configurações sincronizadas

As seguintes configurações são sempre sincronizadas entre as réplicas em uma tabela global de várias contas:

nota

Diferentemente das tabelas globais da mesma conta, as tabelas globais de várias contas não permitem substituições por região para essas configurações. A única exceção é que as substituições de políticas de ajuste de escala automático de leitura (tabelas e GSIs) são permitidas, pois são recursos externos separados.

  • Modo de capacidade (capacidade provisionada ou sob demanda)

  • Capacidade provisionada de leitura e gravação da tabela

  • Ajuste de escala automático de leitura e gravação da tabela

  • Definição do índice secundário local (LSI)

  • Definição do Índice Secundário Global (GSI)

  • Capacidade provisionada de leitura e gravação do GSI

  • Ajuste de escala automático de leitura e gravação do GSI

  • Definição de streams no modo MREC

  • Vida útil (TTL)

  • Throughput a quente

  • Throughput máximo sob demanda de leitura e gravação

Configurações não sincronizadas

As configurações a seguir não são sincronizadas entre as réplicas e devem ser definidas de forma independente para cada tabela-réplica em cada região.

  • Classe de tabela

  • Tipo de criptografia do lado do servidor (SSE)

  • Recuperação para um ponto no tempo

  • ID da chave do KMS da criptografia do lado do servidor (SSE)

  • Proteção contra exclusão

  • Kinesis Data Streams (KDSD)

  • Tags

  • Política de recursos

  • Tabela Cloudwatch-Contributor Insights (CCI)

  • GSI Cloudwatch-Contributor Insights (CCI)

Monitoramento

Tabelas globais configuradas para consistência final em várias regiões (MREC) publicam a métrica ReplicationLatency no CloudWatch. Essa métrica controla o tempo decorrido entre quando um item foi gravado em uma tabela-réplica e quando esse item aparece em outra réplica na tabela global. ReplicationLatency é expresso em milissegundos e é emitido para cada par de regiões de origem e destino em uma tabela global.

Os valores típicos de ReplicationLatency dependem da distância entre as regiões da AWS escolhidas, bem como de outras variáveis como tipo de workload e throughput. Por exemplo, uma réplica de origem na região Oeste dos EUA (N. da Califórnia) (us-west-1) tem uma ReplicationLatency menor para a região Oeste dos EUA (Oregon) (us-west-2) em comparação com a região África (Cidade do Cabo) (af-south-1).

Um valor elevado para ReplicationLatency pode indicar que as atualizações de uma réplica não se propagaram para outras tabelas-réplica em tempo hábil. Nesse caso, você pode redirecionar temporariamente as atividades de leitura e gravação da aplicação para outra região da AWS.

Lidar com problemas de latência de replicação em tabelas globais de várias contas

Se ReplicationLatency exceder três horas devido a problemas causados pelo cliente em uma tabela-réplica, o DynamoDB enviará uma notificação solicitando que o cliente resolva o problema subjacente. Os problemas comuns causados pelo cliente que podem impedir a replicação incluem:

  • Remover as permissões necessárias da política de recursos da tabela-réplica.

  • Optar por não aderir a uma região da AWS que hospede uma réplica da tabela global de várias contas.

  • Negar as permissões da chave do AWS KMS da tabela necessárias para descriptografar dados.

Dentro de três horas, o DynamoDB enviará uma notificação inicial de alta latência de replicação, seguida de uma segunda notificação após vinte horas se o problema continuar sem solução. Se o problema não for corrigido dentro do período exigido, o DynamoDB desassociará automaticamente a réplica da tabela global. Depois, a réplica afetada será convertida em uma tabela regional.