O banco de dados de uma empresa é executado em uma instância de banco de dados Amazon RDS for MySQL na região us-east-1. Eles devem disponibilizar os mesmos dados para clientes na Europa com latência mínima e sem dados desatualizados. Tanto os clientes dos EUA quanto os europeus devem ser capazes de fazer gravações, e as gravações feitas por uma região devem ser visíveis na outra em tempo real. Qual solução satisfará esses requisitos?

A opção correta atende a todos os requisitos: baixa latência, sem dados desatualizados e gravações em tempo real em ambas as regiões. A criação de uma réplica de leitura do Aurora a partir do RDS existente permite uma migração para o Aurora com tempo de inatividade mínimo. A promoção da réplica para um cluster autônomo é um passo necessário para usar o Aurora Global Database. Adicionar eu-west-1 como região secundária e habilitar o encaminhamento de gravação no Aurora Global Database garante que as gravações feitas em qualquer região sejam replicadas e visíveis na outra em tempo real, mantendo a consistência e baixa latência. As opções incorretas falham por diferentes motivos: Adicionar uma réplica entre regiões do RDS e configurar a replicação de gravações de volta para o primário não é uma funcionalidade nativa do RDS para replicação multi-mestre ativa-ativa e pode levar a problemas de consistência e latência. Copiar um snapshot e configurar a replicação lógica do MySQL é mais complexo, pode ter maior latência e não oferece o encaminhamento de gravação nativo do Aurora Global Database. Converter a instância RDS diretamente para Aurora e adicionar a região secundária não considera a necessidade de migrar os dados existentes de forma eficiente e sem interrupção inicial, além de não ser a forma mais direta de migração para o Aurora Global Database a partir de um RDS MySQL existente.