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à.
# Amazon DocumentDB Disponibilità e replica elevate
Puoi ottenere disponibilità elevata e scalabilità di lettura in Amazon DocumentDB (con compatibilità con MongoDB) utilizzando istanze di replica. Un singolo cluster Amazon DocumentDB supporta una singola istanza primaria e fino a 15 istanze di replica. Queste istanze possono essere distribuite tra le zone di disponibilità all'interno della regione del cluster. L'istanza primaria accetta il traffico in lettura e in scrittura, mentre le istanze di replica accettano solo richieste di lettura.
Il volume cluster si compone di più copie dei dati per il cluster. Tuttavia, i dati nel volume del cluster sono rappresentati come un unico volume logico nell'istanza principale e nelle repliche di Amazon DocumentDB nel cluster. Le istanze di replica sono consistenti finali. Restituiscono risultati di query con un ritardo di replica minimo, generalmente inferiore a 100 millisecondi dopo che l'istanza primaria ha scritto un aggiornamento. Il ritardo di replica varia in base alla velocità di modifica del database. In altre parole, nei periodi in cui si verificano numerose operazioni di scrittura nel database, potresti riscontrare un aumento del ritardo di replica.
## Dimensionamento della lettura
Le repliche di Amazon DocumentDB funzionano bene per il ridimensionamento della lettura perché sono completamente dedicate alle operazioni di lettura sul volume del cluster. Le operazioni di lettura sono gestite dall'istanza primaria. Il volume del cluster è condiviso tra tutte le istanze del cluster. Pertanto, non è necessario replicare e conservare una copia dei dati per ogni replica di Amazon DocumentDB.
## Elevata disponibilità
Quando crei un cluster Amazon DocumentDB, a seconda del numero di zone di disponibilità nel gruppo di sottoreti (devono essercene almeno due), Amazon DocumentDB effettua il provisioning delle istanze nelle zone di disponibilità. Quando crei istanze nel cluster, Amazon DocumentDB le distribuisce automaticamente tra le zone di disponibilità in un gruppo di sottoreti per bilanciare il cluster. Questa azione impedisce inoltre che tutte le istanze si trovino nella stessa zona di disponibilità.
**Esempio**
Per illustrare il punto, considera un esempio in cui crei un cluster con un gruppo di sottoreti con tre zone di disponibilità:, e. *AZ1*AZ2*AZ3***
Una volta creata, la prima istanza all'interno del cluster si trova in una delle zone di disponibilità. In questo esempio, è in. *AZ1* La seconda istanza creata è un'istanza di replica e si trova, ad esempio *AZ2*, in una delle altre due zone di disponibilità. La terza istanza creata è un'istanza di replica e si trova nella zona di disponibilità rimanente,. *AZ3* Se crei più istanze, queste sono distribuite tra le zone di disponibilità in modo da ottenere il bilanciamento del cluster.
Se si verifica un errore nell'istanza principale (AZ1), viene attivato un failover e una delle repliche esistenti viene promossa a principale. Quando la vecchia unità primaria viene ripristinata, diventa una replica nella stessa zona di disponibilità in cui era stata fornita (). AZ1 Quando effettui il provisioning di un cluster a tre istanze, Amazon DocumentDB continua a conservare quel cluster a tre istanze. Amazon DocumentDB gestisce automaticamente il rilevamento, il failover e il ripristino degli errori delle istanze senza alcun intervento manuale.
Quando Amazon DocumentDB esegue un failover e ripristina un'istanza, l'istanza recuperata rimane nella zona di disponibilità in cui era stata originariamente fornita. Tuttavia, il ruolo dell'istanza potrebbe cambiare da primaria a replica. Questa operazione viene eseguita per evitare lo scenario in cui una serie di failover provoca il posizionamento di tutte le istanze nella stessa zona di disponibilità.
È possibile specificare le repliche di Amazon DocumentDB come destinazioni di failover. In altre parole, se l'istanza primaria fallisce, la replica Amazon DocumentDB specificata o la replica di un livello viene promossa all'istanza principale. Si verifica una breve interruzione durante la quale le richieste di lettura e scrittura inviate all'istanza primaria falliscono con un'eccezione. Se il tuo cluster Amazon DocumentDB non include alcuna replica di Amazon DocumentDB, quando l'istanza principale si guasta, viene ricreata. La promozione di una replica di Amazon DocumentDB è molto più rapida rispetto alla ricreazione dell'istanza principale.
Per scenari ad alta disponibilità, consigliamo di creare una o più repliche di Amazon DocumentDB. Queste repliche devono appartenere alla stessa classe di istanza dell'istanza principale e in zone di disponibilità diverse per il cluster Amazon DocumentDB.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Comprendere la tolleranza agli errori del cluster Amazon DocumentDB](db-cluster-fault-tolerance.md)
+ [Failover di Amazon DocumentDB](failover.md)
+ [Controllo della destinazione del failover](failover.md#failover-target_control)
### Alta disponibilità con cluster globali
Per un'elevata disponibilità su più piattaforme Regioni AWS, puoi configurare cluster [globali di Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). Ogni cluster globale si estende su più regioni, consentendo letture globali a bassa latenza e disaster recovery in caso di interruzioni su un. Regione AWS Amazon DocumentDB gestisce automaticamente la replica di tutti i dati e gli aggiornamenti dalla regione principale a ciascuna delle regioni secondarie.
## Aggiunta di repliche di
L'istanza primaria è la prima istanza aggiunta al cluster. Ogni istanza aggiunta dopo la prima è un'istanza di replica. Un cluster può avere fino a 15 istanze di replica oltre a quella principale.
Quando si crea un cluster utilizzando il Console di gestione AWS, contemporaneamente viene creata automaticamente un'istanza primaria. Per creare una replica nello stesso momento in cui viene creato il cluster e l'istanza primaria, scegli **Create replica in different zone (Crea replica in una zona diversa)**. Per ulteriori informazioni, consulta la fase 4.d in [Creazione di un cluster Amazon DocumentDB](db-cluster-create.md). Per aggiungere altre repliche a un cluster Amazon DocumentDB, consulta. [Aggiungere un'istanza Amazon DocumentDB a un cluster](db-instance-add.md)
Quando si utilizza il AWS CLI per creare un cluster, è necessario creare in modo esplicito le istanze primarie e di replica. Per ulteriori informazioni, consulta la sezione «Utilizzo di AWS CLI" nei seguenti argomenti:
+ [Creazione di un cluster Amazon DocumentDB](db-cluster-create.md)
+ [Aggiungere un'istanza Amazon DocumentDB a un cluster](db-instance-add.md)
# 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"
}
}
```
## Ritardo di replica
Il ritardo di replica è in genere pari o inferiore a 50 ms. I motivi più comuni dell'aumento del ritardo di replica sono:
+ Una velocità di scrittura elevata sul sistema primario che fa sì che le repliche di lettura rimangano inferiori rispetto a quelle primarie.
+ Conflitto sulle repliche di lettura tra query a esecuzione prolungata (ad esempio, scansioni sequenziali di grandi dimensioni, query di aggregazione) e replica di scrittura in entrata.
+ Numero molto elevato di query simultanee sulle repliche di lettura.
Per ridurre al minimo il ritardo nella replica, prova queste tecniche di risoluzione dei problemi:
+ Se hai una velocità di scrittura o un utilizzo elevato della CPU, ti consigliamo di scalare verso l'alto le istanze del cluster.
+ Se sono presenti query di lunga durata sulle repliche di lettura e aggiornamenti molto frequenti dei documenti interrogati, è consigliabile modificare le query di lunga durata o eseguirle sulla replica primaria/di scrittura per evitare conflitti sulle repliche di lettura.
+ Se è presente un numero molto elevato di query simultanee o un elevato utilizzo della CPU solo sulle repliche di lettura, un'altra opzione consiste nel ridimensionare il numero di repliche di lettura per distribuire il carico di lavoro.
+ Poiché il ritardo di replica è il risultato di un'elevata velocità di scrittura e di query a esecuzione prolungata, si consiglia di risolvere il problema del ritardo di replica utilizzando la metrica CW in combinazione con lo slow query logger e/metrics. DBCluster ReplicaLagMaximum `WriteThroughput` `WriteIOPS`
In generale, è consigliabile che tutte le repliche siano dello stesso tipo di istanza, in modo che un failover del cluster non provochi un peggioramento delle prestazioni.
Se si sceglie tra la scalabilità verticale e quella orizzontale (ad esempio sei istanze più piccole anziché tre istanze più grandi), in genere consigliamo di provare a scalare prima (istanze più grandi) prima di eseguire la scalabilità orizzontale, in quanto si otterrà una cache di buffer più grande per istanza DB.
In modo proattivo, dovresti impostare un allarme di ritardo nella replica e impostarne la soglia su un valore che ritieni sia il limite superiore per indicare il ritardo (o «obsoleto») dei dati sulle istanze di replica prima che inizino a influire sulla funzionalità dell'applicazione. In generale, consigliamo di superare la soglia di ritardo di replica per diversi punti dati prima dell'invio di allarmi, a causa di carichi di lavoro transitori.
**Nota**
Inoltre, si consiglia di impostare un altro allarme per i ritardi di replica superiori a 10 secondi. Se superi questa soglia per più punti dati, ti consigliamo di scalare le istanze o ridurre il throughput di scrittura sull'istanza principale.