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:
+ [Entender a tolerância a falhas de cluster do Amazon DocumentDB](db-cluster-fault-tolerance.md)
+ [Failover do Amazon DocumentDB](failover.md)
+ [Controlar o destino de failover](failover.md#failover-target_control)
### Alta disponibilidade com clusters globais
Para obter alta disponibilidade em várias Regiões da AWS, é possível configurar [clusters globais do Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). 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 Console de gerenciamento da AWS, 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 **Criar réplica em zona diferente**. Para obter mais informações, consulte a etapa 4.d em [Criar um cluster do Amazon DocumentDB](db-cluster-create.md). Para adicionar mais réplicas a um cluster do Amazon DocumentDB, consulte [Adicionar uma instância do Amazon DocumentDB a um cluster](db-instance-add.md).
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:
+ [Criar um cluster do Amazon DocumentDB](db-cluster-create.md)
+ [Adicionar uma instância do Amazon DocumentDB a um cluster](db-instance-add.md)
# Failover do Amazon DocumentDB
Em alguns casos, como determinados tipos de manutenção programada, ou no caso improvável de uma falha de nó primário ou zona de disponibilidade, o Amazon DocumentDB (compativel com MongoDB) detecta a falha e substitui o nó primário. Durante um failover, o tempo de gravação é minimizado. Isso ocorre porque a função do nó primário fará failover em uma das réplicas de leitura, em vez de ter que criar e provisionar um novo nó primário. A detecção de falhas e a promoção de réplica garantem que você possa continuar a gravar no novo primário assim que a promoção estiver concluída.
Para que o failover funcione, o cluster deve ter pelo menos duas instâncias — uma instância principal e pelo menos uma réplica.
**nota**
Esse tópico se aplica somente aos clusters baseados em instâncias originais do Amazon DocumentDB. Ele não se aplica aos clusters elásticos ou globais.
## Controlar o destino de failover
O Amazon DocumentDB fornece níveis de failover para controlar qual instância de réplica é promovida a instância principal quando ocorre um failover.
**Níveis de failover**
Cada instância de réplica é associada a um nível de failover (0–15). Quando ocorre um failover devido à manutenção ou a uma falha de hardware improvável, a instância principal executa failover em uma réplica com o maior nível de prioridade (o nível numerado mais baixo). Se várias réplicas tiverem o mesmo nível de prioridade, a principal executará failover na réplica do nível que é mais próximo em tamanho da prévia principal.
Ao definir o nível de failover de um grupo de réplicas selecionadas como `0` (a prioridade mais alta), você pode garantir que um failover promova uma das réplicas desse grupo. Você pode impedir efetivamente que as réplicas específicas sejam promovidas a principal no caso de um failover, atribuindo um nível de baixa prioridade (número alto) a essas réplicas. Isso é útil em casos em que réplicas específicas são muito usadas por uma aplicação, e o failover em um deles teria um impacto negativo em uma aplicação crítica.
Você pode definir o nível de failover de uma instância ao criá-la ou posteriormente, modificando-o. Definir um nível de failover da instância modificando a instância não aciona um failover. Para obter mais informações, consulte os tópicos a seguir:
+ [Adicionar uma instância do Amazon DocumentDB a um cluster](db-instance-add.md)
+ [Modificar uma instância do Amazon DocumentDB](db-instance-modify.md)
Ao iniciar manualmente um failover, você tem dois meios de controlar qual instância de réplica é promovida a principal: o nível de failover, conforme descrito anteriormente, e o parâmetro `--target-db-instance-identifier`.
**--`target-db-instance-identifier`**
Para testar, você pode forçar um evento de failover usando a operação `failover-db-cluster`. Você pode usar o parâmetro `--target-db-instance-identifier` para especificar qual réplica deve ser promovida à principal. O uso do parâmetro `--target-db-instance-identifier` substitui o nível de prioridade de failover. Se você não especificar o parâmetro `--target-db-instance-identifier`, o failover primário estará de acordo com o nível de prioridade de failover.
## O que acontece durante um failover
O failover é automaticamente controlado pelo Amazon DocumentDB para que suas aplicações possam retomar operações de banco de dados o mais rápido possível e sem intervenção administrativa.
+ Se você tiver uma instância da réplica do Amazon DocumentDB na mesma zona de disponibilidade ou em outra, ao fazer o failover: o Amazon DocumentDB alterará o registro de nome canônico (CNAME) da instância para apontar para a réplica íntegra que, por sua vez, é promovida e se torna a nova principal. Normalmente, o failover é concluído em 30 segundos do início ao fim.
+ Se você não tiver uma instância de réplica do Amazon DocumentDB (por exemplo, um cluster de instância única): o Amazon DocumentDB tentará criar uma instância na mesma zona de disponibilidade que a instância original. O melhor possível é feito para realizar essa substituição da instância original, mas pode ser que isso não tenha êxito se, por exemplo, ocorrer um problema que afete amplamente a zona de disponibilidade.
Sua aplicação deve tentar novamente fazer as conexões do banco de dados em caso de uma perda de conexão.
## Testar o failover
Um failover para um cluster promove uma das réplicas do Amazon DocumentDB (instâncias somente leitura) no cluster para ser a instância primária (o gravador do cluster).
Quando a instância principal falhar, o Amazon DocumentDB executará failover automaticamente em uma réplica do Amazon DocumentDB, se houver. Você pode forçar um failover quando quiser simular uma falha de uma instância principal para testes. Cada instância em um cluster tem seu próprio endereço de endpoint. Portanto, você precisa limpar e restabelecer as conexões existentes que usam os endereços de endpoint quando o failover é concluído.
Para forçar um failover, use a operação `failover-db-cluster` com esses parâmetros.
+ `--db-cluster-identifier`—Obrigatório. O nome do cluster no qual executar failover.
+ `--target-db-instance-identifier`: opcional. O nome da instância a ser promovida à instância principal.
**Example**
A operação a seguir força um failover do cluster `sample-cluster`. Ela não especifica qual instância se tornará a nova instância principal, portanto o Amazon DocumentDB escolhe a instância de acordo com a prioridade do nível de failover.
Para Linux, macOS ou Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster
```
Para Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster
```
A operação a seguir força um failover do cluster `sample-cluster`, especificando a `sample-cluster-instance` que será promovida à função principal. (Observe `"IsClusterWriter": true` na saída.)
Para Linux, macOS ou Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-cluster-instance
```
Para Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster ^
--target-db-instance-identifier sample-cluster-instance
```
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"DBCluster": {
"HostedZoneId": "Z2SUY0A1719RZT",
"Port": 27017,
"EngineVersion": "3.6.0",
"PreferredMaintenanceWindow": "thu:04:05-thu:04:35",
"BackupRetentionPeriod": 1,
"ClusterCreateTime": "2018-06-28T18:53:29.455Z",
"AssociatedRoles": [],
"DBSubnetGroup": "default",
"MasterUsername": "master-user",
"Engine": "docdb",
"ReadReplicaIdentifiers": [],
"EarliestRestorableTime": "2018-08-21T00:04:10.546Z",
"DBClusterIdentifier": "sample-cluster",
"ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"DBClusterMembers": [
{
"DBInstanceIdentifier": "sample-cluster-instance",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": true
},
{
"DBInstanceIdentifier": "sample-cluster-instance-00",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
},
{
"DBInstanceIdentifier": "sample-cluster-instance-01",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
}
],
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1a"
],
"DBClusterParameterGroup": "default.docdb3.6",
"Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"IAMDatabaseAuthenticationEnabled": false,
"AllocatedStorage": 1,
"LatestRestorableTime": "2018-08-22T21:57:33.904Z",
"PreferredBackupWindow": "00:00-00:30",
"StorageEncrypted": false,
"MultiAZ": true,
"Status": "available",
"DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-12345678"
}
],
"DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ"
}
}
```
## Lag 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 da aplicação. Em geral, aconselhamos que o limite de atraso de replicação seja excedido para vários pontos de dados antes do alarme, devido a workloads 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.