Condividi tramite

Affidabilità in Database di Azure per MySQL

Database di Azure per MySQL è un servizio di database completamente gestito progettato per offrire un controllo granulare e flessibilità sulle funzioni di gestione del database e sulle impostazioni di configurazione. Il servizio offre funzionalità di disponibilità elevata e ripristino di emergenza in base alle esigenze.

Quando si usa Azure, reliability è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare resilienza e ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere Database di Azure per MySQL resiliente a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità, interruzioni dell'area e manutenzione del servizio. Descrive anche come usare i backup per il ripristino da altri tipi di problemi ed evidenzia alcune informazioni chiave sul contratto di servizio Database di Azure per MySQL.

Raccomandazioni per la distribuzione di produzione

Per informazioni su come distribuire Database di Azure per MySQL per supportare i requisiti di affidabilità della soluzione e su come l'affidabilità influisce su altri aspetti dell'architettura, vedere Architecture best practices for Database di Azure per MySQL in Azure Well-Architected Framework.

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

Quando si lavora con Database di Azure per MySQL, si distribuisce un server, che rappresenta le risorse di calcolo e di archiviazione necessarie per supportare il server di database. Distribuisci uno o più database sul server.

È possibile distribuire server in più livelli di calcolo: burstable, per utilizzo generico e ottimizzato per la memoria, ognuno dei quali è ottimizzato per diversi tipi di carichi di lavoro.

Per altre informazioni sull'architettura del servizio generale e sui modelli di distribuzione, vedere Che è Database di Azure per MySQL?.

Architettura fisica

  • Separazione tra calcolo e archiviazione: Database di Azure per MySQL usa un'architettura di separazione delle risorse di calcolo e archiviazione per supportare la disponibilità elevata. Il motore di database viene eseguito in una macchina virtuale. I file di dati vengono archiviati in Archiviazione di Azure, che mantiene in modo sincrono tre copie dei dati per proteggersi da errori hardware di archiviazione. A seconda della configurazione a disponibilità elevata del server, i file di dati possono essere archiviati nell'archiviazione con ridondanza della zona o nell'archiviazione con ridondanza locale.

  • Disponibilità elevata: Facoltativamente, è possibile abilitare una configurazione a disponibilità elevata nel server. Quando si abilita la configurazione a disponibilità elevata, il servizio effettua il provisioning e gestisce un server di replica warm standby. Le modifiche ai dati nel server primario vengono replicate in modo sincrono nel server di replica standby per garantire una perdita di dati pari a zero durante un errore del server primario.

    L'architettura separa il livello di calcolo dal livello di archiviazione, consentendo al servizio di gestire in modo appropriato diversi tipi di errori. Per una maggiore resilienza, è possibile distribuire i server tra zone di disponibilità.

    Un server di replica standby viene distribuito nella stessa configurazione della macchina virtuale del server primario, inclusi vCore, archiviazione e impostazioni di rete.

    È possibile passare da un server all'altro eseguendo un failover. Esistono due tipi di failover: failover non pianificati, che vengono usati quando il server primario ha esito negativo e failover pianificati, usati in altri scenari in cui è necessario ridurre al minimo il tempo di inattività dell'applicazione durante un failover.

    Per altre informazioni, vedere Disponibilità elevata in Database di Azure per MySQL.

  • Backups: Database di Azure per MySQL crea automaticamente i backup del server. Per altre informazioni, vedere Backup e ripristino.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le linee guida per la gestione degli errori temporanei Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Le applicazioni devono gestire errori di connettività temporanei che possono verificarsi durante la manutenzione, il ridimensionamento delle operazioni o le interruzioni di rete. Seguire queste raccomandazioni:

  • Quando l'applicazione rileva errori temporanei, ripetere l'operazione usando il backoff esponenziale. Aumentare il ritardo tra i tentativi e limitare il numero di tentativi. Se l'operazione ha ancora esito negativo dopo i tentativi massimi, considerarla come un errore.
  • Se possibile, utilizzare librerie client che gestiscono automaticamente i nuovi tentativi.
  • Gli errori temporanei che si verificano durante le operazioni di scrittura richiedono una considerazione più attenta. Valutare la possibilità di rendere idempotenti le operazioni di scrittura, in modo che possano essere eseguite più volte in modo sicuro.

