Panoramica della continuità aziendale con Database di Azure per PostgreSQL - Server singolo

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server singolo

Importante

Database di Azure per PostgreSQL - Server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per PostgreSQL - Server flessibile. Per altre informazioni sulla migrazione a Database di Azure per PostgreSQL - Server flessibile, vedere What's happening to Database di Azure per PostgreSQL Single Server?.

Questa panoramica descrive le funzionalità offerte da Database di Azure per PostgreSQL per la continuità aziendale e il ripristino di emergenza. Informazioni sulle opzioni per il ripristino da eventi di arresto improvviso che potrebbero provocare la perdita di dati o la disattivazione del database e dell'applicazione. Informazioni sulle operazioni da eseguire quando si verifica un errore generato da un utente o da un'applicazione che influisce sull'integrità dei dati, se in un'area di Azure si verifica un'interruzione o quando l'applicazione richiede manutenzione.

Funzionalità che è possibile usare per assicurare la continuità aziendale

Quando si sviluppa il piano di continuità aziendale, è necessario conoscere il tempo massimo accettabile prima che l'applicazione venga ripristinata completamente dopo l'evento di arresto improvviso. Si tratta dell'obiettivo del tempo di ripristino (RTO). È anche necessario conoscere la perdita massima di aggiornamenti di dati recenti (intervallo di tempo) che l'applicazione riesce a tollerare durante il ripristino dopo l'evento di arresto improvviso, ovvero l'obiettivo del punto di recupero (RPO).

Database di Azure per PostgreSQL offre funzionalità di continuità aziendale, tra cui i backup con ridondanza geografica con la possibilità di avviare il ripristino geografico e la distribuzione delle repliche in lettura in un'area diversa. Ogni funzionalità presenta caratteristiche diverse in termini di tempo di recupero e di potenziale perdita di dati. Con la funzionalità di ripristino geografico, viene creato un nuovo server usando i dati di backup replicati da un'altra area. Il tempo complessivo necessario per il ripristino e il recupero dipende dalle dimensioni del database e dalla quantità di log da recuperare. Il tempo complessivo per stabilire il server varia da pochi minuti ad alcune ore. Con le repliche in lettura, i log delle transazioni dal database primario vengono trasmessi in modo asincrono alla replica. In caso di interruzione del database primario a causa di un errore a livello di zona o a livello di area, il failover nella replica offre un RTO più breve e una riduzione della perdita di dati.

Nota

Il ritardo tra il database primario e la replica dipende dalla latenza tra i siti, dalla quantità di dati da trasmettere e soprattutto dal carico di lavoro di scrittura del server primario. I carichi di lavoro di scrittura pesanti possono generare un ritardo significativo.

A causa della natura asincrona della replica usata per le repliche di lettura, non devono essere considerate come una soluzione a disponibilità elevata perché i ritardi più elevati possono significare RTO e RPO più elevati. Solo per i carichi di lavoro in cui il ritardo rimane più piccolo attraverso i picchi e i tempi non di picco del carico di lavoro, le repliche in lettura possono fungere da alternativa a disponibilità elevata. In caso contrario, le repliche in lettura sono destinate a una vera scalabilità in lettura per carichi di lavoro pesanti pronti e per scenari di ripristino di emergenza (ripristino di emergenza).

La tabella seguente confronta RTO e RPO in uno scenario tipico del carico di lavoro :

Funzionalità Base Utilizzo generico Ottimizzato per la memoria
Ripristino temporizzato dal backup Qualsiasi punto di ripristino entro il periodo di conservazione
RTO - Varia
RPO < 15 min		 Qualsiasi punto di ripristino entro il periodo di conservazione
RTO - Varia
RPO < 15 min		 Qualsiasi punto di ripristino entro il periodo di conservazione
RTO - Varia
RPO < 15 min
Ripristino geografico dai backup con replica geografica Non supportato RTO - Varia
RPO < 1 h		 RTO - Varia
RPO < 1 h
Repliche in lettura RTO - Minuti*
RPO < 5 min*		 RTO - Minuti*
RPO < 5 min*		 RTO - Minuti*
RPO < 5 min*

