Diferenças de comportamento entre as versões herdada e atual Pré-requisitos da atualização Permissões obrigatórias O que esperar durante a atualização Comportamento do DynamoDB Streams Atualizar para a versão 2019.11.21 (atual)

Atualizar tabelas globais para a versão atual (2019.11.21) partindo da versão herdada (2017.11.29)

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). Os clientes devem usar a versão 2019.11.21 (atual) sempre que possível, pois ela oferece maior flexibilidade e eficiência e consome menos capacidade de gravação que a 2017.11.29 (herdada). Para determinar qual versão você está usando, consulte Determinar a versão da tabela global que você está usando.

Esta seção descreve como atualizar tabelas globais para a versão 2019.11.21 (atual) usando o console do DynamoDB. Atualizar da versão 2017.11.29 (herdada) para a versão 2019.11.21 (atual) é uma ação única que não pode ser revertida. No momento, é possível atualizar tabelas globais usando apenas o console.

Tópicos

Diferenças de comportamento entre as versões herdada e atual
Pré-requisitos da atualização
Permissões obrigatórias
O que esperar durante a atualização
Comportamento do DynamoDB Streams
Atualizar para a versão 2019.11.21 (atual)

Diferenças de comportamento entre as versões herdada e atual

A lista a seguir descreve as diferenças de comportamento entre as versões herdada e atual das tabelas globais.

A versão 2019.11.21 (atual) consome menor capacidade de gravação para várias operações do DynamoDB em comparação à versão 2017.11.29 (herdada) e, portanto, é mais econômica para a maioria dos clientes. As diferenças dessas operações do DynamoDB são as seguintes:

Invocar PutItem para um item de 1 KB em uma região e replicar para outras regiões requer 2 rWRUs por região para a 2017.11.29 (herdada), mas apenas 1 rWRU para a 2019.11.21 (atual).
Invocar UpdateItem para um item de 1 KB requer 2 rWRUs na região de origem e 1 rWRU por região de destino para a 2017.11.29 (herdada), mas apenas 1 rWRU para as regiões de origem e de destino para a 2019.11.21 (atual).
Invocar DeleteItem para um item de 1 KB requer 1 rWRU na região de origem e 2 rWRUs por região de destino para a 2017.11.29 (herdada), mas apenas 1 rWRU para as regiões de origem e de destino para a 2019.11.21 (atual).

A tabela a seguir mostra o consumo de rWRU para as tabelas de 2017.11.29 (herdada) e 2019.11.21 (atual).

Consumo de rWRU das tabelas de 2017.11.29 (herdada) e 2019.11.21 (atual) para um item de 1 KB em duas regiões
Operation	2017.11.29 (herdada)	2019.11.21 (atual)	Economia
PutItem	4 rWRUs	2 rWRUs	50%
UpdateItem	3 rWRUs	2 rWRUs	33%
DeleteItem	3 rWRUs	2 rWRUs	33%

A versão 2017.11.29 (herdada) está disponível somente em 11 Regiões da AWS. No entanto, a versão 2019.11.21 (atual) está disponível em todas as Regiões da AWS.
Você deve criar tabelas globais da versão 2017.11.29 (herdada) criando primeiro um conjunto de tabelas regionais vazias e, depois, invocando a API CreateGlobalTable para formar a tabela global. As tabelas globais da versão 2019.11.21 (atual) são criadas invocando a API UpdateTable para adicionar uma réplica a uma tabela regional existente.
A versão 2017.11.29 (herdada) exige que você esvazie todas as réplicas na tabela antes de adicionar uma réplica em uma nova região (inclusive durante a criação). A versão 2019.11.21 (atual) aceita remover e adicionar réplicas a regiões em uma tabela que já contém dados.
A versão 2017.11.29 (herdada) usa o seguinte conjunto dedicado de APIs de ambiente de gerenciamento para gerenciar réplicas:
A versão 2019.11.21 (atual) usa as APIs DescribeTable e UpdateTable para gerenciar réplicas.
A versão 2017.11.29 (herdada) publica dois registros do DynamoDB Streams para cada gravação. A versão 2019.11.21 (atual) publica um registro do DynamoDB Streams para cada gravação.
A versão 2017.11.29 (herdada) preenche e atualiza os atributos aws:rep:deleting, aws:rep:updateregion e aws:rep:updatetime. A versão 2019.11.21 (atual) não preenche nem atualiza esses atributos.
A versão 2017.11.29 (herdada) não sincroniza configurações de Vida útil (TTL) entre réplicas. A versão 2019.11.21 (atual) sincroniza as configurações de TTL em todas as réplicas.
A versão 2017.11.29 (herdada) não replica as exclusões de TTL para outras réplicas. A versão 2019.11.21 (atual) replica as exclusões de TTL para todas as réplicas.
A versão 2017.11.29 (herdada) não sincroniza configurações de ajuste de escala automático entre réplicas. A versão 2019.11.21 (atual) sincroniza as configurações de ajuste de escala automático em todas as réplicas.
A versão 2017.11.29 (herdada) não sincroniza configurações de índice secundário global (GSI) entre réplicas. A versão 2019.11.21 (atual) sincroniza as configurações de GSI em todas as réplicas.
A versão 2017.11.29 (herdada) não sincroniza configurações de criptografia em repouso entre réplicas. A versão 2019.11.21 (atual) sincroniza as configurações de criptografia em repouso em todas as réplicas.
A versão 2017.11.29 (herdada) publica a métrica PendingReplicationCount. A versão 2019.11.21 (atual) não publica essa métrica.

