MariaDB
 sql >> Database >  >> RDS >> MariaDB

Cloud Disaster Recovery per MariaDB e MySQL

MySQL ha una lunga tradizione nella replica geografica. La distribuzione di cluster a data center remoti riduce gli effetti della latenza geografica avvicinando i dati all'utente. Fornisce inoltre una funzionalità per il ripristino di emergenza. A causa del costo significativo della duplicazione dell'hardware in un sito separato, in passato non molte aziende potevano permetterselo. Un altro costo è rappresentato dal personale qualificato in grado di progettare, implementare e mantenere un sofisticato ambiente con più data center.

Con la rivoluzione dell'automazione Cloud e DevOps, avere un datacenter distribuito non è mai stato così accessibile alle masse. I fornitori di servizi cloud stanno aumentando la gamma di servizi offerti a un prezzo migliore. È possibile creare ambienti ibridi cross-cloud con dati diffusi in tutto il mondo. È possibile creare piani di ripristino di emergenza flessibili e scalabili per affrontare un'ampia gamma di scenari di interruzione. In alcuni casi, può essere solo un backup archiviato fuori sede. In altri casi, può essere una copia 1 a 1 di un ambiente di produzione in esecuzione da qualche altra parte.

In questo blog daremo un'occhiata ad alcuni di questi casi e affronteremo scenari comuni.

Memorizzazione dei backup nel cloud

Un piano di ripristino di emergenza è un termine generico che descrive un processo per ripristinare i sistemi IT interrotti e altre risorse critiche utilizzate da un'organizzazione. Il backup è il metodo principale per raggiungere questo obiettivo. Quando un backup si trova nello stesso data center dei server di produzione, si rischia che tutti i dati vengano cancellati in caso di smarrimento del data center. Per evitarlo, dovresti avere la politica per creare una copia in un'altra posizione fisica. È comunque buona norma mantenere un backup su disco per ridurre il tempo necessario per il ripristino. Nella maggior parte dei casi, manterrai il backup principale nello stesso data center (per ridurre al minimo i tempi di ripristino), ma dovresti anche disporre di un backup che possa essere utilizzato per ripristinare le procedure aziendali quando il data center primario è inattivo.

ClusterControl:Carica backup nel cloud

ClusterControl consente una perfetta integrazione tra l'ambiente del database e il cloud. Fornisce opzioni per la migrazione dei dati nel cloud. Offriamo una combinazione completa di backup del database per Amazon Web Services (AWS), Google Cloud Services o Microsoft Azure. I backup possono ora essere eseguiti, programmati, scaricati e ripristinati direttamente dal provider cloud di tua scelta. Questa capacità offre una maggiore ridondanza, migliori opzioni di ripristino di emergenza e vantaggi sia in termini di prestazioni che di risparmio sui costi.

ClusterControl:gestione delle credenziali cloud

Il primo passaggio per impostare il "backup a prova di errore del data center" è fornire le credenziali per il tuo operatore cloud. Puoi scegliere tra più fornitori qui. Diamo un'occhiata al processo impostato per l'operatore cloud più popolare:AWS.

ClusterControl:aggiunta di credenziali cloud

Tutto ciò di cui hai bisogno è l'ID chiave AWS e il segreto per la regione in cui desideri archiviare il backup. Puoi ottenerlo dalla console AWS. Puoi seguire alcuni passaggi per ottenerlo.

  1. Utilizza l'indirizzo e-mail e la password dell'account AWS per accedere alla Console di gestione AWS come utente root dell'account AWS.
  2. Nella pagina IAM Dashboard, scegli il nome del tuo account nella barra di navigazione, quindi seleziona Le mie credenziali di sicurezza .
  3. Se visualizzi un avviso sull'accesso alle credenziali di sicurezza per il tuo account AWS, scegli Continua con le credenziali di sicurezza .
  4. Espandi la sezione Chiavi di accesso (ID chiave di accesso e chiave di accesso segreta).
  5. Scegli di Creare una nuova chiave di accesso . Quindi scegli Scarica file chiave per salvare l'ID della chiave di accesso e la chiave di accesso segreta in un file sul computer. Dopo aver chiuso la finestra di dialogo, non sarai più in grado di recuperare questa chiave di accesso segreta.
