Ottenere la disponibilità elevata con Azure Cosmos DB

Articolo
11/16/2023

SI APPLICA A: Nosql Mongodb Cassandra Gremlin Tabella

Per creare una soluzione con disponibilità elevata, è necessario valutare le caratteristiche di affidabilità di tutti i relativi componenti. Azure Cosmos DB offre funzionalità e opzioni di configurazione per ottenere una disponibilità elevata per la soluzione.

Questo articolo usa le condizioni seguenti:

Obiettivo del tempo di ripristino (RTO): tempo compreso tra l'inizio di un'interruzione che influisce su Azure Cosmos DB e il ripristino fino alla disponibilità completa.
Obiettivo del punto di ripristino (RPO): tempo compreso tra l'ultima scrittura ripristinata correttamente e l'ora dell'inizio dell'interruzione che influisce su Azure Cosmos DB.

Nota

Gli rpo previsti e massimi e gli oggetti RTO dipendono dal tipo di interruzione riscontrato da Azure Cosmos DB. Ad esempio, un'interruzione di un singolo nodo ha RTO e RPO previsti diversi rispetto all'interruzione di un'intera area.

Questo articolo illustra in dettaglio gli eventi che possono influire sulla disponibilità di Azure Cosmos DB e sulle opzioni di configurazione di Azure Cosmos DB corrispondenti.

Manutenzione della replica

Azure Cosmos DB è un servizio multi-tenant che gestisce in modo trasparente tutti i dettagli dei singoli nodi di calcolo. Gli utenti non devono preoccuparsi di alcun tipo di applicazione di patch o manutenzione pianificata. Azure Cosmos DB garantisce contratti di servizio per la disponibilità e la latenza P99 tramite tutte le operazioni di manutenzione automatica eseguite dal sistema.

Interruzioni della replica

Le interruzioni della replica sono interruzioni dei singoli nodi in un cluster di Azure Cosmos DB distribuito in un'area di Azure.

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 interruzioni dei singoli nodi, senza richiedere modifiche o configurazioni dell'applicazione.

In molte aree di Azure è possibile distribuire il cluster Azure Cosmos DB tra zone di disponibilità. Le zone di disponibilità possono aumentare i contratti di servizio perché sono fisicamente separati e forniscono una fonte di alimentazione, una rete e un raffreddamento distinti. Quando si distribuisce un account Azure Cosmos DB usando le zone di disponibilità, Azure Cosmos DB fornisce un RTO pari a 0 e un RPO pari a 0, anche in un'interruzione della zona.

Quando si esegue la distribuzione in una singola area di Azure, senza input utente aggiuntivo, Azure Cosmos DB è resiliente alle interruzioni dei nodi. L'abilitazione della ridondanza tra zone di disponibilità rende Azure Cosmos DB resiliente alle interruzioni della zona a costi elevati.

È possibile configurare la ridondanza della zona solo quando si aggiunge una nuova area a un account Azure Cosmos DB. Per le aree esistenti, è possibile abilitare la ridondanza della zona rimuovendo l'area e quindi aggiungendola nuovamente con la ridondanza della zona abilitata. Per un account a singola area, questo approccio richiede di aggiungere un'area per eseguire temporaneamente il failover e quindi rimuovere e aggiungere l'area desiderata con la ridondanza della zona abilitata.

Per impostazione predefinita, un account Azure Cosmos DB non usa più zone di disponibilità. È possibile abilitare la distribuzione in più zone di disponibilità nei modi seguenti:

Se l'account Azure Cosmos DB viene distribuito tra le aree di Azure N , saranno presenti N x 4 copie di tutti i dati. Per altre informazioni su come Azure Cosmos DB replica i dati in ogni area, vedere Distribuzione globale con Azure Cosmos DB. La disponibilità di un account Azure Cosmos DB in più di due aree migliora la disponibilità dell'applicazione e offre bassa latenza nelle aree associate.

Interruzioni dell'area

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 irreversibile nell'area di Azure Cosmos DB.

