Hur man automatiserar migrering från fristående MySQL till Galera Cluster med Ansible

Databasmigrering skalas inte bra. Vanligtvis behöver du utföra en hel del tester innan du kan trycka på avtryckaren och byta från gammalt till nytt. Migrering sker vanligtvis manuellt, eftersom det mesta av processen inte lämpar sig för automatisering. Men det betyder inte att det inte finns utrymme för automatisering i migreringsprocessen. Föreställ dig att sätta upp ett antal noder med ny programvara, förse dem med data och konfigurera replikering mellan gamla och nya miljöer för hand. Detta tar dagar. Automatisering kan vara mycket användbart när du konfigurerar en ny miljö och tillhandahåller den med data. I det här blogginlägget kommer vi att ta en titt på en mycket enkel migrering - från fristående Percona Server 5.7 till en 3-nods Percona XtraDB Cluster 5.7. Vi kommer att använda Ansible för att åstadkomma det.

Miljöbeskrivning

Först av allt, en viktig ansvarsfriskrivning - det vi ska visa här är bara ett utkast av vad du skulle vilja köra i produktionen. Det fungerar på vår testmiljö men det kan kräva modifieringar för att göra det lämpligt för din miljö. I våra tester använde vi fyra Ubuntu 16.04 VM:er distribuerade med Vagrant. En innehåller fristående Percona Server 5.7, resterande tre kommer att användas för Percona XtraDB Cluster-noder. Vi använder också en separat nod för att köra eventuella spelböcker, även om detta inte är ett krav och spelboken kan även köras från en av noderna. Dessutom är SSH-anslutning tillgänglig mellan alla noder. Du måste ha anslutning från värden där du kör ansible, men att ha förmågan att ssh mellan noder är användbart (särskilt mellan master och ny slav - vi förlitar oss på detta i spelboken).

Playbook-struktur

Ansible playbooks har vanligtvis gemensam struktur - du skapar roller som kan tilldelas olika värdar. Varje roll kommer att innehålla uppgifter som ska utföras på den, mallar som kommer att användas, filer som kommer att laddas upp, variabler som är definierade för just denna spelbok. I vårt fall är spelboken väldigt enkel.

.
├── 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

Vi definierade ett par roller - vi har en huvudroll, som är avsedd att göra några förnuftskontroller på den fristående noden. Det finns en slavnod, som kommer att köras på en av Galera-noderna för att konfigurera den för replikering och ställa in den asynkrona replikeringen. Sedan har vi en roll för alla Galera-noder och en roll för den första Galera-noden att starta klustret från det. För Galera-roller har vi ett par mallar som vi kommer att använda för att skapa my.cnf-filer. Vi kommer också att använda lokal .my.cnf för att definiera ett användarnamn och lösenord. Vi har en fil som innehåller ett par variabler som vi kanske vill anpassa, precis som lösenord. Äntligen har vi en inventeringsfil, som definierar värdar som vi ska köra playbook på, vi har även playbook-filen med information om exakt hur saker och ting ska utföras. Låt oss ta en titt på de enskilda bitarna.

Inventeringsfil

Detta är en mycket enkel fil.

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

Vi har tre grupper, 'galera', som innehåller alla Galera-noder, 'first_node', som vi kommer att använda för bootstrap och slutligen 'master', som innehåller vår fristående Percona Server-nod.

Playbook.yml

Filen playbook.yml innehåller de allmänna riktlinjerna för hur spelboken ska köras.

-   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 }

Som du kan se börjar vi med den fristående noden och vi tillämpar uppgifter relaterade till rollen "mästare" (vi kommer att diskutera detta i detaljer längre ner i det här inlägget).

-   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 }

För det andra går vi till nod definierad i 'first_node'-gruppen och vi tillämpar två roller:'first_node' och 'slav'. Den förra är avsedd att distribuera ett PXC-kluster för en enda nod, det senare kommer att konfigurera det att fungera som en slav och ställa in replikeringen.

-   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 }

Slutligen går vi igenom alla Galera-noder och tillämpar "galera"-rollen på dem alla.

Variabler

Innan vi börjar titta på roller vill vi nämna standardvariabler som vi definierade för den här spelboken.

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

Som vi sa är detta en väldigt enkel spelbok utan många anpassningsmöjligheter. Du kan konfigurera användare och lösenord och detta är i princip det. One gotcha - se till att den fristående nodens root-lösenord matchar "root_password" här eftersom spelboken annars inte skulle kunna ansluta dit (den kan utökas för att hantera det men vi täckte inte det).

