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á.
Comparação das soluções de replicação do Amazon Aurora
A tabela a seguir apresenta uma comparação das três soluções de replicação do Amazon Aurora.
Réplicas do Aurora |
Replicação entre regiões do Aurora |
Bancos de dados globais do Aurora |
|
Fornece alta disponibilidade |
Sim |
Não |
Não |
Fornece recuperação de desastres |
Não |
Sim |
Sim |
Tipo de replicação |
Assíncrona |
Assíncrona |
Assíncrona |
Failover automático |
Sim |
Não |
Não |
Descarrega consultas SELECT |
Sim |
Sim |
Sim |
Pode realizar gravações em réplicas |
Não |
Sim (não recomendado) |
Não |
Proximidade com o cluster primário |
Sempre existe na mesma região que o primário. |
Não pode existir na mesma região que o primário. |
Não pode existir na mesma região que o primário. |
Lag de replicação |
Normalmente, muito menor que 100 milissegundos |
Depende do volume de transações. Normalmente, alguns segundos para a maioria dos sistemas. |
Normalmente, é menos que 1 segundo. |
Considerações sobre custos |
Pague somente por nós adicionais de instâncias de bancos de dados. |
Você paga taxas padrão do Aurora por instâncias, armazenamento, transferência de dados entre regiões, armazenamento de backup e E/S de gravação replicadas entre a região primária e cada região secundária. |
Você paga taxas padrão do Aurora por instâncias, armazenamento, transferência de dados entre regiões, armazenamento de backup e E/S de gravação replicadas entre a região primária e cada região secundária. |
Número de réplicas aceitas |
15 na mesma região |
Até cinco clusters de banco de dados secundários em diferentes regiões da edição do Aurora compatível com MySQL. (A edição do Aurora compatível com PostgreSQL não é compatível com réplicas entre regiões.) |
Até cinco clusters de banco de dados secundários em diferentes regiões. |
Tempo de provisionamento |
Menos de cinco minutos, independentemente do tamanho do banco de dados. |
Depende do tamanho do banco de dados, pois a criação da réplica exige que a cópia inteira do banco de dados seja replicada nas regiões secundárias. |
Depende do tamanho do banco de dados, pois a criação da réplica exige que a cópia inteira do banco de dados seja replicada nas regiões secundárias. |
Ao decidir qual opção implementar, use as seguintes diretrizes:
-
Se você precisar de alta disponibilidade do seu cluster do Aurora, use as réplicas do Aurora. O Aurora promoverá automaticamente uma das réplicas do Aurora se a instância primária falhar. As réplicas do Aurora também são ótimas para escalabilidade horizontal de suas workloads de leitura. O gerenciador de conexões do Aurora distribuirá automaticamente a workload entre várias réplicas do Aurora dentro da mesma Região da AWS, usando o endpoint de leitura comum.
-
Se você estiver buscando uma recuperação de desastres (DR) entre regiões, use os bancos de dados globais do Aurora. Com os bancos de dados globais do Aurora, você pode abranger várias Regiões da AWS para permitir leituras locais rápidas e DR. Você pode usar uma região secundária como opção de backup caso precise se recuperar rapidamente de uma degradação ou interrupção regional. Um banco de dados em uma região secundária pode ser promovido a recursos completos de leitura/gravação em menos de um minuto.
-
As réplicas do Aurora entre regiões atendem a alguns casos de uso. Primeiro, se você precisar de uma cópia entre regiões do seu banco de dados do Aurora e não puder usar um banco de dados global devido a algumas de suas limitações, poderá usar réplicas do Aurora entre regiões. Segundo, se você precisar migrar do Amazon Relational Database Service (Amazon RDS) para MySQL para a edição do Aurora compatível com MySQL, você pode configurar uma réplica do Aurora MySQL.