Per proteggersi dalla perdita completa dei dati che potrebbe causare emergenze irreversibili in un'area, Azure Cosmos DB offre due modalità di backup:

Backup continui di ogni area ogni 100 secondi. Consentono di ripristinare i dati in qualsiasi momento con granularità di 1 secondo. In ogni area il backup dipende dai dati di cui è stato eseguito il commit in tale area.
Backup periodici di 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 l'interruzione dell'area
Sessione, prefisso coerente, finale	Meno di 15 minuti
Obsolescenza associata	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 decadimento ristretto.

Per altre informazioni sulle differenze tra i livelli di coerenza, vedere Livelli di coerenza in Azure Cosmos DB.

Disponibilità

Se la soluzione richiede disponibilità continua 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 disponibili quando necessario.

Gli account a singola area potrebbero perdere la disponibilità dopo un'interruzione a livello di area. Per garantire la disponibilità elevata in qualsiasi momento, è consigliabile configurare l'account Azure Cosmos DB con una singola area di scrittura e almeno un'area di scrittura (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 disponibilità al costo della 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 failover gestito dal servizio, vedere Gestire un account Azure Cosmos DB usando il portale di Azure.

Importante

Se è stata scelta la configurazione di scrittura a singola area con più aree di lettura, è consigliabile configurare gli account Azure Cosmos DB usati per i carichi di lavoro di produzione per 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à di scrittura per tutta la durata dell'interruzione dell'area di scrittura. Il failover manuale non riesce a causa di una mancanza di connettività dell'area.

Avviso

Anche con il failover gestito dal servizio abilitato, un'interruzione parziale può richiedere un intervento manuale per il team del servizio Azure Cosmos DB. In questi scenari possono essere necessarie fino a 1 ora (o più) per rendere effettivo il failover. Per una migliore disponibilità di scrittura durante 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 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 TTL o eliminazione) avrà un effetto sulle prestazioni di replica a causa di un numero maggiore 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 il traffico locale

Quando si usano scritture in più aree, l'applicazione deve emettere traffico di lettura e scrittura che ha origine nell'area locale esclusivamente nell'area locale di Cosmos DB. Per ottenere prestazioni ottimali, evitare chiamate tra aree.

È importante per l'applicazione ridurre 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 per un'operazione di lettura o scrittura per ogni richiesta
Uso di criteri 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 coerenza assoluta. L'area scritta in risponde immediatamente dopo che Azure Cosmos DB replica i dati in locale durante la replica asincrona dei dati a livello globale.

Anche se è poco frequente, potrebbe verificarsi un ritardo di replica in una o poche partizioni quando si esegue la replica geografica dei dati. Il ritardo di replica può verificarsi a causa di un raro blip nel traffico di rete o di frequenze superiori al solito di risoluzione dei conflitti.

Ad esempio, un'architettura in cui l'applicazione scrive nell'area A, ma legge dall'area B introduce una dipendenza dal ritardo di 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 della sessione per le operazioni di scrittura

Nella coerenza della sessione si usa il token di sessione per le operazioni di lettura e scrittura.

Per le operazioni di lettura, Azure Cosmos DB invia il token di sessione memorizzato nella cache al server con una garanzia di ricezione dei 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 una garanzia di persistenza dei dati solo se il server ha raggiunto il token di sessione fornito. Negli account di scrittura in un'area singola, l'area di scrittura viene sempre rilevata fino al token di sessione. Tuttavia, negli account di scrittura in più aree, l'area in cui si scrive potrebbe non essere stata rilevata per le scritture rilasciate in un'altra area. Se il client scrive nell'area A con un token di sessione dall'area B, l'area A non sarà in grado di 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.

Attenuare gli aggiornamenti rapidi allo stesso documento

Gli aggiornamenti del server per risolvere o confermare l'assenza di conflitti possono essere in conflitto con le scritture attivate dall'applicazione quando lo stesso documento viene aggiornato ripetutamente. Aggiornamenti ripetuti in rapida successione allo stesso documento con latenze più elevate durante la risoluzione dei conflitti.

