Share via

Panoramica della continuità aziendale con Database di Azure per MySQL - Server flessibile

  • Articolo

SI APPLICA A: Database di Azure per MySQL - Server flessibile

Database di Azure per MySQL server flessibile consente funzionalità di continuità aziendale che proteggono i database in caso di interruzione pianificata e non pianificata. Funzionalità come i backup automatizzati e la disponibilità elevata indirizzano diversi livelli di protezione dagli errori con diversi tempi di ripristino ed esposizione alla perdita di dati. Quando si progetta l'applicazione per proteggersi da errori, è consigliabile prendere in considerazione l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) per ogni applicazione. RTO è la tolleranza di inattività e RPO è la tolleranza alla perdita di dati dopo un'interruzione del servizio di database.

Nella tabella seguente vengono illustrate le funzionalità offerte Database di Azure per MySQL server flessibile.

Funzionalità Descrizione Restrizioni
Backup e ripristino Il servizio esegue automaticamente backup giornalieri dei file di database e esegue continuamente il backup dei log delle transazioni. I backup possono essere conservati per qualsiasi periodo compreso tra 1 e 35 giorni. È possibile ripristinare il server di database in qualsiasi momento entro il periodo di conservazione dei backup. Il tempo di recupero dipende dalle dimensioni dei dati da ripristinare e dal tempo necessario per eseguire il ripristino del log. Per altri dettagli, vedere Concetti - Backup e ripristino. I dati di backup rimangono all'interno dell'area
Backup con ridondanza locale I backup del servizio vengono archiviati automaticamente e in modo sicuro in una risorsa di archiviazione con ridondanza locale all'interno di un'area e nella stessa zona di disponibilità. I backup con ridondanza locale replicano i file di dati di backup del server tre volte all'interno di una singola posizione fisica nell'area primaria. L'archiviazione di backup con ridondanza locale offre almeno il 99,99999999% (11 nove) durabilità degli oggetti in un determinato anno. Per altri dettagli, vedere Concetti - Backup e ripristino. Applicabile in tutte le aree
Backup con ridondanza geografica I backup del servizio possono essere configurati come con ridondanza geografica in fase di creazione. L'abilitazione della ridondanza geografica replica i file di dati di backup del server nell'area primaria ™abbinata per offrire resilienza a livello di area. L'archiviazione di backup con ridondanza geografica offre almeno il 99,999999999999999% (16 nove) durabilità degli oggetti in un determinato anno. Per altri dettagli, vedere Concetti - Backup e ripristino. Disponibile in tutte le aree abbinate di Azure
Disponibilità elevata di ridondanza della zona Il servizio può essere distribuito in modalità a disponibilità elevata, che distribuisce server primario e standby in due diverse zone di disponibilità all'interno di un'area. La disponibilità elevata con ridondanza della zona protegge da errori a livello di zona e consente anche di ridurre i tempi di inattività delle applicazioni durante gli eventi di tempo di inattività pianificati e non pianificati. I dati del server primario vengono replicati in modo sincrono nella replica di standby. Durante un evento di inattività, viene eseguito automaticamente il failover del server di database nella replica di standby. Per altri dettagli, vedere Concetti - Disponibilità elevata. Supportato nei livelli di calcolo per utilizzo generico e Business Critical. Disponibile solo nelle aree in cui sono disponibili più zone.
Condivisioni file Premium I file di database vengono archiviati in condivisioni file Premium di Azure altamente durevoli e affidabili che offrono ridondanza dei dati con tre copie di replica archiviate all'interno di una zona di disponibilità con funzionalità di ripristino automatico dei dati. Per altri dettagli, vedere Condivisioni file Premium. Dati archiviati all'interno di una zona di disponibilità

Mitigazione del tempo di inattività pianificata

Ecco alcuni scenari di manutenzione pianificata che comportano tempi di inattività:

