Affidabilità in Database di Azure per MySQL

Database di Azure per MySQL è un servizio di database completamente gestito che offre un controllo granulare e flessibilità rispetto alle funzioni di gestione del database e alle 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 varie 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 eseguire 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

Azure Well-Architected Framework offre raccomandazioni su affidabilità, sicurezza, costi, operazioni e prestazioni. Per comprendere in che modo queste aree influiscono tra loro e contribuiscono a una soluzione di Database di Azure per MySQL affidabile, vedere Procedure consigliate per l'architettura per Database di Azure per MySQL.

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 nei tier di calcolo Burstable, General Purpose e Memory Optimized. Ogni livello di calcolo è ottimizzato per diversi tipi di carichi di lavoro.

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

Architettura fisica

• Separazione tra elaborazione e archiviazione: Database di Azure per MySQL usa un'architettura che separa elaborazione e archiviazione per supportare l'alta disponibilità. Il motore di database viene eseguito in una macchina virtuale .The database engine runs on a virtual machine (VM). 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 di disponibilità elevata del server, i file di dati possono essere archiviati in un'archiviazione con ridondanza della zona (ZRS) o in un'archiviazione con ridondanza locale (LRS).

• DISPONIBILITÀ elevata: Facoltativamente, è possibile abilitare una configurazione a disponibilità elevata nel server. Quando si attiva la configurazione HA, il servizio esegue il provisioning e gestisce un server replica in 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, che consente 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. Usare failover non pianificati quando il server primario ha esito negativo e usare failover pianificati quando è necessario ridurre al minimo i tempi di inattività dell'applicazione durante un failover.

  Per ulteriori informazioni, vedi HA 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:

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.

Seleziona il tipo di supporto per la zona di disponibilità tramite la configurazione HA. Quando si attiva l'alta disponibilità, Database di Azure per MySQL distribuisce un server di replica in standby insieme al server primario. Questo modello a disponibilità elevata garantisce 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, il servizio esegue il commit sincrono dei dati sia nei server di replica primario che in quello di standby. Se il server primario viene interrotto, il server esegue automaticamente il failover nel server di replica di standby.

Il servizio archivia i dati nell'archiviazione Premium di File di Azure. A seconda della configurazione HA del server, vengono usati ZRS o LRS, che memorizzano tre copie dei dati all’interno di una singola zona di disponibilità o tra più zone di disponibilità.

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

• Alta disponibilità con ridondanza tra zone: La ridondanza tra zone offre il massimo livello di resilienza tra zone distribuendo un server primario in una zona di disponibilità e un server replica in standby in un'altra zona di disponibilità. Il server di replica standby usa una configurazione di calcolo, archiviazione e rete simile al server primario. 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.

  Usa distribuzioni con ridondanza di zona per i server di produzione.

  

  Il diagramma è costituito da tre sezioni. La prima sezione elenca le applicazioni client, ad esempio macchine virtuali Azure, Servizio Azure Kubernetes (AKS) e Servizio app di Azure. La sezione successiva è etichettata come zona di disponibilità 1. Contiene il server primario e due sottosezioni, calcolo e archiviazione, separate da una linea tratteggiata. La terza sezione è etichettata come zona di disponibilità 2. Rispecchia la zona di disponibilità 1, ma contiene il server di standby. Le frecce puntano dalle applicazioni client a un bilanciatore del carico standard. Una freccia va dal bilanciatore del carico a una VM sul server primario nella zona di disponibilità 1. Le frecce bidirezionali connettono la macchina virtuale e la condivisione file Premium e l'unità SSD (Solid State Drive). Un'altra freccia punta dalla condivisione file Premium all'archiviazione BLOB per il backup. Una freccia etichettata "replica asincrona basata sull'archiviazione" punta dalla zona di disponibilità 1 alla zona di disponibilità 2.

  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 da 5% a 10% maggiore latenza per le operazioni di scrittura e commit dell'applicazione. L'impatto varia in base al carico di lavoro, allo SKU selezionato e all'area.

• HA a ridondanza locale: Il server primario e quello di 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 alta disponibilità all'interno di una singola zona di disponibilità. Protegge gli errori a livello di nodo e consente anche di ridurre i tempi di inattività delle applicazioni 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 a zona singola.

  

  Il diagramma è costituito da tre sezioni. La prima sezione elenca le applicazioni client come le VM di Azure, AKS e App Service. La sezione successiva è etichettata come zona di disponibilità 1. Contiene due sezioni separate per il server primario e il server di standby. Una linea tratteggiata divide la sezione di ogni server in due sottosezioni, calcolo e archiviazione. Le frecce puntano dalle applicazioni client a un bilanciatore del carico standard. Una freccia va dal bilanciatore del carico a una VM sul server primario nella zona di disponibilità 1. Le frecce bidirezionali connettono la macchina virtuale e la condivisione file Premium e l'unità SSD (Solid State Drive). Un'altra freccia punta dalla condivisione file Premium all'archiviazione BLOB di backup. Una freccia etichettata "replicazione asincrona basata sull'archiviazione" punta dal server primario al server di standby. La terza sezione, etichettata zona di disponibilità 2, è vuota.

  Utilizzare l'HA con ridondanza locale solo negli scenari seguenti:

  • Quando si dispone di applicazioni insolitamente sensibili alla latenza, è necessario verificare la necessità di ridurre al minimo la latenza tra la replica primaria e secondaria e pianificare la resilienza della zona usando altri approcci architetturali.

  • Quando si esegue la distribuzione in un'area che non supporta le zone di disponibilità. In questo scenario, la regione funziona come un'unica zona, il che rende l'alta disponibilità con ridondanza locale l'unica opzione di alta disponibilità.

  I server si trovano nella stessa zona, riducendo 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 quel server o la sua zona si guasta, il tuo server non è disponibile.

Requisiti

• Supporto dell'area: Database di Azure per MySQL supporta diverse configurazioni della zona di disponibilità a seconda dell'area Azure. Per un elenco completo delle aree, inclusi i tipi di supporto della zona di disponibilità e considerazioni specifiche per ogni area, vedere Azure aree.

• Livello di servizio: HA richiede i livelli General Purpose o Memory Optimized. Il livello Burstable non supporta l'alta disponibilità (HA) con ridondanza della zona o con ridondanza locale.

Cost

Quando si abilita l'alta disponibilità, si crea il server di standby e lo si paga alla stessa tariffa del server primario. La configurazione della zona di disponibilità non influisce sul costo. La replica dei dati non comporta addebiti 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 Database di Azure per MySQL prezzi.

Considerazioni

• Chiavi primarie: Usare chiavi primarie in tutte le tabelle perché questo approccio riduce la replica e il tempo di failover.

• Limitazioni e problemi noti: Esaminare l'elenco delle limitazioni e deiproblemi noti.

Configurare il supporto delle zone di disponibilità

Per configurare il supporto per le zone di disponibilità di un server, configurare le impostazioni HA.

• Crea un server a ridondanza di zona. Per informazioni sulla creazione di un server con alta disponibilità e ridondanza della zona abilitate, vedere i seguenti articoli:

  • Portale di Azure: Gestire l'alta disponibilità a ridondanza della zona in Database di Azure per MySQL tramite il portale di Azure.

  • interfaccia della riga di comando di Azure: Gestire l'alta disponibilità con ridondanza della zona in Database di Azure per MySQL usando interfaccia della riga di comando di Azure.

• Crea un server con ridondanza locale. Per creare un server con alta disponibilità e ridondanza locale in una singola zona di disponibilità, è necessario usare interfaccia della riga di comando di Azure o un altro metodo di distribuzione programmatico. Per le istruzioni su interfaccia della riga di comando di Azure, vedere Abilitare l'alta disponibilità durante la creazione del server.

• Modificare la configurazione della zona di disponibilità per i server esistenti. Se si dispone di un server esistente, l'approccio seguito per abilitare il supporto della zona di disponibilità dipende dalla configurazione iniziale del server.

  • Per convertire un server esistente in alta disponibilità con ridondanza della zona, è necessario eseguire la migrazione verso un nuovo server. Per altre informazioni, vedere Eseguire la migrazione da un server esistente a un server a zone ridondanti.

  • Per modificare un server esistente in HA con ridondanza locale:

    1. Disabilita HA, se è abilitata.

    2. Abilita l'alta disponibilità con ridondanza locale. È necessario usare il interfaccia della riga di comando di Azure o un altro metodo di distribuzione a livello di codice. Per istruzioni sull'interfaccia della riga di comando di Azure, vedi Gestire l'alta disponibilità con ridondanza della zona in Database di Azure per MySQL usando l'interfaccia della riga di comando di Azure.

• Disattiva HA. La disabilitazione della disponibilità elevata rimuove il server di replica standby, quindi il server non è resiliente alle interruzioni a livello di zona. Tuttavia, se i backup con ridondanza geografica sono abilitati, è comunque possibile ripristinare il server in un'area diversa usando tali backup. Per ulteriori informazioni, consultare Disabilitare l'alta disponibilità.

Comportamento quando tutte le zone sono integre

Questa sezione descrive che cosa aspettarsi quando si configurano i server con supporto per HA e 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 il server primario gestisce tutte le connessioni e le query del database nella zona di disponibilità primaria. Il server di replica standby non gestisce il traffico client durante le normali operazioni.

• Replicazione dei dati tra zone: Le scritture vengono confermate sul server primario e scritte in modo sincrono nei log del 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 da 5% a 10% maggiore latenza 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: Nessun traffico viene replicato 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 che cosa aspettarsi quando si configurano server con supporto per l'alta disponibilità e per le zone di disponibilità e si verifica un'interruzione in una zona di disponibilità.

• Rilevamento e risposta: Azure controlla periodicamente l'integrità dei server primario e standby. 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.

  Se si verifica un errore di zona, il comportamento varia 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 altre informazioni, vedere Funzionamento del rilevamento automatico del failover nei server abilitati per la disponibilità elevata.

    Per visualizzare i possibili tipi di stato a 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à.

• Notifica: 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 terminare. 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 standby 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 altre informazioni, 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.

• Ridondanza della zona: 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 server 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. Se si vuole riportare il database primario nella zona di origine, è possibile avviare manualmente un failover pianificato.

• 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. Usare un failover pianificato per simulare un'interruzione non pianificata durante l'esecuzione del carico di lavoro e osservare il tempo di inattività dell'applicazione. Eseguire simulazioni in ambienti non di produzione o in un momento di quiete. Per altre informazioni, vedere Failover pianificato.

• Ridondanza locale: Non è possibile simulare un'interruzione completa della zona, ma è possibile simulare che il server non sia disponibile in modo analogo a quello che si verifica durante un'interruzione della zona. Per altre informazioni, consultare gli articoli seguenti:

  • Portale di Azure: Arrestare e avviare un'istanza di Database di Azure per MySQL - Server flessibile.

  • interfaccia della riga di comando di Azure: Riavvio, arresto e avvio di un'istanza di Database di Azure per MySQL - Server flessibile.

Resilienza agli errori a livello di area

Database di Azure per MySQL supporta repliche in lettura tra 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

Distribuisci repliche di lettura per proteggere i tuoi database da guasti a livello di regione. Ogni replica di lettura è un server Database di Azure per MySQL separato. Quando si inserisce una replica in lettura in un'altra area di Azure, il server del database può fornire resilienza a un problema a livello di area. È possibile distribuire fino a 10 repliche in lettura, che facoltativamente possono trovarsi in aree Azure diverse.

La tecnologia di replica fisica MySQL aggiorna le repliche in lettura in modo asincrono dal server di origine nell'area primaria, il che significa che le repliche possono essere in ritardo rispetto all'origine. 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 ulteriori informazioni sulle funzionalità delle repliche di lettura e sugli aspetti da considerare, consulta Repliche di lettura.

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

Requisiti

• Supporto per le regioni: È possibile creare repliche di lettura cross-regionale in qualsiasi regione che supporta Database di Azure per MySQL. Non si è limitati alle aree associate 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 dopo averlo creato, ma è consigliabile usare valori uguali o maggiori per garantire 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.

• HA: Le repliche in lettura non possono avere HA abilitata e, quando il failover le promuove a server primario, non dispongono comunque di HA. Sei responsabile della configurazione di HA dopo avere eseguito il failover 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

• Creare una replica di lettura: Per informazioni su come creare una replica di lettura, vedere gli articoli seguenti:

  • Portale di Azure: Come creare e gestire repliche di lettura nel Server flessibile di Database di Azure per MySQL usando il portale di Azure

  • interfaccia della riga di comando di Azure: Come creare e gestire repliche di lettura nel server flessibile di Database di Azure per MySQL usando l'interfaccia della riga di comando di Azure

  È possibile configurare le repliche dopo aver creato il server di origine solo se il server di origine è in esecuzione e raggiungibile.

• Arrestare la replica: Per informazioni su come arrestare la replica, vedere Arrestare la replica in un server di replica.

• Eliminare una replica di lettura: Per informazioni su come eliminare una replica in lettura, vedere Eliminare un server di replica.

Comportamento quando tutte le aree sono integre

Questa sezione descrive che cosa aspettarsi quando si configura il proprio server con una replica di lettura in un'altra regione e tutte le regioni sono operative:

• Routing del traffico tra aree: Durante le 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 si configura un server per il supporto della replica in lettura tra aree 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 effettua automaticamente il failover verso le repliche di lettura, anche in caso di errore di un'area.

  Per eseguire il failover è necessario eseguire i passaggi seguenti:

  1. Interrompere la replicazione. Questa 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 usare il nuovo server 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 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 due minuti dopo l'attivazione dell'azione. L'utente è responsabile della riconfigurazione delle applicazioni per la connessione al nuovo server primario. 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 il failover di una replica di lettura a server primario, il server non ha HA abilitata. Devi abilitare manualmente HA o includerla nei processi di automazione.

Ripristino della regione

Quando la regione si riprende, sei responsabile delle attività di failback per ripristinare 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:

• Mettere l'applicazione fuori servizio e attendere che la replica recuperi tutte le modifiche. Questo approccio richiede tempi di inattività dell'applicazione che corrispondono approssimativamente al ritardo della replica.

• Eseguire il failover e accettare la perdita di 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

Eseguire regolarmente test delle procedure di failover delle repliche di lettura per assicurarsi che i processi siano validi e che le capacità soddisfino i requisiti relativi al Recovery Time Objective (RTO) e al Recovery Point Objective (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ò causare la perdita di dati e richiede il failback manuale.

Nell'ambito della tua strategia di disaster recovery, esegui regolarmente esercitazioni di ripristino completo. Queste esercitazioni includono 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 il backup dei dati, in modo da poterli ripristinare in qualsiasi momento entro il periodo di conservazione dei backup. Questa protezione consente di evitare il danneggiamento accidentale e l'eliminazione dei dati. Microsoft gestisce completamente i backup senza interrompere la disponibilità del server. I backup includono sia backup completi che backup del log delle transazioni.

• Archiviazione di backup: Se si configura il server con HA con ridondanza della zona, il sistema archivia i backup in ZRS. Per i server configurati senza alta disponibilità o con alta disponibilità con ridondanza locale, il sistema archivia i backup in LRS.

  Nelle aree di Azure associate in coppia, è possibile configurare l'archiviazione con ridondanza geografica (GRS) per i backup al momento della creazione del server. Questo approccio replica i backup nell'area Azure abbinata per una protezione aggiuntiva dagli errori dell'area. Il sistema replica i backup in modo asincrono.

  Il periodo di conservazione dei backup predefinito è di 7 giorni, ma è possibile 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. È possibile usare il nuovo server as-is o copiarne i dati.

  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.

  Usare questa funzionalità per eseguire 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:

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 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 per l'alta disponibilità con ridondanza della zona.
• Server configurati con alta disponibilità a ridondanza locale.
• Server configurati senza disponibilità elevata.

Contenuti correlati

• Affidabilità di Azure
• Architecture consigliate per Database di Azure per MySQL
• Panoramica della continuità aziendale con Database di Azure per MySQL