Resilienza ai guasti delle zone di disponibilità

Zone di disponibilità sono gruppi fisicamente separati di data center all'interno di un'area Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

È possibile selezionare il tipo di supporto della zona di disponibilità tramite la configurazione a disponibilità elevata. L'abilitazione della disponibilità elevata distribuisce un server di replica standby insieme al server primario. Questo modello di disponibilità elevata consente di garantire che i dati di cui è stato eseguito il commit non vengano mai persi durante gli errori. Indipendentemente dal modello di distribuzione a disponibilità elevata scelta, i dati vengono sottoposti a commit sincrono sia nei server di replica primario che in standby. Se si verifica un'interruzione del server primario, il server esegue automaticamente il failover nel server di replica di standby.

I dati vengono archiviati su archiviazione Premium di File di Azure. A seconda della configurazione a disponibilità elevata del server, usa l'archiviazione con ridondanza di zona o l'archiviazione con ridondanza locale, che conserva tre copie di dati all'interno o tra zone di disponibilità.

Database di Azure per MySQL supporta due tipi di configurazione della zona di disponibilità quando si usa la disponibilità elevata:

  • Disponibilità elevata con ridondanza della zona: La ridondanza della zona offre il massimo livello di resilienza della zona distribuendo un server primario in un'unica zona di disponibilità e un server di replica di standby in una zona di disponibilità diversa. Il server di replica standby usa una configurazione di calcolo, archiviazione e rete simile a quella primaria. Una configurazione con ridondanza della zona fornisce l'isolamento fisico dell'intero stack tra i server primari e di standby.

    Selezionare le zone di disponibilità per i server primario e standby.

    È consigliabile usare distribuzioni con ridondanza della zona per i server di produzione.

    Le operazioni di scrittura possono riscontrare un piccolo aumento della latenza di commit perché il servizio replica in modo sincrono i dati nel server di standby. In media, è possibile prevedere un aumento della latenza del 5-10% per le operazioni di scrittura e commit dell'applicazione, ma l'impatto varia in base al carico di lavoro, allo SKU selezionato e all'area.

  • Disponibilità elevata con ridondanza locale: I server primario e standby usano la stessa zona di disponibilità. Se si verifica un'interruzione del server primario, ma la zona è ancora integra, il server esegue automaticamente il failover nel server di standby.

    Una distribuzione con ridondanza locale offre disponibilità elevata all'interno di una singola zona di disponibilità. Protegge l'utente da errori a livello di nodo e consente anche di ridurre i tempi di inattività dell'applicazione durante gli eventi di tempo di inattività pianificati e non pianificati. Tuttavia, non protegge da un'interruzione in tale zona. Nelle aree con zone di disponibilità, questo tipo di configurazione viene talvolta definito anche zonale o singola zona.

    È consigliabile la disponibilità elevata con ridondanza locale solo in scenari specifici:

    • Quando si dispone di applicazioni insolitamente sensibili alla latenza, è stata convalidata la necessità di ridurre al minimo la latenza tra la replica primaria e secondaria ed è stata pianificata la resilienza della zona usando altri approcci architetturali.
    • Quando si esegue la distribuzione in un'area che non supporta le zone di disponibilità, l'area funziona in modo efficace come singola zona, rendendo la disponibilità elevata con ridondanza locale l'unica opzione a disponibilità elevata.

    Poiché i server si trovano nella stessa zona, può ridurre la latenza di scrittura nelle applicazioni distribuite all'interno di tale zona.

Se si configura il server senza disponibilità elevata, viene eseguito in un singolo server. Se il server o la relativa zona diventa inattivo, il server non è disponibile.