Scenario Processo
Ridimensionamento del calcolo (utente) Quando si esegue l'operazione di ridimensionamento del calcolo, viene effettuato il provisioning di un nuovo server flessibile usando la configurazione di calcolo con scalabilità orizzontale. Nel server di database esistente, i checkpoint attivi sono autorizzati a completare, le connessioni client vengono svuotate, tutte le transazioni di cui non è stato eseguito il commit vengono annullate e quindi vengono arrestate. L'archiviazione viene quindi collegata al nuovo server e il database viene avviato, che esegue il ripristino, se necessario, prima di accettare le connessioni client.
Nuova distribuzione software (Azure) Le nuove funzionalità di implementazione o correzioni di bug vengono eseguite automaticamente come parte della manutenzione pianificata del servizio ed è possibile pianificare quando si verificano tali attività. Per altre informazioni, vedere la documentazione e controllare anche il portale
Aggiornamenti delle versioni secondarie (Azure) Database di Azure per MySQL server flessibile applica automaticamente patch ai server di database alla versione secondaria determinata da Azure. Si verifica come parte della manutenzione pianificata del servizio. Ciò comporta un breve tempo di inattività in termini di secondi e il server di database viene riavviato automaticamente con la nuova versione secondaria. Per altre informazioni, vedere la documentazione e controllare anche il portale.

Quando il server flessibile è configurato con disponibilità elevata con ridondanza della zona, il server flessibile esegue prima le operazioni sul server standby e quindi sul server primario senza failover. Per altri dettagli, vedere Concetti - Disponibilità elevata.

Mitigazione dei tempi di inattività non pianificati

I tempi di inattività non pianificati possono verificarsi a causa di errori imprevisti, inclusi errori hardware sottostanti, problemi di rete e bug software. Se il server di database diventa inattivo in modo imprevisto, se configurato con disponibilità elevata ,la replica di standby viene attivata. In caso contrario, viene eseguito automaticamente il provisioning di un nuovo server di database. Anche se non è possibile evitare tempi di inattività non pianificati, il server flessibile riduce il tempo di inattività eseguendo automaticamente operazioni di ripristino a livello di server di database e di archiviazione senza richiedere l'intervento umano.

Tempi di inattività non pianificati: scenari di errore e ripristino del servizio

Ecco alcuni scenari di errore non pianificati e il processo di ripristino:

Scenario Processo di ripristino [non a disponibilità elevata] Processo di ripristino [disponibilità elevata]
Errore del server di database Se il server di database è inattivo a causa di un errore hardware sottostante, le connessioni attive vengono eliminate e le transazioni in corso vengono interrotte. Azure tenta di riavviare il server di database. Se l'operazione ha esito positivo, viene eseguito il ripristino del database. Se il riavvio non riesce, viene eseguito un tentativo di riavvio del server di database in un altro nodo fisico.

Il tempo di ripristino (RTO) dipende da vari fattori, tra cui l'attività al momento dell'errore, ad esempio transazioni di grandi dimensioni e la quantità di recupero da eseguire durante il processo di avvio del server di database. L'RPO è zero perché non è prevista alcuna perdita di dati per le transazioni di cui è stato eseguito il commit. Le applicazioni che usano i database MySQL devono essere compilate in modo da rilevare e ripetere le connessioni eliminate e le transazioni non riuscite. Quando l'applicazione ritenta, le connessioni vengono indirizzate al server di database appena creato.

Altre opzioni disponibili vengono ripristinate dal backup. È possibile usare sia il ripristino temporizzato che quello geografico dall'area abbinata.
PITR : RTO: Varia, RPO=0sec
Ripristino geografico: RTO: varia RPO <1 h.

