Condividi tramite


Replica tra aree in Azure Cosmos DB per vCore MongoDB

SI APPLICA A: MongoDB vCore

Questo articolo illustra il ripristino di emergenza (DR) tra aree per vCore di Azure Cosmos DB per MongoDB. Vengono inoltre illustrate le funzionalità di lettura delle repliche cluster in altre aree per la scalabilità delle operazioni di lettura.

La funzionalità di replica tra aree consente di replicare i dati da un cluster a un cluster di sola lettura in un'altra area di Azure. Le repliche vengono aggiornate con la tecnologia di replica asincrona. È possibile avere una replica del cluster in un'altra area preferita per il cluster vCore di Azure Cosmos DB per MongoDB primario. In rari casi di interruzione dell'area, è possibile alzare di livello la replica del cluster in un'altra area per diventare il nuovo cluster di lettura/scrittura per il funzionamento continuo del database MongoDB. Le applicazioni potrebbero continuare a usare le stesse stringhe di connessione dopo che la replica del cluster in un'altra area viene alzata di livello per diventare il nuovo cluster primario.

Le repliche consistono in nuovi cluster gestibili in modo simile ai cluster normali. Per ogni replica in lettura, viene addebitato il costo delle risorse di calcolo e di archiviazione sottoposte a provisioning, espresse rispettivamente in vCore e GiB/mese. I costi di calcolo e archiviazione per i cluster di replica hanno la stessa struttura dei normali cluster e dei prezzi dell'area di Azure in cui vengono creati.

Ripristino di emergenza tramite repliche in lettura cluster

La replica tra aree è uno dei principali pilastri di strategia di continuità aziendale e ripristino di emergenza (BCDR) di Azure. La replica tra aree replica in modo asincrono le stesse applicazioni e i dati in altre aree di Azure per la protezione del ripristino di emergenza. Non tutti i servizi di Azure replicano automaticamente i dati o eseguono automaticamente il fallback da un'area problematica per eseguire la replica incrociata in un'altra area abilitata. vCore di Azure Cosmos DB per MongoDB offre un'opzione per creare una replica cluster in un'altra area e avere i dati scritti nel cluster primario replicati automaticamente in tale replica. Il fallback alla replica cluster in caso di interruzione nell'area primaria deve essere avviato manualmente.

Quando la replica tra aree è abilitata in un cluster vCore di Azure Cosmos DB per MongoDB, ogni partizione viene replicata in un'altra area in modo continuo. Questa replica gestisce una replica di dati nell'area selezionata. Una replica di questo tipo è pronta per essere usata come parte del piano di ripristino di emergenza in un raro caso di interruzione dell'area primaria. La replica è asincrona. Le operazioni di scrittura nella partizione del cluster primario non attendono la replica completata nella partizione della replica corrispondente prima di inviare la conferma di una scrittura corretta. La replica asincrona consente di evitare latenze maggiori per le operazioni di scrittura nel cluster primario.

Scritture continue, operazioni di lettura nelle repliche cluster e stringa di connessione

Il stringa di connessione di lettura/scrittura globale in Azure Cosmos DB per MongoDB indirizza costantemente le scritture nel cluster attivo abilitato per la scrittura. Quando si avvia un'innalzamento di livello di un cluster di replica, il cluster di replica nell'area B passa alla modalità di scrittura, mentre il cluster primario originale nell'area A passa in sola lettura. Prima dell'innalzamento di livello, il stringa di connessione di lettura globale è destinato al cluster primario nell'area A e quindi viene aggiornato in modo che punti all'area B, in quanto presuppone responsabilità di scrittura. Per le applicazioni che usano il stringa di connessione di lettura/scrittura globale, le operazioni di scrittura continuano senza problemi durante il processo di promozione, mantenendo un flusso di dati ininterrotto.

I cluster di replica sono disponibili anche per le letture. Consente di eseguire l'offload di operazioni di lettura intensive dal cluster primario o di offrire una latenza ridotta per le operazioni di lettura ai client che si trovano più vicino all'area di replica. Quando la replica tra aree è abilitata, le applicazioni possono usare il cluster di replica self-stringa di connessione per eseguire letture dalla replica cluster. Il cluster primario è disponibile per le operazioni di lettura e scrittura usando il proprio stringa di connessione autonomo.

Screenshot del cluster stringa di connessione un cluster Azure Cosmos DB per MongoDB (vCore), tra cui stringa di connessione di lettura e stringa di connessione self-write globali.

Quando si crea una replica abilitando la replica tra aree, non eredita le impostazioni di rete, ad esempio le regole del firewall del cluster primario. Queste impostazioni devono essere configurate in modo indipendente per la replica. La replica eredita l'account amministratore dal cluster primario. Gli account utente devono essere gestiti nel cluster primario. È possibile connettersi al cluster primario e al relativo cluster di replica usando gli stessi account utente.

Promozione del cluster di replica

Se si verifica un'interruzione dell'area, è possibile eseguire un'operazione di ripristino di emergenza promuovendo la replica del cluster in un'altra area per diventare disponibile per le scritture. Durante l'operazione di promozione della replica, vengono eseguiti questi passaggi:

  1. Le scritture nella replica nell'area B sono abilitate oltre alle letture. La replica precedente diventa un nuovo cluster di lettura/scrittura.
  2. Il cluster di replica alzato di livello nell'area B accetta scritture usando i relativi stringa di connessione e l'stringa di connessione di lettura/scrittura globale.
  3. Il cluster nell'area A è impostato su sola lettura e ne mantiene il stringa di connessione.

Importante

Poiché la replica è asincrona, alcuni dati del cluster nell'area A potrebbero non essere replicati nell'area B quando viene alzata di livello la replica del cluster nell'area B. In questo caso, la promozione comporterà la mancata replica dei dati non presenti in entrambi i cluster.