Panoramica della continuità aziendale con Database di Azure per MariaDB

Importante

Database di Azure per MariaDB è sul percorso di ritiro. È consigliabile eseguire la migrazione a Database di Azure per MySQL. Per altre informazioni sulla migrazione a Database di Azure per MySQL, vedere What's happening to Database di Azure per MariaDB?.

Questo articolo descrive le funzionalità offerte da Database di Azure per MariaDB 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 su cosa fare quando un errore utente o un errore dell'applicazione influisce sull'integrità dei dati, un'area di Azure ha un'interruzione o richiede manutenzione dell'applicazione.

Funzionalità per la continuità aziendale

Durante lo sviluppo del piano di continuità aziendale, è necessario comprendere quanto segue:

• Obiettivo del tempo di ripristino (RTO): tempo massimo accettabile prima che l'applicazione venga ripristinata completamente dopo un evento di interruzione.
• Obiettivo del punto di ripristino (RPO): quantità massima di aggiornamenti dei dati recenti (intervallo di tempo) che l'applicazione può tollerare la perdita quando viene ripristinata dopo un evento di interruzione.

Database di Azure per MariaDB offre funzionalità di continuità aziendale e ripristino di emergenza che includono backup con ridondanza geografica con la possibilità di avviare il ripristino geografico e distribuire repliche in lettura in un'altra area. Ogni funzionalità presenta caratteristiche diverse in termini di tempo di recupero e di potenziale perdita di dati.

Con il ripristino geografico, Database di Azure per MariaDB crea un nuovo server usando i dati di backup replicati da un'altra area. Il tempo complessivo per il ripristino e il ripristino dipende dalle dimensioni del database e dalla quantità di dati di log da ripristinare. 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 a una replica. Se si verifica un'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 (più importante) 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 in lettura, non considerare le repliche in lettura come soluzione a disponibilità elevata. I lag più elevati possono significare un RTO e un RPO più elevati. Le repliche in lettura possono fungere da alternativa a disponibilità elevata solo per i carichi di lavoro in cui il ritardo rimane più piccolo attraverso i picchi e gli orari di minore attività. In caso contrario, le repliche in lettura sono destinate alla scalabilità in lettura effettiva per carichi di lavoro con utilizzo elevato di lettura e per scenari di ripristino di emergenza.

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

Funzionalità	Di base	Utilizzo generico	Ottimizzato per la memoria
Ripristino temporizzato dal backup	Qualsiasi punto di ripristino entro il periodo di conservazione RTO varia RPO è inferiore a 15 minuti	Qualsiasi punto di ripristino entro il periodo di conservazione RTO varia RPO è inferiore a 15 minuti	Qualsiasi punto di ripristino entro il periodo di conservazione RTO varia RPO è inferiore a 15 minuti
Ripristino geografico dai backup con replica geografica	Non supportato	RTO varia RPO è maggiore di 24 ore	RTO varia RPO è maggiore di 24 ore
Repliche in lettura	L'obiettivo RTO è minuti RPO è inferiore a 5 minuti	L'obiettivo RTO è minuti RPO è inferiore a 5 minuti	L'obiettivo RTO è minuti RPO è inferiore a 5 minuti

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

Ripristino di un server dopo un errore dell'utente o dell'applicazione

È possibile usare i backup del servizio per ripristinare un server da vari eventi di interruzione. Ad esempio, un utente potrebbe eliminare accidentalmente alcuni dati, eliminare accidentalmente una tabella importante o persino eliminare un intero database. Un'applicazione potrebbe sovrascrivere accidentalmente dati validi con dati non validi a causa di un difetto dell'applicazione.

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

Importante

È possibile ripristinare i server eliminati solo entro cinque giorni dall'eliminazione. Dopo cinque giorni, i backup vengono eliminati. È possibile accedere e ripristinare il backup del database solo dalla sottoscrizione di Azure che ospita il server. Per ripristinare un server eliminato, vedere i passaggi documentati. Per proteggere le risorse del server da eliminazioni accidentali o modifiche impreviste dopo la distribuzione, gli amministratori possono usare i blocchi di gestione.

Ripristino da un'interruzione del data center a livello di area di Azure

Anche se è raro, un data center di Azure può avere un'interruzione. Quando si verifica un'interruzione, causa un'interruzione dell'azienda che potrebbe durare solo alcuni minuti, ma potrebbe durare per ore.

Un'opzione consiste nell'attendere che il server torni online quando l'interruzione del data center è finita. Quando il data center ha un'interruzione, non si sa quanto tempo potrebbe durare l'interruzione. Questa opzione funziona quindi solo per le applicazioni che possono consentire la modalità offline del server per un certo periodo di tempo (ad esempio, un ambiente di sviluppo).

Ripristino geografico

La funzionalità di ripristino geografico ripristina il server usando backup con ridondanza geografica. I backup sono ospitati nell'area associata del server. Questi backup sono accessibili anche quando l'area in cui è ospitato il server è offline. È possibile eseguire il ripristino da questi backup in qualsiasi altra area e quindi riportare online il server. Altre informazioni sul ripristino geografico sono disponibili nell'articolo sui concetti relativi al backup e al ripristino.

Importante

Il ripristino geografico è possibile solo se è stato effettuato il provisioning del server con l'archiviazione di backup con ridondanza geografica. Se si vuole passare da backup con ridondanza locale a backup con ridondanza geografica per un server esistente, è necessario generare un backup del server esistente usando mysqldump. Eseguire quindi il ripristino in un server appena creato configurato con backup con ridondanza geografica.

Repliche in lettura tra aree

È possibile usare repliche in lettura tra aree per migliorare la pianificazione per la continuità aziendale e il ripristino di emergenza. Le repliche in lettura vengono aggiornate in modo asincrono tramite la tecnologia di replica di MySQL per i log binari. Altre informazioni sulle repliche in lettura, sulle aree disponibili e su come eseguire il failover nell'articolo sui concetti di replica in lettura.

Domande frequenti

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

Per impostazione predefinita, Database di Azure per MariaDB non sposta o archivia i dati dei clienti dall'area in cui viene distribuita. È tuttavia possibile scegliere facoltativamente di abilitare i backup con ridondanza geografica o creare repliche in lettura tra aree per l'archiviazione dei dati in un'altra area.

Passaggi successivi

• Altre informazioni sui backup automatizzati in Database di Azure per MariaDB.
• Informazioni su come eseguire il ripristino usando il portale di Azure o l'interfaccia della riga di comando di Azure.
• Informazioni sulle repliche in lettura in Database di Azure per MariaDB.