* RTO e RPO possono essere molto più elevati in alcuni casi a seconda di vari fattori, tra cui la latenza tra siti, la quantità di dati da trasmettere e soprattutto il carico di lavoro di scrittura del database primario.

Ripristinare un server in seguito a errore di un'applicazione o di un utente

È possibile usare i backup del servizio per ripristinare un server da svariati eventi che possono causare interruzioni del funzionamento. Un utente può accidentalmente eliminare alcuni dati, una tabella importante o addirittura un intero database. Un'applicazione potrebbe sovrascrivere accidentalmente dei dati con dati errati a causa di un difetto dell'applicazione e così via.

È possibile eseguire un ripristino temporizzato per creare una copia del server in un momento valido noto. Questo punto nel tempo deve essere compreso nel periodo di conservazione di backup configurato per il server. Dopo il ripristino dei dati nel nuovo server, è possibile sostituire il server originale con il server appena ripristinato o copiare i dati necessari dal server ripristinato nel server originale.

È consigliabile usare il blocco delle risorse di Azure per evitare l'eliminazione accidentale del server. Se il server è stato eliminato accidentalmente, potrebbe essere possibile ripristinarlo se l'eliminazione è avvenuta negli ultimi 5 giorni. Per altre informazioni, vedere Ripristinare un server Database di Azure per PostgreSQL eliminato.

Eseguire il ripristino in seguito un'interruzione del data center di Azure

Anche se raramente, un data center di Azure può subire un'interruzione del servizio. Quando si verifica un'interruzione, viene generata un'interruzione delle attività che potrebbe durare solo pochi minuti, ma anche ore.

Una delle opzioni è attendere che il server torni online al termine dell'interruzione del data center. Questa opzione funziona per le applicazioni che possono permettersi di avere il server offline per un certo periodo, ad esempio gli ambienti di sviluppo. Quando un data center ha un'interruzione, non si sa quanto tempo potrebbe durare l'interruzione, quindi questa opzione funziona solo se non è necessario il server per un certo periodo di tempo.

Ripristino geografico

La funzionalità di ripristino geografico ripristina il server usando backup con ridondanza geografica. I backup sono ospitati nell'area associata del server. È possibile eseguire il ripristino da questi backup in qualsiasi altra area. Il ripristino geografico crea un nuovo server con i dati dei backup. Altre informazioni sul ripristino geografico sono disponibili nell'articolo concetti relativi al backup e al ripristino.

Importante

Il ripristino geografico è possibile solo se è stato effettuato il provisioning del server con l'archivio di backup con ridondanza geografica. Per passare da backup con ridondanza locale a backup con ridondanza geografica per un server esistente, è necessario eseguire un dump del server esistente usando pg_dump e quindi ripristinarlo in un nuovo server configurato per i backup con ridondanza geografica.

Repliche in lettura tra aree

È possibile usare repliche in lettura tra aree per migliorare la continuità aziendale e la pianificazione del ripristino di emergenza. Le repliche in lettura vengono aggiornate in modo asincrono usando la tecnologia di replica fisica di PostgreSQL e possono causare un ritardo nel database primario. Altre informazioni sulle repliche in lettura, sulle aree disponibili e su come eseguire il failover dall'articolo Concetti relativi alle repliche in lettura.

Domande frequenti

Dove Database di Azure per PostgreSQL archivia i dati dei clienti?

Per impostazione predefinita, Database di Azure per PostgreSQL non sposta o archivia i dati dei clienti dall'area in cui viene distribuita. Tuttavia, i clienti possono scegliere facoltativamente di abilitare i backup con ridondanza geografica o creare una replica di lettura tra aree per l'archiviazione dei dati in un'altra area.

Passaggi successivi