Mysql
 sql >> Database >  >> RDS >> Mysql

Automatizza la distribuzione del tuo cluster MySQL o Postgres dal backup

ClusterControl 1.7.1 introduce una nuova funzionalità chiamata Crea cluster da backup, che consente di distribuire un nuovo cluster basato su MySQL o Postgres e ripristinare i dati su di esso da un backup. Questo post del blog mostra come funziona questa nuova funzionalità e come questo tipo di automazione può apportare miglioramenti alle operazioni della tua infrastruttura.

Presentazione:Crea cluster da backup

La gestione del backup è la funzionalità più amata dai nostri utenti e l'abbiamo appena portata al livello successivo. Questa nuova funzionalità sembra semplice:ClusterControl 1.7.1 è in grado di distribuire un nuovo cluster da un backup esistente. Tuttavia, sono necessarie più procedure e controlli per distribuire un cluster di livello di produzione direttamente da un backup. Il restauro stesso ha le sue sfide, come ad esempio:

  • Conseguenze del ripristino totale o parziale
  • Backup di base e relativo ordinamento dei backup incrementali (per backup incrementale)
  • Decrittografia del backup (se crittografato)
  • Opzioni dello strumento di ripristino
  • Decompressione (se compressa)
  • Backup dello streaming dall'origine al server di destinazione
  • Utilizzo dello spazio su disco durante e dopo il ripristino
  • Report sullo stato di avanzamento del restauro

Combinando quanto sopra con la complessità e la ripetitività delle attività di distribuzione del cluster di database, è possibile risparmiare tempo e ridurre i rischi nell'esecuzione di procedure soggette a errori. La parte più difficile dal punto di vista dell'utente è scegliere da quale backup eseguire il ripristino. ClusterControl gestirà tutto il lavoro pesante dietro le quinte e riporterà il risultato finale una volta terminato.

I passaggi sono sostanzialmente semplici:

  1. Imposta SSH senza password dal nodo ClusterControl ai nuovi server.
  2. Scegli un backup logico dall'elenco dei backup o creane uno in Backup -> Crea backup .
  3. Fai clic su Ripristina -> Crea cluster da backup e segui la procedura guidata di distribuzione.

Questa funzionalità è stata creata specificamente per MySQL Galera Cluster e PostgreSQL al momento. Ecco cosa vedresti nell'interfaccia utente dopo aver fatto clic su "Ripristina" su un backup esistente:

L'opzione in basso è quella che stiamo cercando. Successivamente, è la finestra di dialogo di riepilogo sul backup scelto prima della configurazione della distribuzione:

Successivamente, verrà mostrata la stessa procedura guidata di distribuzione del cluster di database per il rispettivo cluster (MySQL Galera Cluster o PostgreSQL) per configurare un nuovo cluster:

Tieni presente che devi specificare lo stesso nome utente e password root/admin del database di quello che hai nel backup. In caso contrario, la distribuzione fallirebbe a metà all'avvio del primo nodo. In generale, le procedure di ripristino e distribuzione avverranno nel seguente ordine:

  1. Installa i software e le dipendenze necessari su tutti i nodi del database.
  2. Avvia il primo nodo.
  3. Streaming e ripristino del backup sul primo nodo (con flag di riavvio automatico).
  4. Configura e aggiungi il resto dei nodi.

Un nuovo cluster di database verrà elencato nel dashboard del cluster ClusterControl una volta completato il processo.

Cosa puoi ricavarne?

Ci sono un certo numero di cose che potresti trarre vantaggio da questa funzione, come spiegato nelle sezioni seguenti.

Testa il tuo set di dati in varie condizioni

A volte, potresti chiederti che la nuova versione del database funzionerebbe o funzionerebbe per il carico di lavoro del tuo database e testarlo è l'unico modo per saperlo. È qui che questa funzione torna utile. Ti consente di eseguire test e benchmark su molte variabili coinvolte che potrebbero influire sulla stabilità o sulle prestazioni del database, ad esempio l'hardware sottostante, la versione software, il fornitore e i carichi di lavoro del database o dell'applicazione.