Anche se i picchi occasionali di aggiornamenti ripetuti dello stesso documento sono inevitabili, è possibile prendere in considerazione l'esplorazione di un'architettura in cui vengono creati nuovi documenti se il traffico con stato stabile rileva aggiornamenti rapidi allo stesso documento in un periodo prolungato.

Cosa aspettarsi durante un'interruzione dell'area

I client di account a area singola riscontrano una perdita di disponibilità di lettura e scrittura fino al ripristino del servizio.

Gli account in più aree riscontrano comportamenti diversi a seconda delle configurazioni e dei tipi di interruzione seguenti.

Impostazione	Outage	Impatto sulla disponibilità	Impatto sulla durabilità	Operazione da eseguire
Area di scrittura singola	Interruzione dell'area di lettura	Tutti i client reindirizza automaticamente le letture ad altre aree. Non esiste alcuna perdita di disponibilità di lettura o scrittura per tutte le configurazioni. L'eccezione è una configurazione di due aree con coerenza assoluta, che perde la disponibilità di scrittura fino al ripristino del servizio. In alternativa, se si abilita il failover gestito dal servizio, il servizio contrassegna l'area come non riuscita e si verifica un failover.	Nessuna perdita di dati.	Durante l'interruzione, assicurarsi che siano presenti unità richiesta (UR) di cui è stato effettuato il provisioning nelle aree rimanenti per supportare il traffico di lettura. Quando l'interruzione è finita, le UR di cui è stato effettuato il provisioning sono corrette in base alle esigenze.When the outage is over, readjust provisioned UR as appropriate.
Area di scrittura singola	Interruzione dell'area di scrittura	I client reindirizza le letture ad altre aree. Senza failover gestito dal servizio, i client riscontrano una perdita di disponibilità in scrittura. Il ripristino della disponibilità di scrittura si verifica 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 permanente di dati, è possibile perdere dati non replicati.	Durante l'interruzione, assicurarsi che nelle aree rimanenti siano presenti UR con provisioning sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione perché non riesce. Quando l'interruzione è finita, le UR di cui è stato effettuato il provisioning sono corrette in base alle esigenze.When the outage is over, readjust provisioned UR as appropriate. Gli account che usano l'API per NoSQL potrebbero anche recuperare i dati non replicati nell'area non riuscita dal feed dei conflitti.
Più aree di scrittura	Eventuali interruzioni a livello di area	Esiste una possibilità di perdita temporanea della disponibilità di scrittura, analoga 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à di scrittura se si verifica un numero elevato di scritture in conflitto al momento dell'interruzione.	I dati aggiornati di recente nell'area non riuscita potrebbero non essere disponibili nelle aree attive rimanenti, a seconda del livello di coerenza selezionato. Se l'area interessata subisce una perdita permanente di dati, è possibile che si perdano dati non replicati.	Durante l'interruzione, assicurarsi che nelle aree rimanenti sia disponibile un numero sufficiente di UR di cui è stato effettuato il provisioning per supportare un maggior traffico. Quando l'interruzione è finita, è possibile riaggiustarne il provisioning in base alle esigenze. Se possibile, Azure Cosmos DB recupera automaticamente i dati non replicati nell'area non riuscita. Questo ripristino 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 ripristino automatico usa le ultime vittorie di scrittura.

Altre informazioni sulle interruzioni dell'area di lettura

