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

Come automatizzare la migrazione da MySQL autonomo a Galera Cluster utilizzando Ansible

Le migrazioni del database non si adattano bene. In genere è necessario eseguire molti test prima di poter premere il grilletto e passare dal vecchio al nuovo. Le migrazioni vengono generalmente eseguite manualmente, poiché la maggior parte del processo non si presta all'automazione. Ma ciò non significa che non ci sia spazio per l'automazione nel processo di migrazione. Immagina di configurare un certo numero di nodi con un nuovo software, di fornire loro i dati e di configurare manualmente la replica tra il vecchio e il nuovo ambiente. Ci vogliono giorni. L'automazione può essere molto utile durante la configurazione di un nuovo ambiente e il provisioning dei dati. In questo post del blog, daremo un'occhiata a una migrazione molto semplice, da Percona Server 5.7 standalone a Percona XtraDB Cluster 5.7 a 3 nodi. Useremo Ansible per farlo.

Descrizione dell'ambiente

Prima di tutto, un importante disclaimer:quello che mostreremo qui è solo una bozza di ciò che ti piacerebbe eseguire in produzione. Funziona nel nostro ambiente di test ma potrebbe richiedere modifiche per renderlo adatto al tuo ambiente. Nei nostri test abbiamo utilizzato quattro VM Ubuntu 16.04 distribuite utilizzando Vagrant. Uno contiene Percona Server 5.7 autonomo, gli altri tre verranno utilizzati per i nodi Percona XtraDB Cluster. Utilizziamo anche un nodo separato per l'esecuzione di playbook ansible, anche se questo non è un requisito e il playbook può essere eseguito anche da uno dei nodi. Inoltre, la connettività SSH è disponibile tra tutti i nodi. Devi avere la connettività dall'host su cui esegui ansible, ma avere la possibilità di ssh tra i nodi è utile (soprattutto tra master e nuovo slave - ci affidiamo a questo nel playbook).

Struttura del Playbook

I playbook Ansible in genere condividono una struttura comune:crei ruoli, che possono essere assegnati a host diversi. Ogni ruolo conterrà attività da eseguire su di esso, modelli che verranno utilizzati, file che verranno caricati, variabili definite per questo particolare playbook. Nel nostro caso, il playbook è molto semplice.

.
├── inventory
├── playbook.yml
├── roles
│   ├── first_node
│   │   ├── my.cnf.j2
│   │   ├── tasks
│   │   │   └── main.yml
│   │   └── templates
│   │       └── my.cnf.j2
│   ├── galera
│   │   ├── tasks
│   │   │   └── main.yml
│   │   └── templates
│   │       └── my.cnf.j2
│   ├── master
│   │   └── tasks
│   │       └── main.yml
│   └── slave
│       └── tasks
│           └── main.yml
└── vars
    └── default.yml

Abbiamo definito un paio di ruoli:abbiamo un ruolo principale, che ha lo scopo di eseguire alcuni controlli di integrità sul nodo autonomo. È presente un nodo slave, che verrà eseguito su uno dei nodi Galera per configurarlo per la replica e configurare la replica asincrona. Quindi abbiamo un ruolo per tutti i nodi Galera e un ruolo per il primo nodo Galera per eseguire il bootstrap del cluster da esso. Per i ruoli Galera, abbiamo un paio di modelli che useremo per creare file my.cnf. Useremo anche local .my.cnf per definire un nome utente e una password. Abbiamo un file contenente un paio di variabili che potremmo voler personalizzare, proprio come le password. Infine abbiamo un file di inventario, che definisce gli host su cui eseguiremo il playbook, abbiamo anche il file del playbook con informazioni su come esattamente le cose dovrebbero essere eseguite. Diamo un'occhiata ai singoli bit.

File di inventario

Questo è un file molto semplice.

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

Abbiamo tre gruppi, "galera", che contiene tutti i nodi Galera, "first_node", che useremo per il bootstrap e infine "master", che contiene il nostro nodo server Percona standalone.

Playbook.yml

Il file playbook.yml contiene le linee guida generali su come eseguire il playbook.

-   hosts: master
    gather_facts: yes
    become: true
    pre_tasks:
    -   name: Install Python2
        raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
    vars_files:
        -   vars/default.yml
    roles:
    -   { role: master }

Come puoi vedere, iniziamo con il nodo autonomo e applichiamo le attività relative al ruolo "master" (ne parleremo in dettaglio più avanti in questo post).

-   hosts: first_node
    gather_facts: yes
    become: true
    pre_tasks:
    -   name: Install Python2
        raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
    vars_files:
        -   vars/default.yml
    roles:
    -   { role: first_node }
    -   { role: slave }

In secondo luogo, andiamo al nodo definito nel gruppo "first_node" e applichiamo due ruoli:"first_node" e "slave". Il primo ha lo scopo di distribuire un cluster PXC a nodo singolo, il secondo lo configurerà per funzionare come slave e configurerà la replica.

-   hosts: galera
    gather_facts: yes
    become: true
    pre_tasks:
    -   name: Install Python2
        raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
    vars_files:
        -   vars/default.yml
    roles:
    -   { role: galera }

Infine, esaminiamo tutti i nodi Galera e applichiamo il ruolo "galera" su tutti loro.

Diversinines DevOps Guide to Database ManagementScopri cosa devi sapere per automatizzare e gestire i tuoi database open sourceScarica gratuitamente

