Modo de gravação em uma região (primária única) - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Modo de gravação em uma região (primária única)

O modo de gravação em uma região, ilustrado no diagrama a seguir, é ativo-passivo e encaminha todas as operações de gravação da tabela para uma única região ativa. (O DynamoDB não tem a noção de uma única região ativa; a camada externa do DynamoDB gerencia isso.) O modo de gravação em uma região funciona bem para tabelas MREC que precisam evitar conflitos de gravação, garantindo que as operações de gravação fluam somente para uma região por vez. Esse modo de gravação ajuda quando você deseja usar expressões condicionais e não pode usar o MRSC por algum motivo ou quando precisa realizar transações. Essas expressões não são possíveis, a menos que você saiba que está agindo com base nos dados mais recentes, então elas exigem o envio de todas as solicitações de gravação para uma única região que tenha os dados mais recentes.

Ao usar uma tabela MRSC, você pode optar por geralmente gravar em uma região por conveniência. Por exemplo, isso pode ajudar a minimizar a construção de sua infraestrutura além do DynamoDB. O modo de gravação ainda seria de gravação em qualquer região, porque com o MRSC você poderia gravar com segurança em qualquer região a qualquer momento, sem se preocupar com a resolução de conflitos que faria com que as tabelas do MREC optassem por gravar em uma região.

Eventualmente, operações de leitura consistentes podem ir para qualquer uma das regiões de réplica para obter latências mais baixas. As operações de leitura altamente consistentes devem ir para a única região primária.

Modo de gravação primário único nas tabelas globais do DynamoDB.

Às vezes, é necessário alterar a região ativa em resposta a uma falha regional, conforme discutido posteriormente. Alguns usuários alteram a região atualmente ativa regularmente, como a implementação de uma follow-the-sunimplantação. Isso coloca a região ativa perto da geografia que tem mais atividade (geralmente onde é diurno, daí o nome), o que resulta nas operações de leitura e gravação de menor latência. Ele também tem a vantagem de chamar o código que muda de região diariamente e garantir que ele seja bem testado antes de qualquer recuperação de desastres.

As regiões passivas podem manter uma infraestrutura reduzida em torno do DynamoDB, que é construída somente se ela se tornar a região ativa. Este guia não aborda a luz piloto e os designs de espera quente. Para obter mais informações, você pode ler a postagem do blog Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby.

Usar o modo de gravação em uma região funciona bem quando você usa tabelas globais para operações de leitura distribuídas globalmente e de baixa latência. Um exemplo é uma grande empresa de mídia social que precisa ter os mesmos dados de referência disponíveis em todas as regiões do mundo. Eles não atualizam os dados com frequência, mas quando o fazem, gravam em apenas uma região para evitar possíveis conflitos de gravação. As operações de leitura sempre são permitidas em qualquer região.

Como outro exemplo, considere a empresa de serviços financeiros discutida anteriormente que implementou o cálculo diário de reembolso. Eles usavam o modo de gravação em qualquer região para calcular o saldo, mas o modo de gravação em uma região para rastrear pagamentos. Esse trabalho requer transações, que não são suportadas nas tabelas MRSC, então funciona melhor com uma tabela MREC separada e gravação em um modo de região.