Migratie automatiseren van standalone MySQL naar Galera Cluster met Ansible

Databasemigraties schalen niet goed. Meestal moet u een groot aantal tests uitvoeren voordat u de trekker kunt overhalen en van oud naar nieuw kunt overschakelen. Migraties worden meestal handmatig gedaan, omdat het grootste deel van het proces zich niet leent voor automatisering. Maar dat betekent niet dat er geen ruimte is voor automatisering in het migratieproces. Stelt u zich eens voor dat u een aantal nodes instelt met nieuwe software, ze voorziet van gegevens en handmatig replicatie tussen oude en nieuwe omgevingen configureert. Dit duurt dagen. Automatisering kan erg handig zijn bij het inrichten van een nieuwe omgeving en het voorzien van data. In deze blogpost zullen we een zeer eenvoudige migratie bekijken - van standalone Percona Server 5.7 naar een Percona XtraDB Cluster 5.7 met 3 knooppunten. We zullen Ansible gebruiken om dat te bereiken.

Omgevingsbeschrijving

Allereerst een belangrijke disclaimer - wat we hier gaan laten zien, is slechts een schets van wat je misschien in productie zou willen nemen. Het werkt wel op onze testomgeving, maar het kan zijn dat er aanpassingen nodig zijn om het geschikt te maken voor uw omgeving. In onze tests hebben we vier Ubuntu 16.04 VM's gebruikt die zijn ingezet met Vagrant. Eén bevat standalone Percona Server 5.7, de overige drie worden gebruikt voor Percona XtraDB Cluster-knooppunten. We gebruiken ook een aparte node voor het draaien van ansible playbooks, hoewel dit geen vereiste is en het playbook ook vanuit een van de nodes kan worden uitgevoerd. Bovendien is SSH-connectiviteit beschikbaar tussen alle nodes. Je moet verbinding hebben vanaf de host waar je ansible draait, maar de mogelijkheid om te ssh tussen nodes is handig (vooral tussen master en nieuwe slave - we vertrouwen hierop in het playbook).

Playbook-structuur

Ansible-playbooks hebben doorgaans een gemeenschappelijke structuur:u maakt rollen aan die aan verschillende hosts kunnen worden toegewezen. Elke rol bevat taken die erop moeten worden uitgevoerd, sjablonen die zullen worden gebruikt, bestanden die worden geüpload, variabelen die zijn gedefinieerd voor dit specifieke playbook. In ons geval is het draaiboek heel eenvoudig.

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

We hebben een aantal rollen gedefinieerd - we hebben een hoofdrol, die bedoeld is om een aantal sanity-checks uit te voeren op het zelfstandige knooppunt. Er is een slave-knooppunt, dat wordt uitgevoerd op een van de Galera-knooppunten om het te configureren voor replicatie en om de asynchrone replicatie in te stellen. Dan hebben we een rol voor alle Galera-knooppunten en een rol voor het eerste Galera-knooppunt om het cluster ervan op te starten. Voor Galera-rollen hebben we een aantal sjablonen die we zullen gebruiken om my.cnf-bestanden te maken. We zullen ook lokale .my.cnf gebruiken om een gebruikersnaam en wachtwoord te definiëren. We hebben een bestand met een aantal variabelen die we misschien willen aanpassen, net als wachtwoorden. Eindelijk hebben we een inventarisbestand, dat hosts definieert waarop we het playbook zullen draaien, we hebben ook het playbook-bestand met informatie over hoe dingen precies moeten worden uitgevoerd. Laten we eens kijken naar de afzonderlijke stukjes.

Inventarisbestand

Dit is een heel eenvoudig bestand.

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

We hebben drie groepen, 'galera', die alle Galera-knooppunten bevat, 'first_node', die we zullen gebruiken voor de bootstrap en ten slotte 'master', die ons stand-alone Percona Server-knooppunt bevat.

Playbook.yml

Het bestand playbook.yml bevat de algemene richtlijnen over hoe het playbook moet worden uitgevoerd.

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

Zoals je kunt zien, beginnen we met het zelfstandige knooppunt en passen we taken toe die verband houden met de rol 'master' (we zullen dit verderop in dit bericht in detail bespreken).

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

Ten tweede gaan we naar het knooppunt gedefinieerd in de groep 'first_node' en passen we twee rollen toe:'first_node' en 'slave'. De eerste is bedoeld om een PXC-cluster met één knooppunt te implementeren, de laatste zal deze configureren om als slaaf te werken en de replicatie in te stellen.

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

Ten slotte gaan we door alle Galera-knooppunten en passen we de 'galera'-rol op ze allemaal toe.

DevOps-gids voor databasebeheer van verschillendenines Lees meer over wat u moet weten om uw open source-databases te automatiseren en beherenGratis downloaden

Variabelen

Voordat we naar rollen gaan kijken, willen we de standaardvariabelen noemen die we voor dit draaiboek hebben gedefinieerd.

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

Zoals we al zeiden, is dit een heel eenvoudig speelboek zonder veel aanpassingsmogelijkheden. U kunt gebruikers en wachtwoorden configureren en dit is het eigenlijk. Eén probleem:zorg ervoor dat het root-wachtwoord van de zelfstandige node hier overeenkomt met 'root_password', anders zou het playbook daar geen verbinding kunnen maken (het kan worden uitgebreid om het te verwerken, maar dat hebben we niet behandeld).