Pré-requisitos da atualização

Antes de iniciar a atualização para as tabelas globais da versão 2019.11.21 (atual), é necessário atender aos seguintes pré-requisitos:

As configurações de Vida útil (TTL) nas réplicas são consistentes em todas as regiões.
As definições de índice secundário global (GSI) em réplicas são consistentes em todas as regiões.
As configurações de criptografia em repouso nas réplicas são consistentes em todas as regiões.
O ajuste de escala automático do DynamoDB está habilitado para WCUs para todas as réplicas ou o modo de capacidade sob demanda está habilitado para todas as réplicas.
As aplicações não exigem a presença dos atributos aws:rep:deleting, aws:rep:updateregion e aws:rep:updatetime nos itens da tabela.

Permissões obrigatórias para a atualização de tabelas globais

Para realizar a atualização para a versão 2019.11.21 (atual), é necessário ter permissões dynamodb:UpdateGlobalTableVersion em todas as regiões com réplicas. Essas permissões se somam às permissões necessárias para acessar o console do DynamoDB e visualizar tabelas.

A política do IAM a seguir concede permissões para atualizar qualquer tabela global para a versão 2019.11.21 (atual).


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableVersion",
            "Resource": "*"
        }
    ]
}

A política do IAM a seguir concede permissões para atualizar apenas a tabela global Music, com réplicas em duas regiões, para a versão 2019.11.21 (atual).


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableVersion",
            "Resource": [
                "arn:aws:dynamodb::123456789012:global-table/Music",
                "arn:aws:dynamodb:ap-southeast-1:123456789012:table/Music",
                "arn:aws:dynamodb:us-east-2:123456789012:table/Music"
            ]
        }
    ]
}

O que esperar durante a atualização

Todas as réplicas de tabelas globais continuarão processando o tráfego de leitura e gravação durante a atualização.
O processo de atualização requer de alguns minutos a várias horas, dependendo do tamanho da tabela e do número de réplicas.
Durante o processo de atualização, o valor de TableStatus mudará de ACTIVE para UPDATING. É possível ver o status da tabela invocando a API DescribeTable ou com a visualização Tabelas no console do DynamoDB.
O ajuste de escala automático não alterará as configurações de capacidade provisionada para uma tabela global enquanto a tabela estiver sendo atualizada. É altamente recomendável definir a tabela como o modo de capacidade sob demanda durante a atualização.
Se você optar por usar o modo de capacidade provisionada com ajuste de escala automático durante a atualização, será necessário aumentar o throughput mínimo de leitura e gravação em suas políticas para atender aos aumentos esperados no tráfego e evitar o controle de utilização durante a atualização.
Quando o processo de atualização estiver concluído, o status da tabela mudará para ACTIVE.

Comportamento do DynamoDB Streams antes, durante e depois da atualização

Atualizar para a versão 2019.11.21 (atual)

Siga estas etapas para atualizar a versão das tabelas globais do DynamoDB usando o AWS Management Console.

Como atualizar tabelas globais para a versão 2019.11.21 (atual)