Variabili

Prima di iniziare a esaminare i ruoli, vogliamo menzionare le variabili predefinite che abbiamo definito per questo playbook.

sst_user: "sstuser"
sst_password: "pa55w0rd"
root_password: "pass"
repl_user: "repl_user"
repl_password: "repl1cati0n"

Come abbiamo affermato, questo è un playbook molto semplice senza molte opzioni per la personalizzazione. Puoi configurare utenti e password e questo è praticamente tutto. One gotcha:assicurati che la password di root del nodo autonomo corrisponda a "root_password" qui, altrimenti il ​​playbook non sarebbe in grado di connettersi lì (può essere esteso per gestirlo ma non l'abbiamo coperto).

Questo file non ha molto valore ma, come regola pratica, si desidera crittografare qualsiasi file che contenga credenziali. Ovviamente, questo è per motivi di sicurezza. Ansible viene fornito con ansible-vault, che può essere utilizzato per crittografare e decrittografare i file. Non tratteremo i dettagli qui, tutto ciò che devi sapere è disponibile nella documentazione. In breve, puoi crittografare facilmente i file utilizzando password e configurare il tuo ambiente in modo che i playbook possano essere decrittografati automaticamente utilizzando la password da file o passati manualmente.

Ruoli

In questa sezione esamineremo i ruoli definiti nel playbook, riassumendo ciò che sono destinati a svolgere.

Ruolo principale

Come abbiamo affermato, questo ruolo ha lo scopo di eseguire un controllo di integrità sulla configurazione di MySQL autonomo. Installerà i pacchetti richiesti come percona-xtrabackup-24. Crea anche un utente di replica sul nodo master. Viene esaminata una configurazione per garantire che server_id e altre impostazioni relative alla replica e al registro binario siano impostate. Anche GTID è abilitato poiché ci affidiamo a esso per la replica.

Ruolo del primo_nodo

Qui viene installato il primo nodo Galera. Verrà configurato il repository Percona, dal template verrà creato my.cnf. Verrà installato PXC. Eseguiamo anche alcune operazioni di pulizia per rimuovere gli utenti non necessari e per creare quelli che saranno richiesti (utente root con la password di nostra scelta, utente richiesto per SST). Infine, il cluster viene avviato utilizzando questo nodo. Facciamo affidamento sul "wsrep_cluster_address" vuoto come metodo per inizializzare il cluster. Questo è il motivo per cui in seguito eseguiamo ancora il ruolo "galera" sul primo nodo, per scambiare l'iniziale my.cnf con quello finale, contenente "wsrep_cluster_address" con tutti i membri del cluster. Una cosa che vale la pena ricordare:quando crei un utente root con password devi stare attento a non rimanere bloccato su MySQL in modo che Ansible possa eseguire altri passaggi del playbook. Un modo per farlo è fornire a .my.cnf l'utente e la password corretti. Un altro sarebbe ricordarsi di impostare sempre login_user e login_password corretti nel modulo 'mysql_user'.

Ruolo di schiavo

Questo ruolo riguarda la configurazione della replica tra il nodo autonomo e il cluster PXC a nodo singolo. Usiamo xtrabackup per ottenere i dati, controlliamo anche gtid eseguito in xtrabackup_binlog_info per assicurarci che il backup venga ripristinato correttamente e che la replica possa essere configurata. Eseguiamo anche un po' della configurazione, assicurandoci che il nodo slave possa utilizzare la replica GTID. Ci sono un paio di problemi qui:non è possibile eseguire "RESET MASTER" usando il modulo "mysql_replication" a partire da Ansible 2.7.10, dovrebbe essere possibile farlo in 2.8, ogni volta che uscirà. Abbiamo dovuto usare il modulo "shell" per eseguire i comandi CLI di MySQL. Quando si ricostruisce il nodo Galera da un'origine esterna, è necessario ricordare di ricreare tutti gli utenti richiesti (almeno l'utente utilizzato per SST). In caso contrario, i nodi rimanenti non potranno unirsi al cluster.

Ruolo Galleria

Infine, questo è il ruolo in cui installiamo PXC sui restanti due nodi. Lo eseguiamo su tutti i nodi, quello iniziale riceverà "produzione" my.cnf invece della sua versione "bootstrap". I restanti due nodi avranno PXC installato e riceveranno SST dal primo nodo nel cluster.

Riepilogo

Come puoi vedere, puoi facilmente creare un playbook Ansible semplice e riutilizzabile che può essere utilizzato per distribuire Percona XtraDB Cluster e configurarlo come slave del nodo MySQL autonomo. Ad essere onesti, per la migrazione di un singolo server, questo probabilmente non avrà alcun senso poiché fare lo stesso manualmente sarà più veloce. Tuttavia, se prevedi di dover rieseguire questo processo un paio di volte, avrà sicuramente senso automatizzarlo e renderlo più efficiente in termini di tempo. Come abbiamo affermato all'inizio, questo non è affatto un playbook pronto per la produzione. È più un proof of concept, qualcosa che puoi estendere per renderlo adatto al tuo ambiente. Puoi trovare l'archivio con il playbook qui:http://diversealnines.com/sites/default/files/ansible.tar.gz

Ci auguriamo che tu abbia trovato questo post del blog interessante e prezioso, non esitare a condividere le tue opinioni.