Dit bestand heeft weinig waarde, maar als vuistregel wilt u elk bestand dat inloggegevens bevat, versleutelen. Uiteraard is dit om veiligheidsredenen. Ansible wordt geleverd met ansible-vault, die kan worden gebruikt om bestanden te coderen en te decoderen. We zullen hier geen details bespreken, alles wat u moet weten is beschikbaar in de documentatie. Kortom, u kunt eenvoudig bestanden coderen met wachtwoorden en uw omgeving zo configureren dat de playbooks automatisch kunnen worden gedecodeerd met behulp van een wachtwoord uit het bestand of met de hand kunnen worden doorgegeven.

Rollen

In dit gedeelte zullen we de rollen bespreken die in het draaiboek zijn gedefinieerd en samenvatten waarvoor ze bedoeld zijn.

Hoofdrol

Zoals we al zeiden, is deze rol bedoeld om een sanity check uit te voeren op de configuratie van de standalone MySQL. Het zal vereiste pakketten installeren zoals percona-xtrabackup-24. Het creëert ook een replicatiegebruiker op het hoofdknooppunt. Een configuratie wordt beoordeeld om ervoor te zorgen dat de server_id en andere replicatie- en binaire log-gerelateerde instellingen zijn ingesteld. GTID is ook ingeschakeld omdat we erop vertrouwen voor replicatie.

First_node-rol

Hier wordt de eerste Galera-node geïnstalleerd. Percona-repository wordt geconfigureerd, my.cnf wordt gemaakt op basis van de sjabloon. PXC wordt geïnstalleerd. We voeren ook wat opruimacties uit om onnodige gebruikers te verwijderen en om deze aan te maken, wat vereist is (rootgebruiker met het wachtwoord van onze keuze, gebruiker vereist voor SST). Ten slotte wordt het cluster opgestart met behulp van dit knooppunt. We vertrouwen op het lege 'wsrep_cluster_address' als een manier om het cluster te initialiseren. Dit is de reden waarom we later nog steeds de 'galera'-rol uitvoeren op het eerste knooppunt - om de initiële my.cnf te verwisselen met de laatste, die 'wsrep_cluster_address' bevat met alle leden van het cluster. Eén ding is het onthouden waard:als je een rootgebruiker met wachtwoord aanmaakt, moet je oppassen dat je MySQL niet afsluit, zodat Ansible andere stappen van het playbook kan uitvoeren. Een manier om dat te doen is door .my.cnf te voorzien van de juiste gebruikersnaam en het juiste wachtwoord. Een ander zou zijn om te onthouden om altijd de juiste login_user en login_password in te stellen in de 'mysql_user'-module.

Slaafrol

In deze rol draait alles om het configureren van replicatie tussen een zelfstandig knooppunt en het PXC-cluster met één knooppunt. We gebruiken xtrabackup om de gegevens op te halen, we controleren ook op uitgevoerde gtid in xtrabackup_binlog_info om ervoor te zorgen dat de back-up correct wordt hersteld en dat replicatie kan worden geconfigureerd. We voeren ook een deel van de configuratie uit en zorgen ervoor dat de slave-node GTID-replicatie kan gebruiken. Er zijn hier een paar valkuilen - het is niet mogelijk om 'RESET MASTER' uit te voeren met de module 'mysql_replication' vanaf Ansible 2.7.10, het zou mogelijk moeten zijn om dat in 2.8 te doen, wanneer het ook uitkomt. We moesten de 'shell'-module gebruiken om MySQL CLI-opdrachten uit te voeren. Bij het opnieuw opbouwen van Galera-knooppunt vanaf een externe bron, moet u eraan denken om alle vereiste gebruikers opnieuw aan te maken (ten minste de gebruiker die voor SST wordt gebruikt). Anders kunnen de overige knooppunten geen lid worden van het cluster.

Galera-rol

Ten slotte is dit de rol waarin we PXC installeren op de resterende twee knooppunten. We draaien het op alle knooppunten, de eerste krijgt "productie" my.cnf in plaats van de "bootstrap" -versie. Op de resterende twee knooppunten is PXC geïnstalleerd en krijgen ze SST van het eerste knooppunt in het cluster.

Samenvatting

Zoals u kunt zien, kunt u eenvoudig een eenvoudig, herbruikbaar Ansible-playbook maken dat kan worden gebruikt voor het implementeren van Percona XtraDB Cluster en het configureren als een slaaf van een stand-alone MySQL-knooppunt. Om eerlijk te zijn, voor het migreren van een enkele server heeft dit waarschijnlijk geen zin, omdat het sneller gaat om hetzelfde handmatig te doen. Maar als u verwacht dat u dit proces een paar keer opnieuw moet uitvoeren, is het zeker zinvol om het te automatiseren en het tijdbesparend te maken. Zoals we in het begin al zeiden, is dit geenszins een productieklaar draaiboek. Het is meer een proof of concept, iets dat je kunt uitbreiden om het geschikt te maken voor jouw omgeving. Je kunt het archief met het playbook hier vinden:http://severalnines.com/sites/default/files/ansible.tar.gz

We hopen dat je deze blogpost interessant en waardevol vond, aarzel niet om je mening te delen.