Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Failover di Amazon DocumentDB
In alcuni casi, come alcuni tipi di manutenzione pianificata o nell'improbabile eventualità di un guasto di un nodo primario o di una zona di disponibilità, Amazon DocumentDB (compatibile con MongoDB) rileva l'errore e sostituisce il nodo principale. Durante un failover, il tempo di inattività di scrittura è ridotto al minimo. Questo perché il ruolo del nodo principaleesegue il failover in una delle repliche di lettura invece di creare ed eseguire il provisioning di un nuovo nodo principale. Questa individuazione degli errori e promozione delle repliche garantisce la possibilità di ricominciare a scrivere nel nuovo nodo primario non appena la promozione è terminata.
Affinché il failover funzioni, il cluster deve avere almeno due istanze: un'istanza primaria e almeno un'istanza di replica.
**Nota**
Questo argomento si applica solo ai cluster originali basati su istanze di Amazon DocumentDB. Non si applica ai cluster elastici o globali.
## Controllo della destinazione del failover
Amazon DocumentDB fornisce livelli di failover come mezzo per controllare quale istanza di replica viene promossa a primaria quando si verifica un failover.
**Livelli di failover**
Ogni istanza di replica è associata a un livello di failover (0-15). Quando si verifica un failover dovuto alla manutenzione o a un improbabile errore hardware, l'istanza principale esegue il failover su una replica con la priorità più alta (il livello con il numero più basso). Se più repliche hanno lo stesso livello di priorità, l'unità principale esegue il failover sulla replica di quel livello, che è la più vicina in termini di dimensioni alla replica principale precedente.
Impostando il livello di failover per un gruppo di repliche selezionate su `0` (priorità massima), puoi assicurare che un failover promuoverà una delle repliche in tale gruppo. Inoltre, per evitare che delle repliche specifiche vengano promosse a istanza primaria in caso di failover, puoi assegnare un livello di priorità basso (numero alto) a queste repliche. Questa funzione è utile nei casi in cui repliche specifiche siano particolarmente utilizzate da un'applicazione e il failover di una di esse potrebbe influire negativamente su un'applicazione critica.
Puoi impostare il livello di failover di un'istanza quando la crei o puoi modificarlo successivamente. Il failover non viene attivato se imposti il livello di failover di un'istanza modificando l'istanza. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Aggiungere un'istanza Amazon DocumentDB a un cluster](db-instance-add.md)
+ [Modifica di un'istanza Amazon DocumentDB](db-instance-modify.md)
Quando avvii manualmente un failover, puoi controllare quale istanza di replica viene promossa a primaria in due modi: i livelli di failover descritti in precedenza e il parametro `--target-db-instance-identifier`.
**--`target-db-instance-identifier`**
Per il testing, puoi forzare un evento di failover utilizzando l'operazione `failover-db-cluster`. Puoi utilizzare il parametro `--target-db-instance-identifier` per specificare quale replica promuovere a istanza primaria. L'utilizzo del parametro `--target-db-instance-identifier` sostituisce il livello di priorità di failover. Se non specifichi il parametro `--target-db-instance-identifier`, il failover primario si conforma al livello di priorità di failover.
## Cosa succede durante un failover
Il failover viene gestito automaticamente da Amazon DocumentDB in modo che le applicazioni possano riprendere le operazioni del database il più rapidamente possibile senza interventi amministrativi.
+ Se hai un'istanza di replica di Amazon DocumentDB nella stessa o in un'altra zona di disponibilità durante il failover: Amazon DocumentDB capovolge il canonical name record (CNAME) dell'istanza in modo che punti alla replica integra, che a sua volta viene promossa a diventare la nuova principale. In genere, l'esecuzione completa dell'intero processo di failover impiega meno di 30 secondi.
+ Se non disponi di un'istanza di replica di Amazon DocumentDB (ad esempio, un cluster a istanza singola): Amazon DocumentDB tenterà di creare una nuova istanza nella stessa zona di disponibilità dell'istanza originale. Questa sostituzione dell'istanza originale viene eseguita in base al tentativo migliore e potrebbe non avvenire, ad esempio, se si verifica un problema che interessa in qualche modo la zona di disponibilità.
L'applicazione deve provare a ristabilire le connessioni al database in caso di perdita della connessione.
## Verifica del Failover
Un failover per un cluster promuove una delle repliche di Amazon DocumentDB (istanze di sola lettura) nel cluster come istanza principale (lo scrittore del cluster).
In caso di errore dell'istanza primaria, Amazon DocumentDB esegue automaticamente il failover su una replica di Amazon DocumentDB, se esistente. Puoi forzare un failover per simulare un guasto di un'istanza primaria per scopi di testing. Ogni istanza in un cluster ha il proprio indirizzo di endpoint. Pertanto, è necessario eliminare e ristabilire tutte le connessioni esistenti che utilizzano tali indirizzi una volta completato il failover..
Per forzare un failover, utilizza l'operazione `failover-db-cluster` con questi parametri.
+ `--db-cluster-identifier`: obbligatorio. Il nome del cluster di cui eseguire il failover.
+ `--target-db-instance-identifier`—Facoltativo. Il nome dell'istanza da promuovere a istanza primaria.
**Example**
L'operazione seguente forza un failover del cluster `sample-cluster`. Non specifica quale istanza creare la nuova istanza primaria, quindi Amazon DocumentDB sceglie l'istanza in base alla priorità del livello di failover.
Per Linux, macOS o Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster
```
Per Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster
```
L'operazione seguente forza un failover del cluster `sample-cluster`, specificando che `sample-cluster-instance` deve essere promosso al ruolo primario. Annota il valore `"IsClusterWriter": true` nell'output.
Per Linux, macOS o Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-cluster-instance
```
Per Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster ^
--target-db-instance-identifier sample-cluster-instance
```
L'aspetto dell'output di questa operazione è simile al seguente (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"
}
}
```