Per un semplice esempio, c'è un grande miglioramento nell'esecuzione DDL tra MySQL 5.6 e MySQL 5.7. La seguente operazione DROP su una tabella di 10 milioni di righe lo dimostra:

mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)
mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

Avere un altro cluster con cui confrontarci ci consente effettivamente di misurare il miglioramento e giustificare una migrazione.

Migrazione database con backup logico

Backup logico come mysqldump e pg_dumpall è il modo più sicuro per aggiornare, eseguire il downgrade o migrare i dati da una versione o da un fornitore a un altro. Tutti i backup logici possono essere utilizzati per eseguire la migrazione del database. I passaggi per l'aggiornamento del database sono sostanzialmente semplici:

  1. Crea (o pianifica) un backup logico - mysqldump per MySQL o pg_dumpall per PostgreSQL
  2. Configura SSH senza password dal nodo ClusterControl ai nuovi server.
  3. Scegli un backup logico creato dall'elenco dei backup.
  4. Fai clic su Ripristina -> Crea cluster da backup e segui la procedura guidata di distribuzione.
  5. Verifica il ripristino dei dati sul nuovo cluster.
  6. Indirizza la tua applicazione al nuovo cluster.

Tempo di ripristino totale del cluster più rapido

Immagina un guasto catastrofico che impedisce l'esecuzione del tuo cluster, come ad esempio un errore di archiviazione centralizzata che ha colpito tutte le macchine virtuali ad esso collegate, potresti ottenere un cluster sostitutivo quasi immediatamente (a condizione che i file di backup siano archiviati al di fuori dei nodi del database guasti , affermare l'ovvio). Questa funzione può essere automatizzata tramite il client s9s, dove puoi attivare un lavoro tramite l'interfaccia della riga di comando, ad esempio:

$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

Una cosa da notare quando si utilizza questa funzione è utilizzare lo stesso nome utente e password amministratore di ciò che è archiviato nel backup. Inoltre, l'SSH senza password per tutti i nodi del database deve essere configurato in anticipo. Altrimenti, se preferisci configurarlo in modo interattivo, usa l'interfaccia utente web.

Ridimensionamento tramite replica asincrona

Per MySQL Galera Cluster, il cluster appena creato ha la possibilità di essere ridimensionato tramite la replica asincrona di MySQL. Diciamo che abbiamo già ripristinato un nuovo cluster nell'ufficio basato sull'ultimo backup dal cluster di produzione nel data center e vorremmo che il cluster dell'ufficio continuasse a replicare dal cluster di produzione, come illustrato nel diagramma seguente:

È quindi possibile impostare il collegamento di replica asincrono nel modo seguente:

  1. Scegli un nodo nella produzione e abilita la registrazione binaria (se disabilitata). Vai a Nodi -> scegli un nodo -> Azioni nodo -> Abilita registrazione binaria.

  2. Abilita la registrazione binaria su tutti i nodi per il cluster dell'ufficio. Questa azione richiede un riavvio in sequenza che verrà eseguito automaticamente se scegli "Sì" nell'elenco a discesa "Riavvio automatico del nodo":

    In caso contrario, puoi eseguire questa operazione senza tempi di inattività utilizzando Gestisci -> Aggiorna -> Riavvia in sequenza (o riavvia manualmente un nodo alla volta).

  3. Crea un utente di replica nel cluster di produzione utilizzando Gestisci -> Schemi e utenti -> Utenti -> Crea nuovo utente:

  4. Quindi, scegli un nodo da replicare nel nodo master nel cluster di produzione e imposta il collegamento di replica:

    mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
mysql> START SLAVE;

  5. Verifica se la replica è in esecuzione:

    mysql> SHOW SLAVE STATUS\G
    Assicurati che Slave_IO_Thread e Slave_SQL_thread riportino "Sì". Il cluster dell'ufficio dovrebbe iniziare a recuperare il ritardo con il nodo master se è in ritardo.

Per ora è tutto!