Requisiti

  • Il supporto delle regioni: il supporto di Database di Azure per MySQL per le configurazioni delle zone di disponibilità differisce tra le regioni di Azure. Per un elenco completo delle aree e dei tipi di supporto della zona di disponibilità e per eventuali considerazioni specifiche per tale area, vedere Azure aree.

  • Livello di servizio: La disponibilità elevata richiede livelli per utilizzo generico o ottimizzato per la memoria. Il livello burstable non supporta la disponibilità elevata (con ridondanza della zona o con ridondanza locale).

Cost

Quando si abilita la disponibilità elevata, il server di standby viene creato e fatturato con la stessa tariffa del server primario. La configurazione della zona di disponibilità non influisce sul costo. Non sono previsti addebiti per la replica dei dati all'interno o tra le zone di disponibilità. A seconda del volume di memoria di backup, potrebbe esserti addebitata anche la memoria di backup. Per informazioni dettagliate sui prezzi, vedere prezzi di Database di Azure per MySQL.

Considerazioni

  • Chiavi primarie: È consigliabile usare chiavi primarie in tutte le tabelle, perché questo approccio riduce il tempo di replica e failover.
  • Limitazioni e problemi noti: Esaminare l'elenco delle limitazioni e deiproblemi noti.

Configurare il supporto delle zone di disponibilità

Per configurare il supporto della zona di disponibilità per un server, configurare le impostazioni di disponibilità elevata.

Annotazioni

