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 ha le dimensioni più vicine 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:
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 record del nome canonico (CNAME) dell'istanza in modo che punti alla replica integra, che a sua volta viene promossa a 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.
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'output di questa operazione è simile al seguente (JSONformato).
{
"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"
}
}