Databasemigrationer skaleres ikke godt. Typisk skal du udføre en hel del tests, før du kan trykke på aftrækkeren og skifte fra gammelt til nyt. Migreringer udføres normalt manuelt, da det meste af processen ikke egner sig til automatisering. Men det betyder ikke, at der ikke er plads til automatisering i migreringsprocessen. Forestil dig at opsætte et antal noder med ny software, forsyne dem med data og konfigurere replikering mellem gamle og nye miljøer manuelt. Dette tager dage. Automatisering kan være meget nyttig, når du opsætter et nyt miljø og forsyner det med data. I dette blogindlæg vil vi tage et kig på en meget simpel migrering - fra selvstændig Percona Server 5.7 til en 3-node Percona XtraDB Cluster 5.7. Vi vil bruge Ansible til at opnå det.
Miljøbeskrivelse
Først og fremmest en vigtig ansvarsfraskrivelse - det, vi skal vise her, er kun et udkast til, hvad du kunne tænke dig at køre i produktionen. Det virker på vores testmiljø, men det kan kræve ændringer for at gøre det egnet til dit miljø. I vores test brugte vi fire Ubuntu 16.04 VM'er installeret ved hjælp af Vagrant. Den ene indeholder selvstændig Percona Server 5.7, de resterende tre vil blive brugt til Percona XtraDB Cluster noder. Vi bruger også en separat node til at køre mulige playbooks, selvom dette ikke er et krav, og playbook kan også udføres fra en af noderne. Derudover er SSH-forbindelse tilgængelig mellem alle noderne. Du skal have forbindelse fra værten, hvor du kører ansible, men at have mulighed for at ssh mellem noder er nyttigt (især mellem master og ny slave - vi stoler på dette i playbook).
Playbook-struktur
Ansible playbooks deler typisk fælles struktur - du opretter roller, som kan tildeles forskellige værter. Hver rolle vil indeholde opgaver, der skal udføres på den, skabeloner, der vil blive brugt, filer, der vil blive uploadet, variabler, der er defineret for denne særlige playbook. I vores tilfælde er spillebogen meget enkel.
.├── inventory├── playbook.yml├── roles│ ├── first_node│ │ ├── min.cnf.j2│ hovedopgave ─ ├│s│s. yml│ │ └── skabeloner│ │ └── my.cnf.j2│ ├── galera│ │ ├── opgaver│ └└└ hoved ─ │ min skabelon─l │ min. cnf.j2│ ├── master│ │ └── opgaver│ │ └── main.yml│ └── slave│ └── opgaver──└ hoved─ym └l─l─m. /kode>
Vi definerede et par roller - vi har en masterrolle, som er beregnet til at udføre nogle fornuftstjek på den selvstændige node. Der er en slaveknude, som vil blive udført på en af Galera-knuderne for at konfigurere den til replikering og opsætte den asynkrone replikering. Så har vi en rolle for alle Galera-noder og en rolle for den første Galera-knude til at starte klyngen fra den. Til Galera-roller har vi et par skabeloner, som vi vil bruge til at oprette my.cnf-filer. Vi vil også bruge lokal .my.cnf til at definere et brugernavn og en adgangskode. Vi har en fil, der indeholder et par variabler, som vi måske ønsker at tilpasse, ligesom adgangskoder. Endelig har vi en inventory-fil, som definerer værter, som vi vil køre playbook på, vi har også playbook-filen med information om, hvordan tingene præcist skal udføres. Lad os tage et kig på de enkelte bits.
Inventarfil
Dette er en meget simpel fil.
[galera]10.0.0.14210.0.0.14310.0.0.144[first_node]10.0.0.142[master]10.0.0.141
Vi har tre grupper, 'galera', som indeholder alle Galera-noder, 'first_node', som vi vil bruge til bootstrap og endelig 'master', som indeholder vores selvstændige Percona Server-node.
Playbook.yml
Filen playbook.yml indeholder de generelle retningslinjer for, hvordan playbook skal udføres.
- værter:master indsamle_fakta:ja bliver:sand pre_tasks:- navn:Installer Python2 rå: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, starter vi med den selvstændige node, og vi anvender opgaver relateret til rollen 'mester' (vi vil diskutere dette i detaljer længere nede i dette indlæg).
- værter:first_node indsamle_fakta:ja bliver:sand pre_tasks:- navn:Installer Python2 rå:test -e /usr/bin/python || (apt -y update &&apt install -y python-minimal) vars_files:- vars/default.yml roles:- { role:first_node } - { role:slave }
For det andet går vi til node defineret i 'first_node'-gruppen, og vi anvender to roller:'first_node' og 'slave'. Førstnævnte er beregnet til at implementere en enkelt node PXC-klynge, den senere vil konfigurere den til at fungere som en slave og opsætte replikeringen.
- værter:galera indsamle_fakta:ja bliver:sand før_opgaver:- navn:Installer Python2 raw:test -e /usr/bin/python || (apt -y update &&apt install -y python-minimal) vars_files:- vars/default.yml roles:- { role:galera }
Til sidst gennemgår vi alle Galera-noder og anvender 'galera'-rolle på dem alle.
Severalnines DevOps Guide til Database Management Lær om, hvad du skal vide for at automatisere og administrere dine open source-databaser. Download gratis Variabler
Før vi begynder at se nærmere på roller, vil vi gerne nævne standardvariabler, som vi har defineret for denne playbook.
sst_user:"sstuser"sst_password:"pa55w0rd"root_password:"pass"repl_user:"repl_user"repl_password:"repl1cati0n"
Som vi sagde, er dette en meget simpel spillebog uden mange muligheder for tilpasning. Du kan konfigurere brugere og adgangskoder, og det er dybest set det. One gotcha - sørg venligst for, at den selvstændige nodes root-adgangskode matcher 'root_password' her, da spillebogen ellers ikke ville være i stand til at oprette forbindelse der (den kan udvides til at håndtere det, men vi dækkede det ikke).
Denne fil er uden meget værdi, men som en tommelfingerregel vil du kryptere enhver fil, der indeholder legitimationsoplysninger. Det er naturligvis af sikkerhedsmæssige årsager. Ansible kommer med ansible-vault, som kan bruges til at kryptere og dekryptere filer. Vi vil ikke dække detaljer her, alt hvad du behøver at vide er tilgængeligt i dokumentationen. Kort sagt, du kan nemt kryptere filer ved hjælp af adgangskoder og konfigurere dit miljø, så spillebøgerne kan dekrypteres automatisk ved hjælp af adgangskode fra fil eller videregives i hånden.
Roller
I dette afsnit vil vi gennemgå roller, der er defineret i spillebogen, og opsummere, hvad de er beregnet til at udføre.
Mesterrolle
Som vi sagde, er denne rolle beregnet til at køre en fornuftskontrol på konfigurationen af den selvstændige MySQL. Det vil installere nødvendige pakker som percona-xtrabackup-24. Det opretter også replikeringsbruger på masternoden. En konfiguration gennemgås for at sikre, at server_id og andre replikerings- og binære log-relaterede indstillinger er indstillet. GTID er også aktiveret, da vi vil stole på det til replikering.
First_node-rolle
Her er den første Galera-node installeret. Percona repository vil blive konfigureret, my.cnf vil blive oprettet fra skabelonen. PXC vil blive installeret. Vi kører også en vis oprydning for at fjerne unødvendige brugere og oprette dem, som vil være påkrævet (rodbruger med adgangskoden efter vores valg, bruger krævet til SST). Endelig opstartes klyngen ved hjælp af denne node. Vi stoler på den tomme 'wsrep_cluster_address' som en måde at initialisere klyngen på. Dette er grunden til, at vi senere stadig udfører 'galera'-rollen på den første node - for at bytte initial my.cnf med den sidste, der indeholder 'wsrep_cluster_address' med alle medlemmer af klyngen. En ting, der er værd at huske - når du opretter en root-bruger med adgangskode, skal du passe på ikke at blive låst af MySQL, så Ansible kunne udføre andre trin i spillebogen. En måde at gøre det på er at give .my.cnf den korrekte bruger og adgangskode. En anden ville være at huske altid at indstille korrekt login_user og login_password i 'mysql_user'-modulet.
Slave rolle
Denne rolle handler om at konfigurere replikering mellem selvstændig node og enkelt node PXC-klyngen. Vi bruger xtrabackup til at hente dataene, vi tjekker også for udført gtid i xtrabackup_binlog_info for at sikre, at sikkerhedskopien bliver gendannet korrekt, og at replikering kan konfigureres. Vi udfører også lidt af konfigurationen og sikrer, at slavenoden kan bruge GTID-replikering. Der er et par gotchas her - det er ikke muligt at køre 'RESET MASTER' ved hjælp af 'mysql_replication'-modulet fra og med Ansible 2.7.10, det burde være muligt at gøre det i 2.8, når det kommer ud. Vi var nødt til at bruge 'shell'-modul til at køre MySQL CLI-kommandoer. Når du genopbygger Galera node fra ekstern kilde, skal du huske at genskabe eventuelle nødvendige brugere (mindst bruger brugt til SST). Ellers vil de resterende noder ikke være i stand til at slutte sig til klyngen.
Galera-rolle
Endelig er dette den rolle, hvor vi installerer PXC på de resterende to noder. Vi kører det på alle noder, den første får "produktion" my.cnf i stedet for sin "bootstrap" version. De resterende to noder vil have PXC installeret, og de vil få SST fra den første node i klyngen.
Oversigt
Som du kan se, kan du nemt oprette en enkel, genanvendelig Ansible-playbook, som kan bruges til at implementere Percona XtraDB Cluster og konfigurere den til at være en slave af den selvstændige MySQL-node. For at være ærlig, for migrering af en enkelt server, vil det sandsynligvis ikke have nogen mening, da det vil være hurtigere at gøre det samme manuelt. Alligevel, hvis du forventer, at du bliver nødt til at udføre denne proces igen et par gange, vil det helt sikkert give mening at automatisere den og gøre den mere tidseffektiv. Som vi sagde i begyndelsen, er dette på ingen måde produktionsklar spillebog. Det er mere et proof of concept, noget du kan udvide for at gøre det egnet til dit miljø. Du kan finde arkiv med spillebogen her:http://severalnines.com/sites/default/files/ansible.tar.gz
Vi håber, du fandt dette blogindlæg interessant og værdifuldt, tøv ikke med at dele dine tanker.