Quando si selezionano le zone di disponibilità da usare, si seleziona effettivamente la zona di disponibilità logica. Se si distribuiscono altri componenti del carico di lavoro in una sottoscrizione Azure diversa, è possibile usare un numero di zona di disponibilità logico diverso per accedere alla stessa zona di disponibilità fisica. Per altre informazioni, vedere Zone di disponibilità fisiche e logiche.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando i server sono configurati con supporto per l'alta disponibilità e il supporto per le zone di disponibilità e tutte le zone di disponibilità sono operative.

  • Operazione tra zone: Le applicazioni client MySQL si connettono al server primario usando il nome di dominio completo (FQDN) del server di database. Evitare di usare l'indirizzo IP del server primario perché l'indirizzo IP può cambiare, incluso durante i failover.

    Database di Azure per MySQL usa una configurazione attiva/passiva in cui tutte le connessioni e le query del database vengono gestite dal server primario nella zona di disponibilità primaria. Il server di replica standby non gestisce il traffico client durante le normali operazioni.

  • Replica dei dati tra zone: Le scritture vengono sottoposte a commit nel server primario e scritte in modo sincrono nei log per il server di standby usando ZRS. Il server primario non attende che il server standby applichi i log, ma, poiché i log si trovano in una Redondanza a Zone (ZRS), sono disponibili anche se si verifica un errore di replica o di zona.

    Gli effetti della replica sono diversi a seconda della configurazione della zona di disponibilità usata dal server:

    • Ridondanza della zona: Poiché i server si trovano in zone separate, questo approccio garantisce una perdita di dati pari a zero durante un errore di zona. Questa situazione è nota anche come raggiungimento di un obiettivo del punto di ripristino (RPO) pari a zero per gli errori di zona.

      Tuttavia, la replica tra zone potrebbe introdurre una piccola quantità di latenza aggiuntiva. In media, è possibile prevedere un aumento della latenza del 5-10% per le operazioni di scrittura e commit dell'applicazione, ma l'impatto varia in base al carico di lavoro, allo SKU selezionato e all'area.

    • Ridondanza locale: non viene replicato alcun traffico tra le zone.

    Annotazioni

    Il sistema replica tutte le modifiche in tempo reale al server di replica standby, inclusi errori utente imprevisti, ad esempio un rilascio accidentale di una tabella o aggiornamenti non corretti dei dati. A causa della replica immediata, non è possibile usare la replica di standby per il ripristino. Per recuperare dagli errori dell'utente, è necessario eseguire un ripristino a un punto specifico nel tempo da un backup. Per altre informazioni, vedere Backup e ripristino.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando i server sono configurati con supporto per l'alta disponibilità e per le zone di disponibilità e si verifica un'interruzione della zona di disponibilità.

  • Rilevamento e risposta: Azure controlla periodicamente l'integrità dei server principale e di riserva. Dopo diversi ping, se il monitoraggio dell'integrità rileva che un server primario non è raggiungibile, il servizio avvia un failover automatico verso il server di standby. L'algoritmo di monitoraggio della salute utilizza più dati per evitare situazioni di falsi positivi.

    In caso di errore di zona, il comportamento è diverso a seconda della configurazione della zona di disponibilità usata dal server:

    • Zone-redundant: Database di Azure per MySQL rileva automaticamente gli errori della zona di disponibilità monitorando continuamente più endpoint server. Per ulteriori informazioni, vedere Funzionamento del rilevamento automatico del failover nei server abilitati per l'alta disponibilità.

      Per visualizzare i possibili tipi di stato di disponibilità elevata, vedere Monitorare la disponibilità elevata. Quando una zona ha esito negativo, Azure avvia un failover non pianificato al server di standby senza che sia necessario intervenire.

    • Ridondanza locale: I server primario e standby non sono disponibili se la zona di disponibilità che ospita un server con ridondanza locale non è più disponibile. In questo scenario, il servizio non fornisce il failover automatico. Sei responsabile del rilevamento dell'interruzione della zona e dell'esecuzione di azioni di ripristino, ad esempio il ripristino di backup a ridondanza di zona in un server separato in un'altra zona o regione di disponibilità.

  • Notification: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Azure Integrità risorse per monitorare l'integrità di una singola risorsa ed è possibile configurare Integrità risorse avvisi per segnalare eventuali problemi. È anche possibile usare integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità Servizi per notificare i problemi.

    Database di Azure per MySQL genera un evento Azure Integrità risorse quando si verifica un failover non pianificato.

  • Richieste attive: Quando una zona di disponibilità non è più disponibile, le richieste in corso ai server nella zona interessata potrebbero essere terminate. Le applicazioni devono ritentare queste richieste. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

  • Perdita di dati prevista: La quantità di perdita di dati dipende dalla configurazione della zona di disponibilità del server.

    • Zone-redundant: Nessuna perdita di dati è prevista durante il failover della zona grazie alla replica sincrona tra il server primario e quello di standby in zone diverse.

    • Ridondanza locale: I dati nei server nella zona interessata non sono disponibili fino al ripristino della zona.

  • Tempo di inattività previsto: La quantità di tempo di inattività dipende dalla configurazione della zona di disponibilità usata dal server.

    • Ridondanza della zona: Il failover viene in genere completato entro 60-120 secondi. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

    • Ridondanza locale: I server in una zona interessata non sono disponibili fino al ripristino della zona di disponibilità.

  • Ridistribuzione: Il comportamento di reindirizzamento del traffico dipende dalla configurazione della zona di disponibilità usata dal server.

    • Ridondanza della zona: Dopo il failover, il server di standby precedente diventa il nuovo server primario e inizia ad accettare nuove connessioni. Azure stabilisce automaticamente un server di standby nella zona primaria originale dopo il ripristino. Per informazioni dettagliate, vedere Failover non pianificato.

    • Ridondanza locale: Quando una zona non è disponibile, il server non è disponibile. Se si dispone di un server separato creato in un'altra zona o area di disponibilità, si è responsabili del reindirizzamento del traffico a tale server.

Ripristino della zona