È anche possibile usare la replica in lettura come soluzione di ripristino di emergenza. È possibile arrestare la replica, che rende la replica in lettura read-write (autonoma e quindi reindirizzare il traffico dell'applicazione a questo database). L'obiettivo RTO nella maggior parte dei casi è di pochi minuti e RPO < 1 h. 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.		 Se vengono rilevati errori del server di database o errori non ripristinabili, il server di database di standby viene attivato, riducendo così il tempo di inattività. Per altri dettagli, vedere la pagina concetti relativi alla disponibilità elevata. L'RTO dovrebbe essere di 60-120 s, con RPO=0.

Nota: le opzioni per il processo di ripristino [non a disponibilità elevata] sono applicabili anche qui.
errore di Archiviazione Le applicazioni non riscontrano alcun impatto sui problemi correlati all'archiviazione, ad esempio un errore del disco o un danneggiamento di blocchi fisici. Poiché i dati vengono archiviati in tre copie, la copia dei dati viene servita dall'archiviazione sopravvissuta. I danneggiamenti dei blocchi vengono corretti automaticamente. Se una copia dei dati viene persa, viene creata automaticamente una nuova copia dei dati.

In uno scenario raro o peggiore se tutte le copie sono danneggiate, è possibile usare il ripristino dal ripristino geografico (area abbinata). RPO sarà < 1 h e RTO varia.

È anche possibile usare la replica in lettura come soluzione di ripristino di emergenza come descritto in precedenza.		 Per questo scenario, le opzioni sono uguali a per il processo di ripristino [non a disponibilità elevata] .
Errori logici/utente Il ripristino da errori utente, ad esempio tabelle eliminate accidentalmente o dati aggiornati in modo non corretto, comporta l'esecuzione di un ripristino temporizzato (PITR), ripristinando e ripristinando i dati fino al momento precedente all'errore.

È possibile ripristinare una risorsa server flessibile eliminata entro cinque giorni dal momento dell'eliminazione del server. Per una guida dettagliata su come ripristinare un server eliminato, [vedere i passaggi documentati] (.. /flexible-server/how-to-restore-dropped-server.md). Per proteggere le risorse del server dopo la distribuzione da modifiche accidentali o impreviste, gli amministratori possono usare i blocchi di gestione.		 Questi errori utente non sono protetti con disponibilità elevata, perché anche tutte le operazioni utente vengono replicate nello standby. Per questo scenario, le opzioni sono uguali a per il processo di ripristino [non a disponibilità elevata]
Errore nella zona di disponibilità Anche se si tratta di un evento raro, se si vuole eseguire il ripristino da un errore a livello di zona, è possibile eseguire il ripristino geografico da a un'area abbinata. RPO sarà <1 h e RTO varia.

È anche possibile usare la replica in lettura come soluzione di ripristino di emergenza creando la replica in un'altra zona di disponibilità. RTO\RPO è simile a quanto descritto in precedenza.		 Se è stata abilitata la disponibilità elevata con ridondanza della zona, il server flessibile esegue il failover automatico nel sito di standby. Per altri dettagli, vedere Concetti relativi alla disponibilità elevata. L'RTO dovrebbe essere di 60-120 s, con RPO=0.

Altre opzioni disponibili vengono ripristinate dal backup. È possibile usare sia il ripristino temporizzato che quello geografico dall'area abbinata.
PITR: RTO: Varia, RPO=0 sec
Ripristino geografico: RTO: varia, RPO <1 h

Nota: se la disponibilità elevata nella stessa zona è abilitata, le opzioni sono identiche a quella del processo di ripristino [non a disponibilità elevata].
Errore dell'area Anche se si tratta di un evento raro, se si vuole eseguire il ripristino da un errore a livello di area, è possibile eseguire il ripristino del database creando un nuovo server usando il backup con ridondanza geografica più recente disponibile nella stessa sottoscrizione per ottenere i dati più recenti. Nell'area selezionata viene distribuito un nuovo server flessibile. Il tempo necessario per il ripristino dipende dal backup precedente e dal numero di log delle transazioni da ripristinare. RPO nella maggior parte dei casi sarebbe <1 h e RTO varia. Per questo scenario, le opzioni sono uguali a per il processo di ripristino [non a disponibilità elevata] .

Requisiti e limitazioni

Residenza dei dati dell'area

Per impostazione predefinita, Database di Azure per MySQL server flessibile 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 configurare la replica tra aree per l'archiviazione dei dati in un'altra area.

Passaggi successivi