Principais conceitos sobre tabelas globais
As seções a seguir descrevem os conceitos e os comportamentos das tabelas globais no Amazon DynamoDB.
Conceitos
As tabelas globais são um recurso do DynamoDB que replica os dados da tabela em todas as regiões da AWS.
Uma tabela-réplica (ou réplica) é uma única tabela do DynamoDB que funciona como parte de uma tabela global. Uma tabela global consiste em duas ou mais tabelas de réplica em diferentes regiões da AWS. Cada tabela global só pode ter uma réplica por região da AWS. Todas as réplicas em uma tabela global compartilham o mesmo nome da tabela, esquema de chave primária e dados do item.
Quando uma aplicação grava dados em uma réplica em uma região, o DynamoDB replica automaticamente a gravação para as outras réplicas na tabela global. Para ter mais informações para começar a usar tabelas globais, consulte Tutoriais: Criação de tabelas globais ou Tutoriais: criar de tabelas globais de várias contas.
Versões
Há duas versões disponíveis das tabelas globais do DynamoDB: Global Tables versão 2019.11.21 (atual) e Global Tables versão 2017.11.29 (herdada). É necessário usar a versão de tabelas globais 2019.11.21 (atual) sempre que possível. As informações nesta seção de documentação são para a versão 2019.11.21 (atual). Para ter mais informações sobre como determinar a versão de uma tabela global, consulte Determinar a versão de uma tabela global.
Disponibilidade
As tabelas globais ajudam a melhorar a continuidade de seus negócios, facilitando a implementação de uma arquitetura de alta disponibilidade multirregional. Se uma workload em uma única região da AWS se tornar prejudicada, você poderá transferir o tráfego do aplicativo para uma região diferente e executar leituras e gravações em uma tabela de réplica diferente na mesma tabela global.
Cada tabela de réplica em uma tabela global oferece a mesma durabilidade e disponibilidade de uma tabela do DynamoDB de região única. As tabelas globais oferecem um Acordo de Serviço (SLA)
Teste de injeção de falhas
As tabelas globais MREC e MRSC integram-se ao Serviço de Injeção de Falhas da AWS (AWS FIS), um serviço totalmente gerenciado para executar experimentos de injeção de falhas controladas para melhorar a resiliência de uma aplicação. Por meio do AWS FIS, é possível:
-
Criar modelos de experimentos que definam cenários de falha específicos.
-
Injetar falhas para validar a resiliência da aplicação simulando o isolamento de região (isto é, pausando a replicação de e para uma réplica selecionada) para testar o tratamento de erros, os mecanismos de recuperação e o comportamento de mudança de tráfego em várias regiões quando uma região da AWS sofre interrupções.
Por exemplo, em uma tabela global com réplicas nas regiões Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio) e Oeste dos EUA (Oregon), é possível executar um experimento na região Leste dos EUA (Ohio) para testar o isolamento de região lá e, ao mesmo tempo, continuar as operações normais na região Oeste dos EUA (Oregon). Esse teste controlado ajuda você a identificar e resolver possíveis problemas antes que eles afetem as workloads de produção.
Consulte Destinos da ação no Guia do usuário do AWS FIS para ver uma lista completa das ações permitidas pelo AWS FIS e da conectividade entre regiões para pausar a replicação do DynamoDB entre regiões.
Para ter informações sobre as ações de tabelas globais do Amazon DynamoDB disponíveis no AWS FIS, consulte Referência de ações de tabelas globais do DynamoDB no Guia do usuário do AWS.
Para começar a realizar experimentos de injeção de falhas, consulte Planejar experimentos do AWS FIS no “Guia do usuário do AWS FIS”.
nota
Durante experimentos do AWS FIS no modo de consistência forte multirregional (MRSC), leituras finais consistentes são permitidas, mas atualizações de configuração de tabela, como alterar o modo de cobrança ou configurar o throughput da tabela, não são permitidas, de maneira semelhante ao modo de consistência final multirregional (MREC). Verifique a métrica FaultInjectionServiceInducedErrors do CloudWatch para ver detalhes adicionais sobre o código de erro.
Vida útil (TTL)
As tabelas globais configuradas para o MREC dão suporte à configuração da exclusão Time To Live (TTL). As configurações de TTL são sincronizadas automaticamente para todas as réplicas em uma tabela global. Quando o TTL exclui um item de uma réplica em uma região, a exclusão é replicada para todas as outras réplicas na tabela global. O TTL não consome capacidade de gravação, portanto, você não é cobrado pela exclusão TTL na região em que a exclusão ocorreu. No entanto, você é cobrado pela exclusão replicada em cada outra região com uma réplica na tabela global.
A replicação de exclusão TTL consome capacidade de gravação nas réplicas nas quais a exclusão está sendo replicada. As réplicas configuradas para capacidade provisionada podem limitar as solicitações de controle de utilização se a combinação de throughput de gravação e throughput de exclusão TTL for maior que a capacidade de gravação provisionada.
As tabelas globais configuradas para consistência forte multirregional (MRSC) não suportam a configuração da exclusão Time To Live (TTL).
Fluxos
As tabelas globais configuradas para consistência final multirregional (MREC) replicam as alterações lendo essas alterações de um DynamoDB Stream em uma tabela de réplica e aplicando essa alteração a todas as outras tabelas de réplica. Portanto, os streams são habilitados por padrão em todas as réplicas em uma tabela global do MREC e não podem ser desativados 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 gravação replicada, resultando em cada fluxo de réplica contendo registros ligeiramente diferentes. Os registros de fluxos nas réplicas com MREC mantêm a ordem de todas as alterações no mesmo item, mas a ordem relativa das alterações em itens diferentes pode variar entre as réplicas.
Se você quiser escrever um aplicativo que processe registros do Streams para alterações que ocorreram em uma determinada região, mas não em outras em uma tabela global, você pode adicionar um atributo a cada item que define em qual região a alteração desse item ocorreu. Você pode usar esse atributo para filtrar os registros do Streams em busca de alterações que ocorreram em outras regiões, incluindo o uso de filtros de eventos do Lambda para invocar somente as funções do Lambda para alterações em uma região específica.
As tabelas globais configuradas para consistência forte multirregionais (MRSC) não usam o DynamoDB Streams para replicação, portanto, o Streams não é habilitado por padrão nas réplicas do MRSC. Você pode habilitar o Streams em uma réplica do MRSC. Os registros de streams nas réplicas do MRSC são idênticos para cada réplica, incluindo a ordenação dos registros do Stream.
Transações
Em uma tabela global configurada para MREC, as operações de transação (TransactWriteItems e TransactGetItems) do DynamoDB são atômicas somente na região em que a operação foi invocada. As gravações transacionais não são replicadas como uma unidade em todas as regiões, o que significa que somente algumas das gravações em uma transação podem ser retornadas por operações de leitura em outras réplicas em um determinado momento.
Por exemplo, se você tiver uma tabela global com réplicas nas regiões Leste dos EUA (Ohio) e Oeste dos EUA (Oregon) e realizar uma operação TransactWriteItems na região Leste dos EUA (Ohio), poderá observar transações parcialmente concluídas na região Oeste dos EUA (Oregon) à medida que as alterações forem replicadas. As alterações só serão replicadas para outras regiões quando forem confirmadas na região de origem.
As tabelas globais configuradas para consistência forte multirregional (MRSC) não dão suporte a operações de transação e retornarão um erro se essas operações forem invocadas em uma réplica do MRSC.
Throughput de leitura e gravação
Modo provisionado
A replicação consome capacidade de gravação. As réplicas configuradas para capacidade provisionada podem controlar a utilização de solicitações se a soma do throughput de gravação de aplicação e do throughput de gravação de replicação ultrapassar a capacidade de gravação provisionada. Para tabelas globais que usam o modo provisionado, as configurações de ajuste de escala automático das capacidades de leitura e gravação são sincronizadas entre as réplicas.
É possível definir de forma independente as configurações de capacidade de leitura para cada réplica em uma tabela global usando o parâmetro ProvisionedThroughputOverride em nível de réplica. Por padrão, as alterações na capacidade de leitura provisionada são aplicadas a todas as réplicas na tabela global. Ao adicionar uma nova réplica a uma tabela global, a capacidade de leitura da tabela ou réplica de origem é usada como valor inicial, a menos que uma substituição em nível de réplica seja especificada explicitamente.
Modo sob demanda
Para tabelas globais configuradas para o modo sob demanda, a capacidade de gravação é sincronizada automaticamente em todas as réplicas. O DynamoDB ajusta automaticamente a capacidade com base no tráfego, e não há configurações de capacidade de leitura ou gravação específicas da réplica para gerenciar.
Monitorar tabelas globais
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.
As tabelas globais configuradas para consistência forte multirregional (MRSC) não publicam uma métrica de ReplicationLatency.
Considerações para gerenciar tabelas globais
Você não pode excluir uma tabela usada para adicionar uma nova réplica de tabela global até que tenham decorrido 24 horas desde que a nova réplica foi criada.
Se você desabilitar uma região da AWS que contém réplicas de tabelas globais, essas réplicas serão convertidas permanentemente em tabelas de região única 20 horas após a desativação da região.