Den här filen är utan mycket värde men som en tumregel vill du kryptera vilken fil som helst som innehåller referenser. Uppenbarligen är detta av säkerhetsskäl. Ansible kommer med ansible-vault, som kan användas för att kryptera och dekryptera filer. Vi kommer inte att täcka detaljer här, allt du behöver veta finns i dokumentationen. Kort sagt, du kan enkelt kryptera filer med lösenord och konfigurera din miljö så att spelböckerna kan dekrypteras automatiskt med lösenord från fil eller skickas för hand.

Roller

I det här avsnittet kommer vi att gå över roller som definieras i spelboken och sammanfatta vad de är avsedda att utföra.

Mästarroll

Som vi sa är den här rollen avsedd att köra en förnuftskontroll på konfigurationen av den fristående MySQL. Det kommer att installera nödvändiga paket som percona-xtrabackup-24. Det skapar också replikeringsanvändare på masternoden. En konfiguration granskas för att säkerställa att server_id och andra replikerings- och binära loggrelaterade inställningar är inställda. GTID är också aktiverat eftersom vi kommer att lita på det för replikering.

First_node-roll

Här är den första Galera-noden installerad. Percona repository kommer att konfigureras, my.cnf kommer att skapas från mallen. PXC kommer att installeras. Vi kör också en del rensning för att ta bort onödiga användare och skapa de som kommer att krävas (rotanvändare med lösenordet som vi väljer, användaren krävs för SST). Slutligen bootstrappas klustret med denna nod. Vi litar på den tomma 'wsrep_cluster_address' som ett sätt att initiera klustret. Det är därför vi senare fortfarande kör 'galera'-rollen på den första noden - för att byta initial my.cnf med den sista, som innehåller 'wsrep_cluster_address' med alla medlemmar i klustret. En sak som är värd att komma ihåg - när du skapar en root-användare med lösenord måste du vara försiktig så att du inte låses av MySQL så att Ansible kan utföra andra steg i spelboken. Ett sätt att göra det är att förse .my.cnf med korrekt användare och lösenord. En annan skulle vara att komma ihåg att alltid ställa in korrekt login_user och login_password i modulen 'mysql_user'.

Slavroll

Denna roll handlar om att konfigurera replikering mellan fristående nod och PXC-klustret för en nod. Vi använder xtrabackup för att hämta data, vi kontrollerar också efter exekverad gtid i xtrabackup_binlog_info för att säkerställa att säkerhetskopian kommer att återställas korrekt och att replikering kan konfigureras. Vi utför också lite av konfigurationen och ser till att slavnoden kan använda GTID-replikering. Det finns ett par gotchas här - det är inte möjligt att köra 'RESET MASTER' med 'mysql_replication'-modulen från och med Ansible 2.7.10, det borde vara möjligt att göra det i 2.8, närhelst det kommer ut. Vi var tvungna att använda "shell"-modulen för att köra MySQL CLI-kommandon. När du bygger om Galera-noden från extern källa måste du komma ihåg att återskapa alla nödvändiga användare (åtminstone användare som används för SST). Annars kommer de återstående noderna inte att kunna gå med i klustret.

Galera roll

Slutligen, detta är rollen i vilken vi installerar PXC på återstående två noder. Vi kör det på alla noder, den första kommer att få "production" my.cnf istället för sin "bootstrap"-version. Återstående två noder kommer att ha PXC installerad och de kommer att få SST från den första noden i klustret.

Sammanfattning

Som du kan se kan du enkelt skapa en enkel, återanvändbar Ansible-spelbok som kan användas för att distribuera Percona XtraDB Cluster och konfigurera den för att vara en slav av fristående MySQL-nod. För att vara ärlig, för att migrera en enskild server, kommer detta förmodligen inte att ha någon mening eftersom att göra detsamma manuellt kommer att vara snabbare. Ändå, om du förväntar dig att du kommer att behöva köra om den här processen ett par gånger, kommer det definitivt att vara vettigt att automatisera den och göra den mer tidseffektiv. Som vi sa i början är detta inte på något sätt produktionsfärdig spelbok. Det är mer ett proof of concept, något du kan utöka för att göra det lämpligt för din miljö. Du kan hitta arkiv med spelboken här:http://severalnines.com/sites/default/files/ansible.tar.gz

Vi hoppas att du tyckte att det här blogginlägget var intressant och värdefullt, tveka inte att dela med dig av dina tankar.