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, ad esempio per alcuni tipi di manutenzione programmata o nel caso poco probabile di un errore in un nodo primario o in una zona di disponibilità, Amazon DocumentDB (con compatibilità con MongoDB) rileva l'errore e sostituisce il nodo primario. 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.
Perché il failover sia efficace, il cluster deve contenere almeno due istanze, una istanza primaria e almeno un'istanza di replica.
Controllo della destinazione di failover
Amazon DocumentDB fornisce livelli di failover con cui controllare quale istanza di replica promuovere a istanza 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 a causa di operazioni di manutenzione o, in casi rari, di un guasto all'hardware, l'istanza primaria esegue il failover su una replica con la massima priorità (il numero di livello più basso). Se più repliche hanno stesso livello di priorità, l'istanza primaria esegue il failover su una replica nello stesso livello con le dimensioni più vicine a quelle dell'istanza primaria 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 accade durante un failover
Il failover viene gestito automaticamente da Amazon DocumentDB, in modo che le applicazioni possano riprendere le operazioni database il più rapidamente possibile, senza alcun intervento amministrativo.
-
Se hai un'istanza di replica Amazon DocumentDB nella stessa zona di disponibilità o in un'altra zona di disponibilità durante il failover: Amazon DocumentDB fa in modo che il record di nome canonico (CNAME) dell'istanza punti alla replica integra, che a sua volta viene alzata di livello e impostata come nuova replica primaria. 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 di un cluster promuove una delle repliche di Amazon DocumentDB (istanze di sola lettura) nel cluster a istanza primaria (cluster di scrittura).
esegue automaticamente il failover in una replica Amazon DocumentDB, se disponibile, quando l'istanza primaria non riesce. 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—Opzionale. Il nome dell'istanza da promuovere a istanza primaria.
L'operazione seguente forza un failover del cluster sample-cluster. Non specifica l'istanza da promuovere a nuova istanza primaria, pertanto 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"
}
}