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á.
Alta disponibilidade e replicação do Amazon DocumentDB
Você pode obter alta disponibilidade e escalabilidade de leitura no Amazon DocumentDB (compatível com MongoDB) usando instâncias de réplica. Um único cluster do Amazon DocumentDB oferece suporte a uma única instância primária e até 15 instâncias de réplica. Essas instâncias podem ser distribuídas em zonas de disponibilidade dentro da região do cluster. A instância principal aceita o tráfego de leitura e de gravação e as instâncias de réplica aceitam somente solicitações de leitura.
O volume do cluster é composto por várias cópias dos dados do cluster. Contudo, os dados no volume do cluster são representados como um volume lógico e único para a instância primária e para réplicas do Amazon DocumentDB no cluster. No final, as instâncias de réplica tornam-se consistentes. Elas retornam os resultados da consulta com atraso de réplica mínimo, geralmente muito inferior a 100 milissegundos após a instância principal ter gravado uma atualização. O atraso da réplica varia de acordo com a taxa de mudança no banco de dados. Ou seja, durante os períodos em que um grande número de operações de gravação ocorre para o banco de dados, você pode ver um aumento no atraso da réplica.
Escalabilidade de leitura
As réplicas do Amazon DocumentDB funcionam bem para a escalabilidade de leitura porque são totalmente dedicadas a operações de leitura no seu volume de cluster. As operações de gravação são gerenciadas pela instância principal. O volume do cluster é compartilhado com todas as instâncias em seu cluster. Portanto, você não precisa replicar e manter uma cópia dos dados para cada réplica do Amazon DocumentDB.
Alta disponibilidade
Quando você cria um cluster do Amazon DocumentDB, dependendo do número de zonas de disponibilidade no grupo de sub-redes (deve haver pelo menos duas) o Amazon DocumentDB provisiona instâncias entre as zonas de disponibilidade. Quando você cria instâncias no cluster, o Amazon DocumentDB distribui automaticamente as instâncias entre as zonas de disponibilidade em um grupo de sub-redes para balancear o cluster. Essa ação também impede que todas as instâncias estejam localizadas na mesma zona de disponibilidade.
Exemplo
Para ilustrar, considere um exemplo no qual você criou um cluster que tem um grupo de sub-redes com três zonas de disponibilidade: AZ1, AZ2 e AZ3.
Quando a primeira instância no cluster é criada, é a instância principal e é localizada em uma das zonas de disponibilidade. Neste exemplo, está AZ1. A segunda instância criada é uma instância de réplica e é localizada em uma das outras duas zonas de disponibilidade, digamos, AZ2. A terceira instância criada é uma instância de réplica e está localizada na zona de disponibilidade remanescente, ou seja, a AZ3. Se você criar mais instâncias, elas serão distribuídas entre as zonas de disponibilidade para alcançar o equilíbrio no cluster.
Se ocorrer uma falha na instância principal (AZ1), um failover será acionado, e uma das réplicas existentes será promovida a principal. Quando a instância principal antiga for recuperada, ela se tornará uma réplica na mesma zona de disponibilidade na qual ela foi provisionada (AZ1). Quando você provisiona um cluster de três instâncias, o Amazon DocumentDB continua preservando esse cluster de três instâncias. O Amazon DocumentDB gerencia automaticamente a detecção, o failover e a recuperação de falhas de instância sem qualquer intervenção manual.
Quando o Amazon DocumentDB executar um failover e recuperar uma instância, a instância recuperada permanecerá na zona de disponibilidade na qual ela foi originalmente provisionada. No entanto, a função da instância pode mudar de principal para réplica. Isso impede o cenário em que uma série de failovers pode resultar em todas as instâncias estando na mesma zona de disponibilidade.
Você pode especificar réplicas do Amazon DocumentDB como destinos de failover. Ou seja, se ocorrer uma falha na instância principal, a réplica especificada do Amazon DocumentDB ou a réplica de uma camada será promovida a instância principal. Há uma breve interrupção durante a qual as solicitações de leitura e gravação feitas na instância principal falharão com uma exceção. Se o cluster do Amazon DocumentDB não incluir réplicas do Amazon DocumentDB, quando a instância principal falhar, ela será recriada. Promover uma réplica do Amazon DocumentDB é muito mais rápido do que recriar a instância principal.
Para cenários de alta disponibilidade, recomendamos criar uma ou mais réplicas do Amazon DocumentDB. Elas devem ser da mesma classe de instância que a instância principal em zonas de disponibilidade diferentes para o cluster do Amazon DocumentDB.
Para obter mais informações, consulte as informações a seguir:
Alta disponibilidade com clusters globais
Para obter alta disponibilidade em várias Regiões da AWS, é possível configurar clusters globais do Amazon DocumentDB. Cada cluster global abrange várias regiões, permitindo leituras globais de baixa latência e recuperação de desastres de interrupções em uma Região da AWS. O Amazon DocumentDB lidará automaticamente com a replicação de todos os dados e atualizações da região primária para cada uma das regiões secundárias.
Adicionar réplicas do
A primeira instância adicionada ao cluster é a instância principal. Todas instância adicionada após a primeira instância é uma instância de réplica. Um cluster pode ter até 15 instâncias de réplica, além da instância principal.
Quando você cria um cluster usando o AWS Management Console, uma instância principal é criada automaticamente ao mesmo tempo. Para criar uma réplica ao mesmo tempo em que cria o cluster e a instância principal, escolha Create replica in different zone (Criar réplica em zona diferente). Para obter mais informações, consulte a etapa 4.d em Criação de um cluster Amazon DocumentDB. Para adicionar mais réplicas a um cluster do Amazon DocumentDB, consulte Adicionando uma instância do Amazon DocumentDB a um cluster.
Ao usar a AWS CLI para criar seu cluster, você deve criar explicitamente suas instâncias principal e de réplica. Para obter mais informações, consulte a seção "Usar a AWS CLI" dos seguintes tópicos:
Atraso de replicação
O atraso de replicação geralmente é de 50 ms ou menos. Os motivos mais comuns para aumentar o atraso da réplica são:
-
Uma alta taxa de gravação no primário que faz com que as réplicas de leitura fiquem atrás do primário.
-
Contenção nas réplicas de leitura entre consultas de longa execução (por exemplo, grandes varreduras sequenciais, consultas de agregação) e replicação de gravação recebida.
-
Número muito grande de consultas simultâneas nas réplicas de leitura.
Para minimizar o atraso na replicação, experimente estas técnicas de solução de problemas:
-
Se você tiver uma alta taxa de gravação ou alta utilização da CPU, recomendamos que você aumente a escala verticalmente das instâncias em seu cluster.
-
Se houver consultas de longa duração em suas réplicas de leitura e atualizações muito frequentes dos documentos que estão sendo consultados, considere alterar suas consultas de longa duração ou executá-las na réplica principal/gravação para evitar contenção nas réplicas de leitura.
-
Se houver um número muito grande de consultas simultâneas ou alta utilização da CPU somente nas réplicas de leitura, outra opção é aumentar a escala horizontalmente do número de réplicas de leitura para espalhar a workload.
-
Como o atraso de replicação é resultado de alto throughput de gravação e consultas de longa execução, recomendamos solucionar problemas do atraso de replicação utilizando a métrica DBClusterReplicalAgMaximum CW em combinação com o registrador de consultas lentas e métricas
WriteThroughput/WriteIOPS.
Em geral, recomendamos que todas as réplicas sejam do mesmo tipo de instância, para que um failover de cluster não cause uma degradação no desempenho.
Se você estiver escolhendo entre aumentar a escala verticalmente e aumentar a escala horizontalmente (por exemplo, seis instâncias menores versus três instâncias maiores), geralmente recomendamos tentar aumentar a escala verticalmente primeiro (instâncias maiores) antes de aumentar a escala horizontalmente, pois você obterá um cache de buffer maior por instância de banco de dados.
Proativamente, você deve definir um alarme de atraso de replicação e definir seu limite para um valor que você acha que é o limite superior para o quão longe (ou “obsoleto”) seus dados em instâncias de réplica podem estar antes de começar a afetar a funcionalidade do aplicativo. Em geral, aconselhamos que o limite de atraso de replicação seja excedido para vários pontos de dados antes do alarme, devido a cargas de trabalho transitórias.
nota
Além disso, recomendamos que você defina outro alarme para atrasos de replicação que excedam 10 segundos. Se você ultrapassar esse limite para vários pontos de dados, recomendamos que você aumente a escala verticalmente de suas instâncias ou reduza seu throughput de gravação na instância principal.
