Processos de evacuação

Caso isso aconteça com uma tabela MRSC, não há nada de especial que você precise fazer. As tabelas MRSC comportam um objetivo de ponto de recuperação (RPO) de zero. Todas as operações de gravação bem-sucedidas feitas na tabela MRSC na região offline estarão disponíveis em todas as outras tabelas da região, portanto, não há nenhuma lacuna possível nos dados, mesmo que a região fique totalmente offline sem aviso prévio. Os negócios podem continuar usando réplicas localizadas em outras regiões.

Se isso acontecer com uma tabela MREC, todas as operações de gravação na região A que ainda não foram propagadas serão mantidas e propagadas depois que a região A voltar a ficar on-line. As operações de gravação não serão perdidas, mas a propagação será adiada indefinidamente.

A aplicação decidirá como proceder nesse caso. Para a continuidade dos negócios, talvez seja necessário prosseguir para a nova região primária B. No entanto, se um item na região B receber uma atualização enquanto houver uma propagação pendente de uma operação de gravação para esse item da região A, a propagação será suprimida no modelo último gravador vence. Qualquer atualização na região B pode suprimir uma solicitação de gravação recebida.

Com o modo de gravação em qualquer região, as leituras e gravações podem continuar na região B, confiando que os itens na região A serão, em algum momento, propagados para a região B, e considerando a possibilidade de haver itens perdidos até que a região A volte a ficar on-line. Quando possível, como em operações de gravação idempotentes, você deve considerar o reprocessamento do tráfego de gravação recente (por exemplo, usando uma fonte de eventos upstream) para preencher a lacuna de quaisquer operações de gravação potencialmente ausentes e permitir que a resolução de conflitos do tipo última gravação prevalece suprima a eventual propagação da operação de gravação de entrada.

Com os outros modos de gravação, você deve considerar até que ponto o trabalho pode continuar com uma visão de mundo ligeiramente desatualizada. Uma pequena duração das operações de gravação, conforme monitoradas por ReplicationLatency, será perdida até que a região A volte a ficar on-line. Os negócios podem prosseguir? Em alguns casos de uso, sim, mas, em outros, talvez não seja possível sem mecanismos adicionais de mitigação.

Por exemplo, imagine que você precise manter um saldo de crédito disponível sem interrupções, mesmo após uma interrupção total na região. Você pode dividir o saldo em dois itens diferentes: um hospedado na região A e outro na região B, cada um começando com metade do saldo disponível. Isso usa o modo de gravação em sua região. As atualizações transacionais processadas em cada região são gravadas com base na cópia local do saldo. Se a região A ficar totalmente off-line, o trabalho ainda poderá prosseguir com o processamento de transações na região B, e as operações de gravação serão limitadas à parte do saldo mantida na região B. Dividir o saldo dessa forma introduz complexidades quando o saldo fica baixo ou o crédito precisa ser reajustado, mas fornece um exemplo de recuperação segura dos negócios, mesmo com operações de gravação pendentes e incertas.

Em outro exemplo, imagine que você está capturando dados de formulários da web. Você pode usar o Controle de Simultaneidade Otimista (OCC) para atribuir versões aos itens de dados e incorporar a versão mais recente ao formulário da web como um campo oculto. Em cada envio, a operação de gravação será bem-sucedida somente se a versão no banco de dados ainda corresponder à versão com a qual o formulário foi criado. Se as versões não corresponderem, o formulário da web poderá ser atualizado (ou mesclado cuidadosamente) com base na versão atual no banco de dados, e o usuário poderá prosseguir novamente. O modelo OCC geralmente protege contra a substituição e a produção de uma nova versão dos dados por outro cliente, mas também pode ajudar durante um failover, quando um cliente pode encontrar versões mais antigas dos dados. Vamos imaginar que você está usando o carimbo de data/hora como a versão. O formulário foi gerado primeiro na região A às 12:00. Após o failover, ao tentar gravar na região B, o sistema descobre que a versão mais recente no banco de dados é das 11:59. Nesse cenário, o cliente pode aguardar até a versão das 12h ser propagada para a região B, depois gravar em cima dessa versão, ou se basear na das 11h59 para criar uma versão das 12h01 (que, depois de ser gravada, vai suprimir a versão recebida após a recuperação da região A).

Como um terceiro exemplo, uma empresa de serviços financeiros mantém dados sobre contas de clientes e suas transações financeiras em um banco de dados do DynamoDB. Em caso de interrupção completa da região A, a empresa quer garantir que toda atividade de gravação relacionada às contas esteja totalmente disponível na região B, ou deseja colocar em quarentena suas contas como incompletas até que a região A voltar a ficar on-line. Em vez de pausar toda a atividade comercial, a empresa decidiu pausar os negócios apenas na pequena fração de contas que determinaram ter transações não propagadas. Para isso, a empresa usou uma terceira região, que chamaremos de região C. Antes de processar qualquer operação de gravação na região A, a empresa incluiu um resumo sucinto dessas operações pendentes (por exemplo, uma nova contagem de transações para uma conta) na região C. Esse resumo foi suficiente para que a região B determinasse se sua visualização estava totalmente atualizada. Essa ação bloqueou efetivamente a conta desde o momento da gravação na região C até a região A aceitar as operações de gravação e a região B recebê-las. Os dados na região C não foram usados, exceto como parte de um processo de failover, após o qual a região B conseguiu comparar seus dados com a região C para verificar se alguma conta estava desatualizada. Essas contas serão colocadas em quarentena até que a recuperação da região A propague os dados parciais para a região B. Se a região C falhar, uma nova região D poderá ser criada para ser usada em seu lugar. Os dados na região C eram muito transitórios e, após alguns minutos, a região D já teria um registro suficientemente atualizado das operações de gravação em andamento para ser totalmente útil. Se a região B falhasse, a região A poderia continuar aceitando solicitações de gravação em cooperação com a região C. Essa empresa estava disposta a aceitar gravações com latência mais alta (em duas regiões: C e, depois, A) e teve a sorte de ter um modelo de dados em que o estado de uma conta pudesse ser resumido sucintamente.