Il comportamento di ripristino della zona dipende dalla configurazione della zona di disponibilità usata dal server.

  • Zone-redundant: Quando la zona di disponibilità viene ripristinata, Database di Azure per MySQL ricompila automaticamente il server di standby nella zona ripristinata e lo sincronizza con il database primario corrente. La zona ripristinata funge quindi da posizione di standby. Il servizio non sposta automaticamente il ruolo primario nella zona originale per evitare interruzioni non necessarie. È possibile avviare manualmente un failover pianificato se si desidera restituire il database primario alla zona originale.

  • Ridondanza locale: Dopo che la zona è operativa, i server nella zona sono nuovamente disponibili. L'utente è responsabile delle procedure di ripristino della zona e della sincronizzazione dei dati richiesta dai carichi di lavoro.

Verifica dei guasti di zona

Le opzioni per il test per gli errori di zona dipendono dalla configurazione della zona di disponibilità usata dall'istanza.

  • Zone-redundante: Puoi testare la resilienza della tua applicazione al failover avviando un failover pianificato. Un failover pianificato consente di simulare uno scenario di interruzione non pianificato durante l'esecuzione del carico di lavoro e osservare il tempo di inattività dell'applicazione. È consigliabile eseguire simulazioni in un ambiente non di produzione o in un momento non di produzione. Per altre informazioni, vedere Failover pianificato.

  • Ridondanza locale: Anche se non è possibile simulare un'interruzione completa della zona, è possibile simulare che il server non sia disponibile in modo analogo a quello che accade durante un'interruzione della zona. Per ulteriori informazioni, vedere:

Resilienza agli errori a livello di area

Database di Azure per MySQL supporta repliche di lettura su più aree , che è possibile usare per mantenere una copia sincronizzata del database in un'area diversa per un ripristino più rapido.

È anche possibile usare i backup con ridondanza geografica, nelle aree supportate, per fornire il ripristino tra aree. Tuttavia, i backup comportano in genere tempi di inattività e perdita di dati maggiori rispetto alla replica. Per altre informazioni, vedere Backup e ripristino.

Repliche di lettura tra regioni

È possibile distribuire repliche in lettura per proteggere i database da errori a livello di area. Ogni replica di lettura è un server Database di Azure per MySQL separato. Quando si inserisce una "read replica" in una seconda area di Azure, il server di database può garantire resilienza contro problemi che interessano l'intera regione. È possibile distribuire fino a dieci repliche in lettura, che possono essere facoltativamente in aree Azure diverse. La tecnologia di replica fisica di MySQL aggiorna le repliche di lettura in modo asincrono dal server di origine nella regione primaria e possono avere un ritardo rispetto alla sorgente. Le repliche di lettura tra aree possono opzionalmente servire attività di sola lettura per ridurre la latenza delle applicazioni distribuite a livello globale o per deviare il traffico di lettura dal server di origine. Per altre informazioni sulle funzionalità di replica in lettura e sulle considerazioni, vedere Repliche in lettura.

Se l'area primaria ha esito negativo, è possibile eseguire manualmente il failover in modo che la replica secondaria diventi il server primario. A tale scopo, arrestare il processo di replica, che promuove la replica di lettura come server di lettura/scrittura. A causa della replica asincrona, il failover può comportare la perdita di dati. L'applicazione deve quindi connettersi al nuovo server primario ed è responsabile della riconfigurazione dell'applicazione.

Annotazioni

Questa sezione riepiloga alcune informazioni chiave su come le repliche di lettura possono supportare la resilienza ai guasti su scala regionale. È anche possibile usare repliche in lettura per migliorare le prestazioni e supportare basi utente geograficamente distribuite su grande scala. Per altre informazioni, vedere Leggere le repliche.

Requisiti

  • Supporto regione: È possibile creare repliche di lettura interregionale in qualsiasi regione che supporta Database di Azure per MySQL. Non siete limitati alle regioni accoppiate di Azure.

  • Livelli di calcolo: I livelli di calcolo ottimizzati per la memoria e per utilizzo generico supportano le repliche in lettura. Il livello burstable non supporta le repliche in lettura.