ClusterControl:backup su cloud ibrido

Quando tutto è impostato, puoi regolare la pianificazione del backup e abilitare l'opzione backup su cloud. Per ridurre il traffico di rete, assicurati di abilitare la compressione dei dati. Riduce i backup e riduce al minimo il tempo necessario per il caricamento. Un'altra buona pratica è crittografare il backup. ClusterControl crea automaticamente una chiave e la utilizza se si decide di ripristinarla. Le politiche di backup avanzate dovrebbero avere tempi di conservazione diversi per i backup archiviati su server nello stesso data center e per i backup archiviati in un'altra posizione fisica. È necessario impostare un periodo di conservazione più esteso per i backup basati su cloud e un periodo più breve per i backup archiviati vicino all'ambiente di produzione, poiché la probabilità di ripristino diminuisce con la durata del backup.

ClusterControl:criterio di conservazione del backup

Estendi il tuo cluster con la replica asincrona

Galera con replica asincrona può essere un'ottima soluzione per costruire un nodo DR attivo in un data center remoto. Ci sono alcuni buoni motivi per collegare uno slave asincrono a un cluster Galera. Le query di tipo OLAP di lunga durata su un nodo Galera potrebbero rallentare un intero cluster. Con l'opzione di applicazione ritardata, la replica ritardata può salvarti dagli errori umani in modo che tutte le immissioni auree non vengano immediatamente applicate al tuo nodo di backup.

ClusterControl:replica ritardata

In ClusterControl, l'estensione di un gruppo di nodi Galera con la replica asincrona viene eseguita in una procedura guidata a pagina singola. Devi fornire le informazioni necessarie sul tuo server slave futuro o esistente. Lo slave verrà configurato da un backup esistente o da un XtraBackup appena trasmesso in streaming dal master allo slave.

Bilanciatori del carico in Multi-Datacenter

I bilanciatori di carico sono un componente cruciale nell'elevata disponibilità dei database MySQL e MariaDB. Non è sufficiente avere un cluster che si estende su più data center. Hai ancora bisogno dei tuoi servizi per accedervi. Un guasto a un sistema di bilanciamento del carico disponibile in un data center renderà irraggiungibile l'intero ambiente.

Proxy Web in ambiente cluster

Uno dei metodi più diffusi per nascondere la complessità del livello di database da un'applicazione consiste nell'utilizzare un proxy. I proxy fungono da punto di ingresso ai database, tengono traccia dello stato dei nodi del database e devono sempre indirizzare il traffico solo ai nodi disponibili. ClusterControl semplifica l'implementazione e la configurazione di diverse tecnologie di bilanciamento del carico per MySQL e MariaDB, inclusi ProxySQL, HAProxy, con un'interfaccia grafica point-and-click.

ClusterControl:bilanciamento del carico HA

Consente inoltre di rendere questo componente ridondante aggiungendo keepalived su di esso. Per evitare che i sistemi di bilanciamento del carico siano un singolo punto di errore, è necessario configurare due istanze HAProxy, ProxySQL o MariaDB Maxscale identiche (una attiva e una in un controller di dominio diverso come standby) e utilizzare Keepalived per eseguire il protocollo di ridondanza del router virtuale (VRRP) tra loro. VRRP fornisce un indirizzo IP virtuale al sistema di bilanciamento del carico attivo e trasferisce l'IP virtuale all'HAProxy di standby in caso di errore. È perfetto perché le due istanze proxy non necessitano di uno stato condiviso.

Naturalmente, ci sono molte cose da considerare per rendere i database immuni ai guasti del data center.
Un'adeguata pianificazione e automazione lo farà funzionare! Buon raggruppamento!