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á.
# 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`.
**-- identificador de instância de banco de dados de `destino`**
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. É possível 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"
}
}
```