Considerazioni

  • Differenze di configurazione: Quando si crea una replica, eredita diverse impostazioni dal server di origine, tra cui la generazione di calcolo, i vCore e l'archiviazione. È possibile personalizzare questi valori nella replica di lettura una volta che è stata creata. Tuttavia, è consigliabile usare valori uguali o maggiori per assicurarsi che la replica possa mantenere il passo con le modifiche nell'origine.

  • Monitoraggio del ritardo della replica: Il processo di replica asincrona richiede un ritardo di replica, che può variare a seconda di diversi fattori. Quando il ritardo di replica è molto elevato, il server potrebbe riscontrare problemi. È importante monitorare il ritardo di replica per attenuare i problemi prima che si aggravino. Per altre informazioni, vedere Monitorare la replica.

  • Disponibilità elevata: Le repliche in lettura non possono avere la disponibilità elevata attivata e, quando vengono sottoposte a failover per diventare il server primario, non dispongono comunque di disponibilità elevata. Sei responsabile della configurazione dell'alta disponibilità dopo il passaggio a una replica.

Cost

Le repliche in lettura comportano costi di calcolo e archiviazione, nonché addebiti per il trasferimento dei dati tra regioni per la replicazione. Per informazioni dettagliate sui prezzi, vedere prezzi Database di Azure per MySQL e Bandwidth pricing.

Configurare il supporto per più aree

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando il server è configurato con una replica di lettura in un'altra area e tutte le aree sono operative:

  • Routing del traffico tra aree: Nelle normali operazioni, l'applicazione deve indirizzare il traffico in lettura/scrittura al server di origine nell'area primaria. È possibile, se desiderato, indirizzare le richieste di lettura alla replica di lettura.

  • Replica dei dati tra aree: Le repliche in lettura tra aree usano la replica asincrona per ridurre al minimo l'impatto sulle prestazioni del server di origine. La quantità di ritardo della replica dipende da diversi fattori, tra cui il carico di scrittura e la latenza tra il server di origine e le repliche. Il ritardo della replica è in genere di almeno alcuni minuti, ma può essere molto più lungo. Per altre informazioni, vedere Monitor replication e per istruzioni dettagliate, vedere Monitor replication in the Azure portal.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando il server è configurato con una replica di lettura in un'altra area ed è presente un'interruzione nell'area primaria:

  • Rilevamento e risposta: Si è responsabili del rilevamento di un'interruzione nell'area primaria e dell'attivazione manuale di un failover. Questa azione può comportare la perdita di dati non replicati.

    Importante

    L'utente è responsabile dell'attivazione del failover. Azure non esegue automaticamente il failover delle repliche di lettura, anche se si verifica un errore nell'area.

    Per il failover, è necessario che tu:

    1. Interrompere la replicazione. Si tratta di una procedura irreversibile e il server non può essere nuovamente trasformato in una replica. Il processo comporta la perdita di dati. Per altre informazioni sulle implicazioni di questa azione, vedere Arrestare la replica.
    2. Riconfigurare l'applicazione per utilizzare il nuovo primario.

    Per altre informazioni, vedere Failover.

  • Notification: Microsoft non invia automaticamente una notifica quando un'area è inattiva. Tuttavia, è possibile usare integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli errori dell'area, ed è possibile configurare gli avvisi di integrità Servizi per notificare eventuali problemi.

  • Richieste attive: Tutte le connessioni attive all'area di origine vengono eliminate se il server di origine non è disponibile. Le applicazioni devono riprovare a stabilire connessioni al nuovo server primario al termine del processo di failover.

  • Perdita di dati prevista: Durante un'interruzione dell'area, è necessario eseguire un failover che arresta la replica. Questo processo comporta la perdita permanente di tutti i dati non replicati.

    La quantità di perdita di dati dipende dal ritardo di replica al momento dell'interruzione. Il ritardo della replica è in genere di almeno alcuni minuti, ma può essere molto più lungo. Per altre informazioni, vedere Monitorare la replica.

  • Tempo di inattività previsto: L'arresto della replica viene in genere completato entro 2 minuti dall'attivazione. Si è responsabili della riconfigurazione delle applicazioni per la connessione al nuovo server primario e il tempo necessario per eseguire la riconfigurazione contribuisce anche al tempo di inattività complessivo.

  • Reindirizzamento del traffico: L'utente è responsabile della riconfigurazione delle applicazioni per la connessione al nuovo server primario.

    Annotazioni

    Dopo aver eseguito il failover di una replica di lettura per diventare il server primario, il server non ha la disponibilità elevata abilitata. È necessario abilitare manualmente la disponibilità elevata o includerla nell'automazione.

Ripristino della regione

Quando la regione viene ripristinata, si è responsabili di tutte le attività di failback al fine di riprendere le operazioni nella regione primaria. Microsoft non sposta automaticamente il server primario. È possibile creare una nuova replica di lettura nell'area primaria, quindi eseguire un altro processo di failover per ripristinare le operazioni nell'area primaria. Considerare uno degli approcci seguenti, a seconda che l'applicazione possa tollerare tempi di inattività o perdita di dati:

  • Metti l'applicazione offline e attendi che la replica si allinei a tutte le modifiche. Questo approccio richiede tempi di inattività dell'applicazione, approssimativamente uguali al ritardo della replica.
  • Esegui il failover e accetta la perdita di eventuali dati non replicati.

Tenere presente che si è anche responsabili della riconfigurazione delle applicazioni per la connessione al nuovo server primario in base alle esigenze.

Testare gli errori dell'area

Testare regolarmente le procedure di failover delle repliche in lettura per assicurarsi che i processi siano validi e che le funzionalità soddisfino i requisiti RTO e RPO.

È possibile eseguire il failover di una replica di lettura per farla diventare il server primario in qualsiasi momento, anche quando tutte le regioni sono integre. È consigliabile eseguire questi test in un ambiente non di produzione perché può comportare la perdita di dati e richiede il failback manuale.

Come parte della strategia di ripristino di disastro, eseguire regolarmente esercitazioni di recupero complete. Queste esercitazioni devono includere la convalida dei dati, i test delle funzionalità dell'applicazione e le procedure di rollback documentate.

Backup e ripristino

Database di Azure per MySQL esegue automaticamente i backup che forniscono funzionalità di ripristino temporizzato e consentono di proteggersi da danneggiamenti accidentali ed eliminazione dei dati. Microsoft gestisce completamente i backup e non interrompe la disponibilità del server, includendo sia backup completi che backup del log delle transazioni.

  • Archiviazione di backup: Se il server è configurato con alta disponibilità e ridondanza di zona, i backup vengono archiviati nell'archiviazione con ridondanza di zona. Per i server configurati senza configurazione di alta disponibilità o con alta disponibilità ridondante a livello locale, i backup vengono memorizzati nella memoria con ridondanza locale.

    In Azure aree con coppie, è possibile configurare l'archiviazione di backup con ridondanza geografica (GRS) in fase di creazione del server per replicare i backup nell'area Azure abbinata per una protezione aggiuntiva dagli errori dell'area. I backup vengono replicati in modo asincrono.

    Il periodo di conservazione dei backup predefinito è di 7 giorni, con l'opzione per estendere la conservazione fino a 35 giorni. Tutti i backup vengono crittografati.

  • Ripristinare: Il ripristino temporizzato consente di ripristinare il database in qualsiasi momento entro il periodo di conservazione dei backup. Il processo di ripristino crea un nuovo server di database con un nuovo nome server fornito dall'utente, che è quindi possibile usare as-is o copiare i dati da.

    Quando si ripristina un backup con ridondanza geografica, si crea un nuovo server nell'area abbinata. In alcune regioni, è possibile usare Universal Geo-Restore per ripristinare un backup con ridondanza geografica in una regione che non è la regione associata alla regione primaria.

    Questa funzionalità è utile per il ripristino da modifiche accidentali ai dati, errori dell'applicazione o scenari di test.

