Disponibilità elevata in Database di Azure per MySQL

  • Articolo

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

Importante

Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?

Il servizio Database di Azure per MySQL offre un elevato livello di disponibilità garantito con il contratto di servizio (SLA) supportato finanziariamente del 99,99%. Database di Azure per MySQL offre disponibilità elevata durante eventi pianificati, ad esempio l'operazione di calcolo della scalabilità avviata dall'utente e anche quando si verificano eventi non pianificati, ad esempio hardware, software o errori di rete sottostanti. Database di Azure per MySQL può eseguire rapidamente il ripristino dalla maggior parte delle circostanze critiche, garantendo praticamente nessun tempo di inattività dell'applicazione quando si usa questo servizio.

Database di Azure per MySQL è adatto per l'esecuzione di database cruciali che richiedono tempi di attività elevati. Basato sull'architettura di Azure, il servizio ha funzionalità di disponibilità elevata, ridondanza e resilienza intrinseche per ridurre i tempi di inattività del database da interruzioni pianificate e non pianificate, senza che sia necessario configurare componenti aggiuntivi.

Componenti in Database di Azure per MySQL

Componente Descrizione
My database SQL Server Database di Azure per MySQL offre sicurezza, isolamento, misure di sicurezza delle risorse e funzionalità di riavvio rapido per i server di database. Queste funzionalità facilitano operazioni come il ridimensionamento e l'operazione di ripristino del server di database dopo un'interruzione in 60-120 secondi a seconda dell'attività transazionale nel database.
Le modifiche ai dati nel server di database si verificano in genere nel contesto di una transazione di database. Tutte le modifiche al database vengono registrate in modo sincrono sotto forma di log write-ahead (ib_log) in Archiviazione di Azure, collegato al server di database. Durante il processo di checkpoint del database, anche le pagine di dati della memoria del server di database vengono scaricate nella risorsa di archiviazione.
Remote Archiviazione Tutti i file di dati fisici e i file di log mySQL vengono archiviati in Archiviazione di Azure, progettato per archiviare tre copie dei dati all'interno di un'area per garantire ridondanza dei dati, disponibilità e affidabilità. Il livello di archiviazione è anche indipendente dal server di database. Può essere scollegato da un server di database non riuscito e ricollegato a un nuovo server di database entro 60 secondi. Inoltre, Archiviazione di Azure monitora continuamente eventuali errori di archiviazione. Se viene rilevato un danneggiamento del blocco, viene risolto automaticamente creando un'istanza di una nuova copia di archiviazione.
Gateway Il gateway funge da proxy di database, instrada tutte le connessioni client al server di database.

Mitigazione del tempo di inattività pianificata

Database di Azure per MySQL è progettato per offrire disponibilità elevata durante le operazioni di inattività pianificate.

view of Elastic Scaling in Azure MySQL

Ecco alcuni scenari di manutenzione pianificata:

Scenario Descrizione
Aumento/riduzione delle prestazioni di calcolo Quando l'utente esegue un'operazione di aumento/riduzione delle prestazioni di calcolo, viene effettuato il provisioning di un nuovo server di database usando la configurazione di calcolo con scalabilità orizzontale. Nel server di database precedente, 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. Lo spazio di archiviazione viene quindi scollegato dal server di database precedente e collegato al nuovo server di database. Quando l'applicazione client ritenta la connessione o tenta di stabilire una nuova connessione, il gateway indirizza la richiesta di connessione al nuovo server di database.
Aumento delle prestazioni Archiviazione La scalabilità verticale dell'archiviazione è un'operazione online e non interrompe il server di database.
Nuova distribuzione software (Azure) Le nuove funzionalità di implementazione o correzioni di bug vengono eseguite automaticamente come parte della manutenzione pianificata del servizio. Per altre informazioni, vedere la documentazione e controllare anche il portale.
Aggiornamenti delle versioni secondarie Database di Azure per MySQL applica automaticamente patch ai server di database alla versione secondaria determinata da Azure. Si verifica come parte della manutenzione pianificata del servizio. Durante la manutenzione pianificata, possono essere presenti riavvii o failover del server di database, che potrebbero causare brevi indisponibilità dei server di database per gli utenti finali. Database di Azure per MySQL server sono in esecuzione in contenitori, in modo che i riavvii del server di database siano in genere veloci, in genere vengono completati in 60-120 secondi. L'intero evento di manutenzione pianificata, incluso ogni riavvio del server, viene monitorato attentamente dal team di progettazione. Il tempo di failover del server dipende dal tempo di ripristino del database, che può causare la modalità online del database più a lungo se si dispone di attività transazionali pesanti sul server al momento del failover. Per evitare tempi di riavvio più lunghi, è consigliabile evitare transazioni a esecuzione prolungata (caricamenti bulk) durante gli eventi di manutenzione pianificata. Per altre informazioni, vedere la documentazione e controllare anche il portale.

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 si arresta in modo imprevisto, viene eseguito automaticamente il provisioning di un nuovo server di database in 60-120 secondi. L'archiviazione remota viene collegata automaticamente al nuovo server di database. Il motore MySQL esegue l'operazione di ripristino usando i file WAL e di database e apre il server di database per consentire ai client di connettersi. Le transazioni di cui non è stato eseguito il commit vengono perse e devono essere ritentate dall'applicazione. Anche se non è possibile evitare tempi di inattività non pianificati, Database di Azure per MySQL riduce il tempo di inattività eseguendo automaticamente operazioni di ripristino a livello di server di database e di archiviazione senza richiedere l'intervento umano.

view of High Availability in Azure MySQL

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

Ecco alcuni scenari di errore e il modo in cui Database di Azure per MySQL viene ripristinato automaticamente:

Scenario Ripristino automatico
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. Viene distribuito automaticamente un nuovo server di database e l'archiviazione dati remota viene collegata al nuovo server di database. Al termine del ripristino del database, i client possono connettersi al nuovo server di database tramite il gateway.

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, il gateway reindirizza in modo trasparente la connessione al server di database appena creato.
errore di Archiviazione Le applicazioni non riscontrano alcun impatto sui problemi correlati all'archiviazione, ad esempio un errore del disco o un danneggiamento del blocco fisico. Poiché i dati vengono archiviati in 3 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.

Ecco alcuni scenari di errore che richiedono l'azione dell'utente per il ripristino:

Scenario Piano di ripristino
Errore dell'area L'errore di un'area è un evento raro. Tuttavia, se è necessaria la protezione da un errore dell'area, è possibile configurare una o più repliche in lettura in altre aree per il ripristino di emergenza.If you need protection from a region failure, you can configure one or more read replicas in other regions for disaster recovery (DR). Per informazioni dettagliate, vedere questo articolo sulla creazione e la gestione delle repliche in lettura. In caso di errore a livello di area, è possibile alzare di livello manualmente la replica di lettura configurata nell'altra area in modo che sia il server di database di produzione.
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.

Se si desidera ripristinare solo un subset di database o tabelle specifiche anziché tutti i database nel server di database, è possibile ripristinare il server di database in una nuova istanza, esportare le tabelle tramite mysqldump e quindi usare il ripristino per ripristinare tali tabelle nel database.

Riepilogo

Database di Azure per MySQL offre funzionalità di riavvio rapido dei server di database, dell'archiviazione ridondante e del routing efficiente dal gateway. Per una protezione aggiuntiva dei dati, è possibile configurare i backup per la replica geografica e distribuire anche una o più repliche in lettura in altre aree. Con funzionalità di disponibilità elevata intrinseche, Database di Azure per MySQL protegge i database dalle interruzioni più comuni e offre un contratto di servizio leader del settore, supportato dal 99,99% del tempo di attività. Tutte queste funzionalità di disponibilità e affidabilità consentono ad Azure di essere la piattaforma ideale per eseguire applicazioni cruciali.

Passaggi successivi