L'area interessata è 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 nell'elenco delle aree preferite è disponibile, esegue automaticamente il fallback all'area di scrittura corrente.
Non sono necessarie modifiche nel codice dell'applicazione per gestire le interruzioni dell'area di lettura. 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 rilevata.
Le letture successive vengono reindirizzate all'area ripristinata senza richiedere alcuna modifica del codice dell'applicazione. Durante il failover e la ricongiuzione di un'area precedentemente non riuscita, Azure Cosmos DB continua a rispettare le garanzie di coerenza di lettura.
Anche in un caso raro e sfortunato in cui un'area di scrittura di Azure è permanentemente irreversibile, non si verifica alcuna perdita di dati se l'account Azure Cosmos DB in più aree è configurato con coerenza assoluta. Un account Azure Cosmos DB in più aree 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 come nuova area di scrittura primaria quando il failover gestito dal servizio è configurato nell'account Azure Cosmos DB. Il failover si verifica 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 coerenza che richiede la connettività tra le aree.
Quando l'area interessata in precedenza è di nuovo online, tutti i dati di scrittura che non sono stati replicati quando l'area non è riuscita viene resa disponibile 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 in base alle esigenze.
Dopo il ripristino dell'area di scrittura interessata in precedenza, viene visualizzato come "online" in 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. Non esiste alcuna perdita di dati o disponibilità prima, mentre o dopo aver cambiato l'area di scrittura. L'applicazione continua a offrire disponibilità elevata.

Avviso

In caso di interruzione dell'area di scrittura, in cui l'account Azure Cosmos DB promuove un'area secondaria come nuova area di scrittura primaria tramite failover gestito dal servizio, l'area di scrittura originale non verrà alzata di livello automaticamente quando l'area di scrittura viene ripristinata. È responsabilità dell'utente tornare all'area ripristinata come area di scrittura usando PowerShell, l'interfaccia della riga di comando di Azure o l'portale di Azure (una volta sicura per farlo, come descritto in precedenza).

Contratti di servizio

La tabella seguente riepiloga le funzionalità a disponibilità elevata di varie configurazioni dell'account.

KPI	Scritture a singola area senza zone di disponibilità	Scritture a singola area con zone di disponibilità	Scritture in più aree, a singola area senza zone di disponibilità	Scritture in più aree, a singola area con zone di disponibilità	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	Dipendente dal livello di coerenza. Per altre informazioni, vedere Coerenza, disponibilità e compromessi sulle prestazioni.	Dipendente dal livello di coerenza. Per altre informazioni, vedere Coerenza, disponibilità e compromessi sulle prestazioni.	Dipendente dal livello di coerenza. Per altre informazioni, vedere Coerenza, disponibilità e compromessi sulle prestazioni.
Interruzione a livello di area: disponibilità	Perdita di disponibilità	Perdita di disponibilità	Nessuna perdita di disponibilità per l'errore dell'area di lettura, temporanea per l'errore dell'area di scrittura	Nessuna perdita di disponibilità per l'errore dell'area di lettura, temporanea per l'errore dell'area di scrittura	Nessuna perdita di disponibilità in lettura, perdita temporanea di disponibilità in scrittura nell'area interessata
Prezzo (1)	Non applicabile	Velocità di ur/sec di provisioning x 1,25	Aree di UR/s x N di cui è stato effettuato il provisioning	Ur/s di cui è stato effettuato il provisioning x 1,25 x N aree (2)	Frequenza 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 La tariffa 1,25 si applica solo alle aree in cui si abilitano le zone di disponibilità.

Suggerimenti per la creazione di applicazioni a disponibilità elevata

Esaminare il comportamento previsto degli SDK di Azure Cosmos DB durante gli eventi e quali configurazioni ne influiscono.
Per garantire una disponibilità elevata di scrittura e lettura, configurare l'account Azure Cosmos DB per estendersi su almeno due aree (o tre, se si usa coerenza assoluta). Per altre informazioni, vedere Esercitazione: Configurare la distribuzione globale di Azure Cosmos DB usando l'API per NoSQL.
Per gli account Azure Cosmos DB in più aree configurati con una singola area di scrittura, abilitare il failover gestito dal servizio usando l'interfaccia della riga di comando di Azure o il portale di Azure. Dopo aver abilitato il failover gestito dal servizio, ogni volta che si verifica un'emergenza a livello di area, Azure Cosmos DB eseguirà il failover dell'account senza alcun input utente.
Anche se l'account Azure Cosmos DB è a disponibilità elevata, l'applicazione potrebbe non essere progettata correttamente per rimanere a disponibilità elevata. Per testare la disponibilità elevata end-to-end dell'applicazione come parte delle esercitazioni sul test dell'applicazione o sul 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 non avrà esito positivo.
All'interno di un ambiente di database distribuito a livello globale, esiste una relazione diretta tra il livello di coerenza e la durabilità dei dati in presenza di un'interruzione a livello di area. Durante lo sviluppo del piano di continuità aziendale, è necessario comprendere il tempo massimo accettabile prima che l'applicazione venga ripristinata completamente dopo un evento di interruzione, ovvero l'RTO. È anche necessario comprendere il periodo massimo di aggiornamenti recenti dei dati che l'applicazione può tollerare quando viene ripristinata dopo un evento di interruzione, ovvero l'RPO. Per altre informazioni su RTO e RPO, vedere Livelli di coerenza in Azure Cosmos DB.

