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 um aplicativo, e o failover em um deles teria um impacto negativo em um aplicativo crítico.
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:
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 seus aplicativos 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.
Seu aplicativo 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.
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"
}
}