Abra o console do DynamoDB em https://console.aws.amazon.com/dynamodb/.
No painel de navegação no lado esquerdo do console, escolha Tabelas e selecione a tabela global que você deseja atualizar para a versão 2019.11.21 (atual).
Selecione a guia Global Tables (Tabelas globais).
Escolha Update version (Atualizar versão).
Leia e concorde com os novos requisitos e escolha Update version (Atualizar versão).
Após a conclusão do processo de atualização, a versão de tabelas globais exibida no console muda para 2019.11.21.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Determinar a versão

Trabalhar com operações de leitura e gravação

Operation	Região de réplica	Comportamento antes da atualização	Comportamento durante a atualização	Comportamento após a atualização
Inserir ou atualizar	Origem	O preenchimento do carimbo de data e hora é feito por meio de UpdateItem.	O preenchimento do carimbo de data e hora é feito por meio de PutItem.	Nenhum carimbo de data e hora visível para o cliente é gerado.
		Dois registros do Streams são gerados. O primeiro contém os atributos gravados pelo cliente. O segundo contém os atributos `aws:rep:*`.	Dois registros do Streams são gerados. O primeiro contém os atributos gravados pelo cliente. O segundo contém os atributos `aws:rep:*`.	Um único registro do Streams é gerado contendo os atributos gravados pelo cliente.
		Duas rWCUs são consumidas para cada gravação do cliente.	Duas rWCUs são consumidas para cada gravação do cliente.	Uma rWCU é consumida para cada gravação do cliente.
		As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	A métrica `ReplicationLatency` é publicada no CloudWatch.
	Destination (Destino)	A replicação acontece usando PutItem.	A replicação acontece usando PutItem.	A replicação acontece usando PutItem.
		É gerado um único registro do Streams, que contém os atributos gravados pelo cliente e os atributos `aws:rep:*`.	É gerado um único registro do Streams, que contém os atributos gravados pelo cliente e os atributos `aws:rep:*`.	É gerado um único registro do Streams, que contém somente os atributos gravados pelo cliente e nenhum atributo de replicação.
		Uma rWCU será consumida se o item existir na região de destino. Duas rWCUs serão consumidas se o item não existir na região de destino.	Uma rWCU será consumida se o item existir na região de destino. Duas rWCUs serão consumidas se o item não existir na região de destino.	Uma rWCU é consumida para cada gravação do cliente.
		As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	A métrica `ReplicationLatency` é publicada no CloudWatch.
Excluir	Origem	Exclua qualquer item com carimbo de data e hora menor usando DeleteItem.	Exclua qualquer item com carimbo de data e hora menor usando DeleteItem.	Exclua qualquer item com carimbo de data e hora menor usando DeleteItem.
		É gerado um único registro do Streams, que contém os atributos gravados pelo cliente e os atributos `aws:rep:*`.	É gerado um único registro do Streams, que contém os atributos gravados pelo cliente e os atributos `aws:rep:*`.	É gerado um único registro do Streams, que contém os atributos gravados pelo cliente.
		Uma rWCU é consumida para cada exclusão do cliente.	Uma rWCU é consumida para cada exclusão do cliente.	Uma rWCU é consumida para cada exclusão do cliente.
		As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	A métrica `ReplicationLatency` é publicada no CloudWatch.
	Destination (Destino)	Ocorrem exclusões em duas fases: Na Fase 1, UpdateItem define o sinalizador de exclusão. Na Fase 2, DeleteItem exclui o item.	Exclui o item usando DeleteItem.	Exclui o item usando DeleteItem.
		Dois registros do Streams são gerados. O primeiro registro contém a alteração no campo `aws:rep:deleting`. O segundo registro contém os atributos gravados pelo cliente e os atributos `aws:rep:*`.	É gerado um único registro do Streams, que contém os atributos gravados pelo cliente.	É gerado um único registro do Streams, que contém os atributos gravados pelo cliente.
		Duas rWCUs são consumidas para cada exclusão do cliente.	Uma rWCU é consumida para cada exclusão do cliente.	Uma rWCU é consumida para cada exclusão do cliente.
		As métricas `ReplicationLatency` e `PendingReplicationCount` são publicadas no CloudWatch.	A métrica `ReplicationLatency` é publicada no CloudWatch.	A métrica `ReplicationLatency` é publicada no CloudWatch.