Cosa aspettarsi durante un'interruzione dell'area di Azure Cosmos DB

Per gli account a singola area, i client riscontrano una perdita di disponibilità di lettura e scrittura durante un'interruzione dell'area di Azure Cosmos DB. Gli account in più aree riscontrano comportamenti diversi, come descritto nella tabella seguente.

Aree per le operazioni di scrittura	Failover gestito dal servizio	Risultati previsti	Operazione da eseguire
Area di scrittura singola	Non abilitata	Se si verifica un'interruzione in un'area di lettura quando non si usa una coerenza assoluta, tutti i client reindirizzano ad altre aree. Non esiste alcuna perdita di disponibilità di lettura o scrittura e non si verifica alcuna perdita di dati. Quando si usa una coerenza assoluta, un'interruzione in un'area di lettura può influire sulla disponibilità di 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 una 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 permanente di dati, è possibile che si perdano dati non replicati. Azure Cosmos DB ripristina la disponibilità di scrittura al termine dell'interruzione.	Durante l'interruzione, assicurarsi che nelle aree rimanenti siano presenti UR con provisioning sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione perché non riesce. Quando l'interruzione è finita, le UR di cui è stato effettuato il provisioning sono corrette in base alle esigenze.When the outage is over, readjust provisioned UR as appropriate.
Area di scrittura singola	Attivata	Se si verifica un'interruzione in un'area di lettura quando non si usa una coerenza assoluta, tutti i client reindirizzano ad altre aree. Non esiste alcuna perdita di disponibilità di lettura o scrittura e non si verifica alcuna perdita di dati. Quando si usa una coerenza assoluta, l'interruzione di un'area di lettura può influire sulla disponibilità di 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 nuova area di scrittura in base alle preferenze. Se non è stata selezionata una 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 permanente di dati, è possibile che si perdano dati non replicati.	Durante l'interruzione, assicurarsi che nelle aree rimanenti siano presenti UR con provisioning sufficienti per supportare il traffico di lettura. Non attivare un failover manuale durante l'interruzione perché non riesce. 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 non riuscita dal feed dei conflitti.
Più aree di scrittura	Non applicabile	I dati aggiornati di recente nell'area non riuscita potrebbero non essere disponibili nelle aree attive rimanenti. I livelli di coerenza finale, coerente e di coerenza della sessione garantiscono un decadimento inferiore a 15 minuti. La decadimento ristretto garantisce meno di K aggiornamenti o T secondi, a seconda della configurazione. Se l'area interessata subisce una perdita permanente di dati, è possibile che si perdano dati non replicati.	Durante l'interruzione, assicurarsi che nelle aree rimanenti sia disponibile un numero sufficiente di UR di cui è stato effettuato il provisioning per supportare un maggior traffico. Quando l'interruzione è finita, è possibile riaggiustarne il provisioning in base alle esigenze. Se possibile, Azure Cosmos DB recupera i dati non replicati nell'area non riuscita. Questo ripristino 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 ripristino usa le ultime vittorie di scrittura.

Passaggi successivi

Successivamente, è possibile leggere gli articoli seguenti: