Descrizione di alta disponibilità e di ripristino di emergenza per Databases for MySQL
L' alta disponibilitàLa capacità di un servizio o di un carico di lavoro di resistere ai guasti e di continuare a fornire capacità di elaborazione secondo un livello di servizio predefinito. Per i servizi, la disponibilità è definita nell'Accordo sul livello dei servizi. La disponibilità comprende sia gli eventi pianificati che quelli non pianificati, come manutenzione, guasti e disastri. (HA) è la capacità di un servizio di rimanere operativo e accessibile in presenza di guasti imprevisti. Il disaster recoveryLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. è il processo di ripristino dell'istanza di servizio in uno stato funzionante.
Databases for MySQL è un servizio regionale che soddisfa gli obiettivi di livello di servizio(SLO) definiti con il piano standard. Per ulteriori informazioni, consultare l'Accordo sul livello dei servizi(SLA). Per ulteriori informazioni sulle regioni e sui data center IBM Cloud disponibili per Databases for MySQL, vedere Disponibilità del servizio e dell'infrastruttura per località.
Architettura ad alta disponibilità
Databases for MySQL offre funzioni di replica, failover e alta disponibilità per proteggere i database e i dati dalla manutenzione dell'infrastruttura, dagli aggiornamenti e da alcuni guasti. Le distribuzioni contengono un cluster con tre membri dati: un leader e due repliche. Le repliche vengono mantenute aggiornate utilizzando la replica asincrona. Tutti i membri contengono una copia dei dati utilizzando Orchestrator per gestire i failover. Il leader e le repliche si trovano sempre in zone diverse di una regione multizona. Se il leader diventa irraggiungibile o incontra un problema critico, il servizio tenta innanzitutto di ripristinare automaticamente il leader esistente. Se non è possibile ripristinare il leader, viene eseguito un failover e una replica viene promossa a leader, una nuova replica si ricollega al cluster come replica e il cluster continua a funzionare normalmente. Se la replica fallisce, viene creata una nuova replica. Se il fallimento di una zona comporta il fallimento di un membro, la nuova replica viene creata in una zona superstite.
È possibile estendere ulteriormente l'alta disponibilità con il provisioning di repliche di sola lettura per il failover interregionale o il read offloading.
Consulta la documentazione di MySQL sulle tecniche di replica per comprendere i vincoli e i compromessi associati alla replica asincrona.
Sebbene la versione 8.0 utilizzi la replica semisincrona e la versione 8.4 introduca la tecnologia asincrona, i comportamenti fondamentali per l'alta disponibilità e il disaster recovery rimangono fondamentalmente invariati.
I carichi di lavoro che accedono programmaticamente al cluster devono seguire la logica di retry della disponibilità del client per mantenere la disponibilità.
Databases for MySQL a volte esegue commutazioni controllate durante il normale funzionamento. Questi passaggi sono generalmente eventi senza perdita di dati che comportano il ripristino delle connessioni attive. La riconnessione può fallire per un periodo massimo di 15 secondi. A volte, i failover non pianificati possono verificarsi a causa di eventi imprevisti nell'ambiente operativo. L'operazione può richiedere fino a 2 minuti, poiché l'istanza potrebbe impiegare un po' di tempo per assegnare un nodo funzionante come leader. La manutenzione del servizio, ad esempio, attiva un failover controllato.
Caratteristiche di alta disponibilità
Databases for MySQL supporta le seguenti funzioni di alta disponibilità:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Comportamento in caso di failover | Standard su tutti i cluster e resiliente contro i guasti di una zona o di un singolo membro. Se il leader diventa non funzionante o irraggiungibile, il servizio tenta di ripristinarlo automaticamente. Se non è possibile ripristinare il leader, viene eseguito un failover e viene promossa una replica per ripristinare la disponibilità di scrittura. | Per ridurre al minimo il ritardo di replica tra il leader e le repliche, seguire le best practice, quali la logica di riprova, la gestione delle connessioni e l'implementazione delle chiavi primarie. |
| Conteggio membri | Uno schieramento di tre membri. Un cluster composto da tre membri è in grado di riprendersi da un singolo guasto di un'istanza o di una zona, con un possibile ritardo dei dati durante il processo di ripristino. In caso di guasto, una replica viene promossa a leader e il cluster continua a funzionare normalmente. | |
| Replica di sola lettura | Le repliche di sola lettura possono fornire un accesso locale in regioni remote, migliorando la disponibilità in caso di potenziali problemi di latenza di rete o di connettività. | Tutte le richieste di scrittura devono essere dirette esclusivamente al cluster di lettura-scrittura associato alla replica di lettura. |
Architettura di disaster recovery
La strategia generale per il ripristino d'emergenza consiste nel creare un nuovo database, come ad esempio il database Restore. Il contenuto del nuovo database può essere un backup del database di origine creato prima del disastro.
È possibile creare un nuovo database utilizzando la funzione point-in-time se il database di produzione è disponibile.
Funzionalità di disaster recovery
Databases for MySQL supporta le seguenti funzioni di disaster recovery:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Ripristino del backup | Creare un database dal backup precedentemente creato. Per ulteriori informazioni, consultare la sezione Gestione dei backup di Cloud Databases. | Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
| Ripristino del punto temporale | Creare un database dalla produzione live utilizzando il ripristino point-in-time. | Ciò è possibile solo se il database attivo è disponibile e l'RPO (disastro) rientra nella finestra supportata. Non è utile se il cluster di produzione non è disponibile. Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
| Promuovere la replica di lettura | Creare una replica di sola lettura quando si pianifica un disastro nella stessa regione o in una regione remota. Promuovere la replica di sola lettura per il ripristino da un disastro. | La replica di lettura creata in precedenza deve essere disponibile. Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
Pianificazione del ripristino in caso di disastro
Le fasi di disaster recovery devono essere praticate regolarmente. Nel costruire il vostro piano, considerate i seguenti scenari di fallimento e le relative soluzioni.
| Operazione non riuscita | Risoluzione |
|---|---|
| Guasto hardware (punto singolo) | IBM fornisce un database resistente a un singolo punto di guasto hardware all'interno di una zona, senza necessità di configurazione. |
| malfunzionamento zona | Failover (#mysql-alta-disponibilità). I membri del database sono distribuiti tra le zone. |
| Dati danneggiati | Ripristino del backup. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato.
Ripristino point-in-time. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato. |
| Fallimento regionale | Ripristino del backup. Utilizzare il database ripristinato in produzione.
Promuovere la replica della lettura. Promuovere una replica di sola lettura a un database di lettura/scrittura. Utilizzare il database ripristinato in produzione |
Alta disponibilità a livello di applicazione
Le applicazioni che comunicano sulle reti e i servizi cloud sono soggette ad errori di connessione temporanei. Le applicazioni devono essere progettate in modo da riprovare le connessioni quando gli errori sono causati da una perdita temporanea di connettività con l'installazione o con IBM Cloud.
Poiché Databases for MySQL è un servizio gestito, gli aggiornamenti regolari e la manutenzione del database fanno parte delle normali operazioni. Se entrambe le repliche vengono perse, le scritture sul leader si bloccano, perché il processo di replica semisincrona non ha un follower. Per ulteriori informazioni, vedere Replica semisincrona. Questo scenario causa occasionalmente brevi intervalli in cui il database non è disponibile. Può anche far sì che il database attivi un failover aggraziato, effettui un nuovo tentativo e si riconnetta. Il database impiega un po' di tempo per determinare quale membro è una replica e quale è il leader, quindi potrebbe verificarsi una breve interruzione della connessione. I failover richiedono generalmente meno di 30 secondi. Per ridurre al minimo le interruzioni, gli aggiornamenti vengono applicati prima alle repliche e per ultimo il leader.
Le applicazioni devono essere progettate per gestire le interruzioni temporanee del database, implementare la gestione degli errori per i comandi del database non riusciti e implementare la logica di retry per recuperare da un'interruzione temporanea.
Non sono previsti diversi minuti di indisponibilità del database o di interruzione della connessione. Aprire un caso di assistenza con i dettagli se si verificano periodi superiori a un minuto senza connettività, in modo da poter indagare.
Limiti connessioni
Databases for MySQL imposta a 200 il numero massimo di connessioni al database MySQL. Lasciare alcune connessioni disponibili, poiché alcune di esse sono riservate internamente per mantenere lo stato e l'integrità del database. Una volta raggiunto il limite di connessione, qualsiasi tentativo di avviare una nuova connessione provoca un errore. Per evitare di sovraccaricare il deployment di connessioni, utilizzare il pooling delle connessioni o scalare il deployment e aumentare il limite di connessioni. Per ulteriori informazioni, vedere Gestione delle connessioni di MySQL.
Le vostre responsabilità per HA e DR
Le seguenti informazioni possono aiutarvi a creare e a mettere in pratica costantemente il vostro piano per l'HA e il DR.
Quando si ripristina un database dai backup o si usa il ripristino point-in-time, viene creato un nuovo database con nuove stringhe di connessione. I carichi di lavoro e i processi esistenti devono essere adattati per utilizzare le nuove stringhe di connessione. La promozione di una replica di lettura in un cluster avrà un impatto simile, anche se le porzioni esistenti di sola lettura del carico di lavoro non saranno interessate.
Un database recuperato può anche avere bisogno delle stesse dipendenze create dal cliente del database danneggiato: accertatevi che questo e altri servizi esistano nella regione recuperata:
- IBM® Key Protect for IBM Cloud®
Ricordate che l'eliminazione di un database elimina anche i backup ad esso associati. Tuttavia, i database eliminati possono essere recuperati entro un periodo di tempo limitato. Per informazioni specifiche sulle procedure di ripristino del database, fare riferimento alle FAQ sui backup.
Non è possibile copiare i backup dal sito IBM Cloud, quindi si consiglia di utilizzare gli strumenti specifici del database per ulteriori backup. Può essere necessario per ripristinare l'eliminazione di un database da parte di un malintenzionato, seguita da una bonifica di un database. Un'attenta gestione dell'accesso IAM ai database può contribuire a ridurre l'esposizione a questo problema.
La seguente lista di controllo associata a ciascuna caratteristica può aiutarvi a creare e mettere in pratica il vostro piano.
- Ripristino del backup
- Verificare che i backup siano disponibili con la frequenza desiderata per soddisfare i requisiti RPO. Per ulteriori informazioni, consultare la sezione Gestione dei backup di Cloud Databases. Considerare uno script utilizzando IBM Cloud® Code Engine- Lavorare con il produttore di eventi Periodic timer(cron) per creare backup aggiuntivi su richiesta per migliorare l'RPO se la criticità e le dimensioni del database lo consentono. Tuttavia, date le capacità del PITR di MySQL's, valutare attentamente la necessità di backup aggiuntivi.
- Esistono alcune restrizioni sulle regioni di ripristino dei database: verificare che gli obiettivi di ripristino possano essere raggiunti leggendo Gestione dei backup di Cloud Databases.
- Verificate che il periodo di conservazione dei backup soddisfi i vostri requisiti.
- Pianificare regolarmente ripristini di prova per verificare che i tempi di ripristino effettivi rispettino l'RTO definito. Ricordate che le dimensioni del database influiscono in modo significativo sui tempi di ripristino. Considerate le strategie per ridurre al minimo i tempi di ripristino, come la suddivisione di database di grandi dimensioni in unità più piccole e gestibili e l'eliminazione dei dati inutilizzati.
- Verificare il servizio Key Protect.
- Ripristino del punto temporale
- Verificare le procedure descritte in precedenza.
- Verificare che il backup desiderato sia presente nella finestra.
- Promuovere la replica di lettura
- Verificare l'esistenza di una replica di lettura nella regione di recupero.
- Esercitarsi nel processo di promozione: creare una replica di lettura temporanea nella regione desiderata. La replica temporanea può essere promossa in lettura/scrittura e si possono eseguire alcuni test con un impatto minimo sulla produzione.
Per saperne di più sulla responsabilità tra il cliente e IBM Cloud per l'utilizzo di Databases for MySQL, vedere Responsabilità condivise per Cloud Databases.
Rimanete informati: notifiche su IBM
Gli aggiornamenti che interessano i carichi di lavoro dei clienti sono comunicati attraverso le notifiche di IBM Cloud. Per essere informati sulla manutenzione programmata, sugli annunci e sulle note di rilascio relative a questo servizio, consultate la pagina delle notifiche e dello stato del monitoraggio. Inoltre, consultate regolarmente la pagina della Politica delle versioni per gli ultimi aggiornamenti sulle versioni e sulle date di fine vita.