Per la maggior parte delle soluzioni, non è consigliabile basarsi esclusivamente sui backup. Usare invece le altre funzionalità descritte in questa guida per supportare i requisiti di resilienza. Tuttavia, i backup proteggono da alcuni rischi che altri approcci non comportano. Per altre informazioni, vedere Che cosa sono ridondanza, replica e backup?.

Per altre informazioni, vedere Backup e ripristino in Database di Azure per MySQL.

Resilienza alla manutenzione del servizio

Database di Azure per MySQL gestisce automaticamente le attività di manutenzione critiche, tra cui l'applicazione di patch dell'hardware, del sistema operativo e del motore di database sottostanti. Il servizio include aggiornamenti della sicurezza, aggiornamenti software e aggiornamenti delle versioni secondarie come parte della manutenzione pianificata. Per altre informazioni, vedere Scheduled maintenance in Database di Azure per MySQL.

Per assicurarsi che il server rimanga disponibile durante le finestre di manutenzione, seguire queste indicazioni:

  • Evitare operazioni di gestione durante i periodi di manutenzione: Non eseguire operazioni di gestione del server mentre è in corso la manutenzione, perché queste operazioni possono influire sull'affidabilità del server.

  • Usare la manutenzione a quasi zero tempi di inattività: Se il server dispone di alta disponibilità abilitata e soddisfa altri criteri di idoneità, le operazioni di manutenzione vengono spesso completate entro 10-30 secondi. Se è abilitata la disponibilità elevata, le operazioni di manutenzione in genere usano gli aggiornamenti in sequenza per ridurre al minimo i tempi di inattività. Le attività di manutenzione periodiche, come gli aggiornamenti della versione minore, vengono eseguite prima nella replica di standby. Per ridurre i tempi di inattività, lo standby viene alzato di livello primario in modo che i carichi di lavoro possano continuare mentre le attività di manutenzione vengono applicate al nodo rimanente. Questa sequenza si applica se il server utilizza alta disponibilità con ridondanza zonale o con ridondanza locale. Per altre informazioni, vedere Manutenzione a quasi zero interruzioni.

  • Configurare finestre di manutenzione personalizzate: È possibile configurare la pianificazione della manutenzione in modo che sia gestita dal sistema o definire una finestra di manutenzione personalizzata per ridurre al minimo l'impatto sulle operazioni aziendali. È anche possibile riprogrammare le operazioni di manutenzione pianificata. Pianificare la manutenzione durante periodi di attività ridotta per ridurre al minimo l'impatto aziendale. Per altre informazioni, vedere Gestire le impostazioni di manutenzione pianificata per Database di Azure per MySQL.

  • Implementare la logica di ripetizione dei tentativi: Assicurarsi che le applicazioni possano gestire brevi interruzioni della connettività che possono verificarsi durante i riavvii di manutenzione. Per rendere resilienti le applicazioni a questi tipi di problemi, vedere Indicazioni sulla resilienza per gli errori temporanei .

  • Abilitare la manutenzione di Virtual Canary nei server di sviluppo e test: La manutenzione canary virtuale offre accesso anticipato agli aggiornamenti. Abilitandolo nei server di sviluppo e test, è possibile verificare che il carico di lavoro non sia interessato dagli aggiornamenti futuri prima che raggiungano i server di produzione. Per ulteriori informazioni, vedere Manutenzione canarino virtuale.

Contratto di servizio

Il contratto di servizio (SLA) per Azure servizi descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per ottenere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere Accordi sul livello di servizio (SLA) per i servizi online.

Database di Azure per MySQL offre contratti di servizio di disponibilità diversi in base alla configurazione del server:

  • Server configurati con alta disponibilità ridondante tra zone.
  • Server configurati con disponibilità elevata con ridondanza locale.
  • Server configurati senza disponibilità elevata.

Contenuti correlati

  • Last updated on