Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive il supporto della disponibilità elevata (affidabilità) in Azure Cosmos DB for NoSQL e illustra sia le zone di disponibilità che il ripristino di emergenza e la continuità aziendale tra aree.
Resilienza dei nodi di calcolo
Azure Cosmos DB gestisce in modo trasparente tutti i dettagli dei singoli nodi di calcolo. Non è necessario preoccuparsi dell'applicazione di patch o delle attività di manutenzione pianificata. Azure Cosmos DB garantisce contratti di servizio per la disponibilità e latenza P99 tramite tutte le operazioni di manutenzione automatica eseguite dal sistema.
Azure Cosmos DB riduce automaticamente le interruzioni delle repliche garantendo almeno tre repliche dei dati in ogni area di Azure per l'account entro un quorum di quattro repliche. Questa garanzia comporta un RTO pari a 0 e un RPO pari a 0 per le interruzioni dei singoli nodi, senza bisogno di modifiche o configurazioni dell'applicazione. Per informazioni su RTO e RPO, vedere Che cosa sono la continuità aziendale, la disponibilità elevata e il ripristino di emergenza?.
Supporto della zona di disponibilità
Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.
Azure Cosmos DB supporta la ridondanza zonale. Quando si abilita la ridondanza della zona, Azure distribuisce le repliche dei dati in più zone di disponibilità, offrendo resilienza ai problemi e alle interruzioni del data center. È possibile abilitare la ridondanza della zona nelle aree di Azure che supportano le zone di disponibilità. Per verificare se l'area supporta le zone di disponibilità, vedere l'elenco delle aree supportate.
È consigliabile usare la ridondanza della zona nelle aree in cui è supportata, in particolare per gli account a singola area.
Ridondanza di zona e account a regione singola
Quando si ha un account Cosmos DB a singola area, è importante essere resilienti ai problemi in una zona di disponibilità. L'abilitazione della ridondanza della zona protegge dalla perdita totale di disponibilità a causa dell'errore di una zona di disponibilità.
Poiché le zone di disponibilità sono fisicamente separate e forniscono alimentazione, rete e raffreddamento distinte, i contratti di servizio di disponibilità per Azure Cosmos DB sono superiori per gli account con ridondanza della zona rispetto agli account che non usano zone di disponibilità.
Ridondanza della zona e account in più aree
Se si dispone di un account con più aree, è possibile abilitare facoltativamente la ridondanza della zona in una o tutte le aree dell'account che supportano le zone di disponibilità. Gli account multi-regione possono ottenere contratti di servizio a disponibilità elevata, e abilitando la ridondanza delle zone puoi migliorare ulteriormente i contratti di servizio di disponibilità complessivi che ottieni in quelle regioni.
Per gli account in più aree, l'impatto della ridondanza della zona sulla disponibilità del database Cosmos DB per NoSQL dipende dal livello di coerenza dell'account e dalle aree con ridondanza della zona abilitata. Consultare la tabella seguente per stimare l'impatto dell'uso delle zone di disponibilità nella configurazione dell'account in più aree:
| Livello di coerenza dell'account | Aree con zone di disponibilità abilitate | Impatto dell'uso delle zone di disponibilità |
|---|---|---|
| Sincrono (assoluta) | Un'area di lettura secondaria | Elevato vantaggio della ridondanza zonale. Offre un valore maggiore perché la perdita di un'area di lettura in questo scenario può influire sulla disponibilità in scrittura. |
| Sincrono (assoluta) | Due o più aree di lettura secondarie | Valore ridotto della ridondanza di zona. Offre un valore marginale perché il sistema può sfruttare il quorum dinamico se un'area di lettura perde la disponibilità, consentendo la continuazione delle scritture. |
| Asincrono (decadimento ristretto o più debole) | Una o più aree di lettura secondarie | Valore ridotto della ridondanza di zona. Offre un valore minimo perché l'SDK fornisce già reindirizzamenti semplici per le letture in caso di errore di un'area di lettura. |
| Qualsiasi | Tutte le aree di scrittura e qualsiasi numero di aree secondarie | Elevato vantaggio della ridondanza zonale. Garantisce una maggiore disponibilità per le operazioni di scrittura in caso di guasti nella zona di disponibilità. |
Costo dell'abilitazione della ridondanza della zona
Le aree in cui è abilitata la ridondanza della zona vengono addebitate a Premium 25%. Tuttavia, il prezzo Premium per le zone di disponibilità è derogato per gli account configurati con scritture in più aree e/o per le raccolte configurate con la modalità di scalabilità automatica.
L'aggiunta di una regione aggiuntiva all'account Cosmos DB solitamente aumenta la fattura esistente di 100% per ogni regione. Tuttavia, esistono piccole variazioni di costo tra le aree.
Per altri dettagli, vedere la pagina dei prezzi.
Miglioramenti del contratto di servizio
Per aumentare la resilienza e la disponibilità di un account Azure Cosmos DB, è possibile implementare un approccio a più livelli, che include:
- Abilitazione della ridondanza della zona.
- Aggiunta di una o più aree aggiuntive.
- Abilitazione delle scritture in più aree.
L'approccio a più livelli protegge l'account in ogni passaggio, dalla disponibilità di 4 9 per una configurazione a singola area senza ridondanza della zona, fino a 4 e metà 9 per una singola area con ridondanza della zona, fino a 5 9 di disponibilità per la configurazione in più aree con l'opzione di scrittura in più aree abilitata.
La tabella seguente contiene un riepilogo dei contratti di servizio per ogni configurazione:
| KPI (Indicatore Chiave di Prestazione) | Scritture in una singola area senza zone di disponibilità | Scritture in una singola area con zone di disponibilità | Multi-area, scritture in una singola area senza zone di disponibilità | Multi-area, scritture in una singola area con zone di disponibilità | Multi-area, scritture in più aree con o senza zone di disponibilità |
|---|---|---|---|---|---|
| Contratto di servizio per la disponibilità in scrittura | 99,99% | 99,995% | 99,99% | 99,995% | 99,999% |
| Contratto di servizio per la disponibilità in lettura | 99,99% | 99,995% | 99,999% | 99,999% | 99,999% |
| Errori di zona: perdita di dati | Perdita di dati | Senza perdita di dati | Senza perdita di dati | Senza perdita di dati | Senza perdita di dati |
| Errori di zona: disponibilità | Perdita di disponibilità | Nessuna perdita di disponibilità | Nessuna perdita di disponibilità | Nessuna perdita di disponibilità | Nessuna perdita di disponibilità |
| Interruzione a livello di area: perdita di dati | Perdita di dati | Perdita di dati | In base al livello di coerenza. Per altre informazioni, vedere Compromessi tra coerenza, disponibilità e prestazioni. | In base al livello di coerenza. Per altre informazioni, vedere Compromessi tra coerenza, disponibilità e prestazioni. | In base al livello di coerenza. Per altre informazioni, vedere Compromessi tra coerenza, disponibilità e prestazioni. |
| Interruzione a livello di area: disponibilità | Perdita di disponibilità | Perdita di disponibilità | Nessuna perdita di disponibilità per errori dell'area di lettura, temporanea per errori dell'area di scrittura | Nessuna perdita di disponibilità per errori dell'area di lettura, temporanea per errori dell'area di scrittura | Nessuna perdita di disponibilità in lettura, perdita temporanea di disponibilità in scrittura nell'area interessata |
| Prezzo (1) | Non applicabile | UR con provisioning x 1,25 | UR con provisioning x N aree | UR con provisioning x 1,25 x N aree (2) | Tariffa di scrittura in più aree x N aree |
1 Per gli account serverless, le UR vengono moltiplicate per un fattore pari a 1,25.
2 Il fattore 1,25 si applica solo alle aree in cui si abilitano le zone di disponibilità.
Configurare le zone di disponibilità
Creare una risorsa con zone di disponibilità abilitate
È possibile configurare le zone di disponibilità solo quando si aggiunge una nuova area a un account Azure Cosmos DB for NoSQL.
Per abilitare il supporto della zona di disponibilità è possibile usare:
Abilitare il supporto della zona di disponibilità
Per informazioni su come abilitare la ridondanza della zona nell'account Azure Cosmos DB, vedere Eseguire la migrazione di Azure Cosmos DB per NoSQL al supporto della zona di disponibilità.
Ripristino di emergenza e continuità aziendale tra aree
Il ripristino di emergenza si riferisce alle procedure usate dalle organizzazioni per il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino di emergenza ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a creare il piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Per il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In questo modello Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Tuttavia, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza adeguato al proprio carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e indicazioni per supportare il ripristino di emergenza. È possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per sviluppare il piano di ripristino di emergenza.
Le interruzioni dell'area sono interruzioni che interessano tutti i nodi di Azure Cosmos DB in un'area di Azure, in tutte le zone di disponibilità. Per i rari casi di interruzioni dell'area, è possibile configurare Azure Cosmos DB per supportare vari risultati di durabilità e disponibilità.
Durabilità
Quando un account Azure Cosmos DB viene distribuito in una singola area, in genere non si verifica alcuna perdita di dati. L'accesso ai dati viene ripristinato dopo il ripristino dei servizi di Azure Cosmos DB nell'area interessata. La perdita di dati può verificarsi solo con un'emergenza impossibile da ripristinare nell'area di Azure Cosmos DB.
Per proteggersi dalla perdita completa dei dati che potrebbe risultare da errori irreversibili in un'area, Azure Cosmos DB offre due modalità di backup:
- Backup continui: backup di ogni area ogni 100 secondi. Consentono di eseguire ripristini temporizzati con granularità di 1 secondo. In ogni area il backup dipende dai dati di cui è stato eseguito il commit in tale area. Se nell'area sono abilitate le zone di disponibilità, il backup verrà archiviato negli account di archiviazione con ridondanza della zona.
- Backup periodici: backup completi di tutte le partizioni di tutti i contenitori nell'account, senza sincronizzazione tra partizioni. L'intervallo di backup minimo è di 1 ora.
Quando un account Azure Cosmos DB viene distribuito in più aree, la durabilità dei dati dipende dal livello di coerenza configurato nell'account. La tabella seguente illustra in dettaglio, per tutti i livelli di coerenza, l'RPO di un account Azure Cosmos DB distribuito in almeno due aree.
| Livello di coerenza | RPO per interruzione dell'area |
|---|---|
| Sessione, Prefisso coerente, Finale | Meno di 15 minuti |
| Decadimento ristretto | K e T |
| Assoluta | 0 |
K = Numero di versioni (ovvero aggiornamenti) di un elemento.
T = Intervallo di tempo dall'ultimo aggiornamento.
Per gli account con più aree, il valore minimo di K e T è 100.000 operazioni di scrittura o 300 secondi. Questo valore definisce il valore RPO minimo per i dati quando si usa il decadimento ristretto.
Per altre informazioni sulle differenze tra i livelli di coerenza, vedere Livelli di coerenza in Azure Cosmos DB.
Failover gestito dal servizio
Se la soluzione richiede tempi di attività continui durante le interruzioni dell'area, è possibile configurare Azure Cosmos DB per replicare i dati in più aree e per eseguire il failover trasparente nelle aree operative quando necessario.
È possibile che gli account in singola area perdano l'accessibilità in caso di interruzione a livello di area. Per garantire sempre la continuità aziendale, è consigliabile configurare l'account Azure Cosmos DB con una singola area di scrittura e almeno una seconda area (di lettura) e abilitare il failover gestito dal servizio.
Il failover gestito dal servizio consente ad Azure Cosmos DB di eseguire il failover dell'area di scrittura di un account con più aree per mantenere la continuità aziendale a fronte di una perdita di dati, come descritto in precedenza nella sezione Durabilità. I failover a livello di area vengono rilevati e gestiti nel client Azure Cosmos DB. Non richiedono modifiche dall'applicazione. Per istruzioni su come abilitare più aree di lettura e il failover gestito dal servizio, vedere Gestire un account Azure Cosmos DB usando il portale di Azure.
Importante
Se è stata scelta la configurazione di scrittura in una singola area con più aree di lettura, è consigliabile configurare gli account Azure Cosmos DB usati per i carichi di lavoro di produzione in modo da abilitare il failover gestito dal servizio. Questa configurazione consente ad Azure Cosmos DB di eseguire il failover dei database dell'account nelle aree disponibili. In assenza di questa configurazione, l'account perderà la disponibilità in scrittura per tutta la durata dell'interruzione dell'area di scrittura. Il failover manuale non riuscirà a causa della mancanza di connettività dell'area.
Avviso
Anche con il failover gestito dal servizio abilitato, un'interruzione parziale può richiedere un intervento manuale da parte del team di servizio di Azure Cosmos DB. In questi scenari può essere necessaria fino a un'ora (o più) perché il failover abbia effetto. Per una migliore disponibilità in scrittura durante le interruzioni parziali, è consigliabile abilitare le zone di disponibilità oltre al failover gestito dal servizio.
Più aree di scrittura
È possibile configurare Azure Cosmos DB per accettare le scritture in più aree. Questa configurazione è utile per ridurre la latenza di scrittura nelle applicazioni distribuite geograficamente.
Quando si configura un account Azure Cosmos DB per più aree di scrittura, la coerenza assoluta non è supportata e potrebbero verificarsi conflitti di scrittura. Per altre informazioni su come risolvere questi conflitti, vedere Tipi di conflitti e criteri di risoluzione quando si usano più aree di scrittura.
Importante
L'aggiornamento frequente dello stesso ID documento (o la ricreazione dello stesso ID documento dopo il TTL o l'eliminazione) avranno un effetto sulle prestazioni di replica a causa dell'aumento del numero di conflitti generati nel sistema.
Area di risoluzione dei conflitti
Quando un account Azure Cosmos DB è configurato con scritture in più aree, una delle aree fungerà da arbitro nei conflitti di scrittura.
Procedure consigliate per le scritture in più aree
Ecco alcune procedure consigliate da considerare quando si scrive in più aree.
Mantenere in locale il traffico locale
Quando si usano le operazioni di scrittura in più aree, l'applicazione dovrebbe inviare il traffico in lettura e scrittura che ha origine nell'area locale esclusivamente all'area locale di Cosmos DB. Per ottenere prestazioni ottimali, evitare chiamate tra aree.
È importante che l'applicazione riduca al minimo i conflitti evitando gli antipattern seguenti:
Invio della stessa operazione di scrittura a tutte le aree per aumentare le probabilità di ottenere un tempo di risposta rapido
Determinare in modo casuale l'area di destinazione di un'operazione di lettura o scrittura per ogni richiesta
Usare un criterio round robin per determinare l'area di destinazione per un'operazione di lettura o scrittura per ogni richiesta.
Evitare la dipendenza dal ritardo della replica
Non è possibile configurare account di scrittura in più aree per la coerenza assoluta. L'area in cui vengono eseguite le operazioni di scrittura risponde immediatamente dopo che Azure Cosmos DB ha replicato i dati in locale, replicandoli in modo asincrono a livello globale.
Anche se è poco frequente, quando si esegue la replica geografica dei dati potrebbe verificarsi un ritardo della replica in una o più partizioni. Il ritardo della replica può essere causato da un raro problema momentaneo nel traffico di rete o da tassi di risoluzione dei conflitti superiori al solito.
Ad esempio, un'architettura in cui l'applicazione scrive nell'area A, ma legge dall'area B, introduce una dipendenza dal ritardo della replica tra le due aree. Tuttavia, se l'applicazione legge e scrive nella stessa area, le prestazioni rimangono costanti anche in presenza di ritardo della replica.
Valutare l'utilizzo della coerenza di sessione per le operazioni di scrittura
Nella coerenza di sessione si usa il token di sessione sia per le operazioni di lettura che per le operazioni di scrittura.
Per le operazioni di lettura, Azure Cosmos DB invia il token di sessione memorizzato nella cache al server con la garanzia di ricevere dati che corrispondono al token di sessione specificato (o più recente).
Per le operazioni di scrittura, Azure Cosmos DB invia il token di sessione al database con la garanzia di salvare i dati in modo permanente solo se il server è aggiornato rispetto al token di sessione fornito. Negli account di scrittura in una singola area, è garantito che l'area di scrittura sia aggiornata rispetto al token di sessione. Tuttavia, negli account di scrittura multi-area, l'area in cui si scrive potrebbe non essere aggiornata rispetto alle scritture eseguite in un'altra area. Se il client scrive nell'area A con un token di sessione dall'area B, l'area A non potrà salvare in modo permanente i dati fino a quando non viene aggiornata alle modifiche apportate nell'area B.
È consigliabile usare i token di sessione solo per le operazioni di lettura e non per le operazioni di scrittura quando si passano token di sessione tra istanze client.
Mitigare i problemi associati agli aggiornamenti rapidi allo stesso documento
Quando lo stesso documento viene aggiornato ripetutamente, gli aggiornamenti del server per risolvere o confermare l'assenza di conflitti possono essere in conflitto con le scritture attivate dall'applicazione. L'esecuzione di aggiornamenti ripetuti in rapida successione allo stesso documento genera latenze più elevate durante la risoluzione dei conflitti.
Anche se è inevitabile che si verifichino impennate occasionali negli aggiornamenti ripetuti dello stesso documento sono inevitabili, è possibile prendere in considerazione un'architettura in cui, se il traffico con stato stabile rileva aggiornamenti rapidi allo stesso documento per un periodo prolungato, vengono creati nuovi documenti.
Interruzioni delle operazioni di lettura e scrittura
I client di account in una singola area subiranno una perdita di disponibilità in lettura e scrittura fino al ripristino del servizio.
Gli account multi-area presentano comportamenti diversi a seconda delle configurazioni e dei tipi di interruzione seguenti.
| Configurazione | Interruzione | Impatto sulla disponibilità | Impatto sulla durabilità | Operazione da eseguire |
|---|---|---|---|---|
| Singola area di scrittura | Interruzione dell'area di lettura | Tutti i client reindirizzano automaticamente le letture ad altre aree. Non esiste alcuna perdita di disponibilità in lettura o scrittura per tutte le configurazioni. L'unica eccezione è una configurazione con due aree con coerenza assoluta, che perde la disponibilità in scrittura fino al ripristino del servizio. In alternativa, se si abilita il failover gestito dal servizio, il servizio contrassegna l'area come in stato di errore e viene eseguito un failover. | Senza perdita di dati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti sia stato effettuato il provisioning di unità richiesta (UR) sufficienti per supportare il traffico di lettura. Al termine dell'interruzione, regolare di nuovo il provisioning di UR come appropriato. |
| Singola area di scrittura | Interruzione dell'area di scrittura | I client reindirizzano le letture ad altre aree. Senza failover gestito dal servizio, i client riscontrano una perdita di disponibilità in scrittura. Il ripristino della disponibilità in scrittura avviene automaticamente al termine dell'interruzione. Con il failover gestito dal servizio, i client riscontrano una perdita di disponibilità in scrittura fino a quando il servizio non gestisce un failover in una nuova area di scrittura selezionata. |
Se non si seleziona il livello di coerenza assoluta, il servizio potrebbe non replicare alcuni dati nelle aree attive rimanenti. Questa replica dipende dal livello di coerenza selezionato. Se l'area interessata subisce una perdita di dati permanente, è possibile perdere dati i non replicati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti sia stato effettuato il provisioning di UR sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione, perché l'operazione non può essere eseguita. Al termine dell'interruzione, regolare di nuovo il provisioning di UR come appropriato. Gli account che usano l'API per NoSQL potrebbero anche recuperare i dati non replicati nell'area in stato di errore dal feed dei conflitti. |
| Più aree di scrittura | Qualunque interruzione a livello di area | Esiste una possibilità di perdita temporanea della disponibilità in scrittura, analogamente a una singola area di scrittura con failover gestito dal servizio. Il failover dell'area di risoluzione dei conflitti potrebbe anche causare una perdita di disponibilità in scrittura se al momento dell'interruzione viene prodotto un numero elevato di scritture in conflitto. | I dati aggiornati di recente nell'area in cui si è verificato l'errore potrebbero non essere disponibili nelle aree attive rimanenti, a seconda del livello di coerenza selezionato. Se l'area interessata subisce una perdita di dati permanente, si potrebbero perdere i dati non replicati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti siano state sottoposte a provisioning UR sufficienti per supportare altro traffico. Al termine dell'interruzione,è possibile regolare di nuovo il provisioning di UR come appropriato. Se possibile, Azure Cosmos DB recupera automaticamente i dati non replicati nell'area in stato di errore. Questo recupero automatico usa il metodo di risoluzione dei conflitti configurato per gli account che usano l'API per NoSQL. Per gli account che usano altre API, questo recupero automatico usa la priorità dell'ultima scrittura. |
Altre informazioni sulle interruzioni dell'area di lettura
L'area interessata viene disconnessa e contrassegnata come offline. Gli SDK di Azure Cosmos DB reindirizzano le chiamate di lettura all'area disponibile successiva nell'elenco delle aree preferite.
Se nessuna delle aree presenti nell'elenco è disponibile, viene eseguito il fallback automatico delle chiamate all'area di scrittura corrente.
Non sono necessarie modifiche nel codice dell'applicazione per gestire le interruzioni di lettura a livello di area. Quando l'area di lettura interessata è di nuovo online, viene sincronizzata con l'area di scrittura corrente ed è nuovamente disponibile per gestire le richieste di lettura dopo che è stata completamente aggiornata.
Le letture successive vengono reindirizzate all'area ripristinata senza richiedere alcuna modifica del codice dell'applicazione. Sia durante il failover che durante il ricongiungimento di un'area che ha riscontrato errori in precedenza, Azure Cosmos DB continua a rispettare le garanzie di coerenza di lettura.
Anche nel raro e sfortunato caso in cui un'area di scrittura di Azure fosse irrimediabilmente non recuperabile, non si verifica alcuna perdita di dati se l'account Azure Cosmos DB multi-area è configurato con la coerenza assoluta. Un account Azure Cosmos DB ,ulti-area presenta le caratteristiche di durabilità specificate in precedenza nella sezione Durabilità.
Altre informazioni sulle interruzioni dell'area di scrittura
Durante un'interruzione dell'area di scrittura, l'account Azure Cosmos DB promuove un'area secondaria a nuova area di scrittura primaria quando nell'account Azure Cosmos DB è configurato il failover gestito dal servizio. Il failover avviene in un'altra area nell'ordine di priorità dell'area specificato.
Il failover manuale non deve essere attivato e non avrà esito positivo in presenza di un'interruzione dell'area di origine o di destinazione. Il motivo è che la procedura di failover include una verifica della coerenza che richiede la connettività tra le aree.
Quando l'area precedentemente interessata torna online, tutti i dati di scrittura che non sono stati replicati quando l'area è entrata in stato errore vengono resi disponibili tramite il feed dei conflitti. Le applicazioni possono leggere il feed dei conflitti, risolvere i conflitti in base alla logica specifica dell'applicazione e scrivere nuovamente i dati aggiornati nel contenitore Azure Cosmos DB come appropriato.
Una volta ripristinata, l'area di scrittura in precedenza interessata viene visualizzata come "online" nel portale di Azure e diventa disponibile come area di lettura. A questo punto, è possibile tornare all'area ripristinata come area di scrittura usando [PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. Non avviene alcuna perdita di dati o di disponibilità prima, durante o dopo il cambio di area di scrittura. L'applicazione continua a offrire disponibilità elevata.
Avviso
Nel caso di un'interruzione di un'area di scrittura, quando l'account Azure Cosmos DB promuove un'area secondaria a nuova area di scrittura primaria tramite failover gestito dal servizio, l'area di scrittura originale non verrà automaticamente promossa di nuovo ad area di scrittura una volta ripristinata. È responsabilità dell'utente reimpostare l'area ripristinata come area di scrittura usando PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure (quando è sicuro farlo, come descritto in precedenza).
Rilevamento, notifica e gestione di interruzioni
Per gli account in area singola, i client riscontrano una perdita di disponibilità in lettura e scrittura durante un'interruzione dell'area di Azure Cosmos DB. Gli account multi-area presentano comportamenti diversi, come descritto nella tabella seguente.
| Aree di scrittura | Failover gestito dal servizio | Cosa aspettarsi | Operazione da eseguire |
|---|---|---|---|
| Singola area di scrittura | Non abilitato | Se si verifica un'interruzione in un'area di lettura quando non si usa la coerenza assoluta, tutti i client reindirizzano ad altre aree. Non si verifica alcuna perdita di disponibilità in lettura o scrittura e non si verifica alcuna perdita di dati. Quando si usa la coerenza assoluta, un'interruzione in un'area di lettura può influire sulla disponibilità in scrittura se rimangono meno di due aree di lettura. Se si verifica un'interruzione nell'area di scrittura, i client riscontrano una perdita di disponibilità in scrittura. Se non è stata selezionata la coerenza assoluta, il servizio potrebbe non replicare alcuni dati nelle aree attive rimanenti. Questa replica dipende dal livello di coerenza selezionato. Se l'area interessata subisce una perdita di dati permanente, si potrebbero perdere i dati non replicati. Azure Cosmos DB ripristina la disponibilità in scrittura al termine dell'interruzione. |
Durante l'interruzione, assicurarsi che nelle aree rimanenti sia stato effettuato il provisioning di UR sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione, perché l'operazione non può essere eseguita. Al termine dell'interruzione, regolare di nuovo il provisioning di UR come appropriato. |
| Singola area di scrittura | Abilitato | Se si verifica un'interruzione in un'area di lettura quando non si usa la coerenza assoluta, tutti i client reindirizzano ad altre aree. Non si verifica alcuna perdita di disponibilità in lettura o scrittura e non si verifica alcuna perdita di dati. Quando si usa la coerenza assoluta, l'interruzione di un'area di lettura può influire sulla disponibilità in scrittura se rimangono meno di due aree di lettura. Se si verifica un'interruzione nell'area di scrittura, i client riscontrano una perdita di disponibilità in scrittura finché Azure Cosmos DB non sceglie una nuova area come area di scrittura in base alle preferenze. Se non è stata selezionata la coerenza assoluta, il servizio potrebbe non replicare alcuni dati nelle aree attive rimanenti. Questa replica dipende dal livello di coerenza selezionato. Se l'area interessata subisce una perdita di dati permanente, si potrebbero perdere i dati non replicati. |
Durante l'interruzione, assicurarsi che nelle aree rimanenti sia stato effettuato il provisioning di UR sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione, perché l'operazione non può essere eseguita. Quando l'interruzione è in corso, è possibile spostare nuovamente l'area di scrittura nell'area originale e riaggiustare le UR di cui è stato effettuato il provisioning in base alle esigenze. Gli account che usano l'API per NoSQL possono anche recuperare i dati non replicati nell'area in stato di errore dal feed dei conflitti. |
| Più aree di scrittura | Non applicabile | I dati aggiornati di recente nell'area in stato di errore potrebbero non essere disponibili nelle aree attive rimanenti. I livelli Coerenza finale, Coerenza del prefisso e Coerenza di sessione e garantiscono un decadimento inferiore a 15 minuti. Il livello Decadimento ristretto garantisce meno di K aggiornamenti o T secondi, a seconda della configurazione. Se l'area interessata subisce una perdita di dati permanente, si potrebbero perdere i dati non replicati. | Durante l'interruzione, assicurarsi che nelle aree rimanenti siano state sottoposte a provisioning UR sufficienti per supportare altro traffico. Al termine dell'interruzione,è possibile regolare di nuovo il provisioning di UR come appropriato. Se possibile, Azure Cosmos DB recupera i dati non replicati nell'area in stato di errore. Questo recupero usa il metodo di risoluzione dei conflitti configurato per gli account che usano l'API per NoSQL. Per gli account che usano altre API, questo recupero usa la priorità dell'ultima scrittura. |
Test per la disponibilità elevata
Anche se l'account Azure Cosmos DB è a disponibilità elevata, l'applicazione potrebbe non essere progettata correttamente per garantire la disponibilità elevata. Per testare la disponibilità elevata end-to-end dell'applicazione come parte dei test dell'applicazione o delle esercitazioni per il ripristino di emergenza, disabilitare temporaneamente il failover gestito dal servizio per l'account. Richiamare il failover manuale usando PowerShell, l'interfaccia della riga di comando di Azure o il portale di Azure e quindi monitorare l'applicazione. Dopo aver completato il test, è possibile eseguire il failover nell'area primaria e ripristinare il failover gestito dal servizio per l'account.
Importante
Non richiamare il failover manuale durante un'interruzione di Azure Cosmos DB nell'area di origine o di destinazione. Il failover manuale richiede la connettività dell'area per mantenere la coerenza dei dati, quindi avrà esito negativo.