Hulpartikel overzicht

Hulpartikel

Linux redundantie tutorial 3: databases synchroniseren

Dit is het derde deel van onze Tutorial Series 'Een redundante VPS-omgeving inrichten'. Ben je een nieuwe redundante VPS-omgeving aan het inrichten, dan raden wij aan om bij deel 1 te beginnen en geen delen over te slaan.

In dit deel zetten wij de synchronisatie op van de databases die je op je VPS'en host. Het doel is om een SQL-cluster te maken, waarbij twee servers een identieke database bevatten. Bij downtime van één of meerdere servers zal de andere automatisch of handmatig (afhankelijk van je eigen keuze) de volledige functionaliteit van het cluster overnemen.

In deze tutorials gebruiken wij dit SQL-cluster om een database in combinatie met een of meerdere websites te gebruiken, bijvoorbeeld een WordPress- of PHP-website. Hoe je een SQL-cluster hieraan koppelt lichten wij later in deze tutorial series toe.

Voor het opzetten van een SQL-cluster gebruiken wij een MariaDB master-slave-configuratie. Bij een master-slave-setup is één van de VPS'en in je SQL-cluster de master en voert write-queries (write, drop, create, etc) uit naar zichzelf, en naar alle aan je cluster gekoppelde slave VPS'en. De slave VPS('en) voeren zelf hooguit read-queries uit (select from).

Kort gezegd is een write-query een actie waarbij data naar je database wordt weggeschreven en een read-query een actie waarbij data vanuit je database wordt opgehaald, zonder die te wijzigen.

  • Voer alle stappen in dit artikel uit met een gebruiker met root-rechten.
     
  • Zorg dat alle VPS'en dezelfde MariaDB-versie gebruiken (10.2 of nieuwer).
     
  • Poorten 3306 en 4008 van de SQL-servers moeten via het private network bereikbaar zijn voor je webservers en voor de SQL-servers.
     
  • Zet om veiligheidsredenen de publieke WAN uit van je SQL-servers. De SQL-servers moeten alleen via het private network voor elkaar en de webservers bereikbaar zijn.
     
  • Voor enkele algemene tips, raadpleeg ons artikel 'best practise tips voor SQL-clusters'.

De master-slave-replicatie opzetten

Voor het opzetten van je master-slave-setup zijn er enkele aanpassingen nodig in de MariaDB-configuratie, bijvoorbeeld om ervoor te zorgen dat je VPS'en elkaar correct kunnen identificeren. Daarnaast maak je een SQL-gebruiker aan die specifiek gebruikt wordt voor de slave-vps om met de master te kunnen communiceren.

 

Stap 1

Verbind met beide VPS'en via SSH of de VPS console in je controlepaneel. Kies vervolgens één van je VPS'en die vanaf dit punt dienst gaat doen als master van je database cluster en noteer welke dit is. Open nu op deze VPS je MySQL-configuratiebestand:

CentOS:

nano /etc/my.cnf.d/server.cnf

Ubuntu:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

 

Stap 2

In je configuratiebestand staat onder [mysqld] de regel #bind-address=0.0.0.0 of #bind-address=127.0.0.1 (al dan niet met # ervoor). MariaDB luistert standaard enkel naar TCP/IP verbindingen van de localhost. Dit betekent dat de slave(s) in je cluster standaard geen rechten hebben om met je master te verbinden.

Verwijder de # en pas de 0.0.0.0 aan naar ::

bind-address=::

Let op: als je in dit bestand de optie skip-networking ziet staan, zorg dan dat deze optie niet op 1 staat. Anders kunnen slave(s) niet verbinden met je master.


 

Stap 3

Voeg direct onder [mariadb] de inhoud hieronder toe:

log-bin
log_basename=dbmaster
server_id=1
wsrep_gtid_mode=1
gtid_strict_mode=1
  • log-bin: activeert binary logging. In binary logs worden alle veranderingen in de databases bijgehouden. Hiervoor wordt gebruik gemaakt van een index file en binary log files.
  • log_basename: is de naam die wordt toegevoegd aan de naam van alle logbestanden die je cluster aanmaakt (niet enkel de binary logs). Gebruik je deze optie niet, dan wordt je hostname gebruikt, wat problemen geeft wanneer die om wat voor reden dan ook verandert.
  • server_id: is het nummer waarmee je VPS geïdentificeerd wordt in het cluster. Dit moet per VPS uniek zijn.
  • wsrep_gtid_mode: schakelt het gebruik van global transaction ID's (GTID)in. Deze zijn vanaf MariaDB 10.0 geïntroduceerd in MariaDB. Hierbij worden events (i.e. nummers) gekoppeld aan iedere event group in de binary logs (binlogs). Bij replicatie van event groups wordt de global transaction ID intact gehouden. Dit maakt het eenvoudiger om dezelfde binlogs events te identificeren. Voor een gedetailleerdere toelichting, zie de documentatie hierover van MariaDB.
  • gtid_strict_mode: door deze optie op 1 te zetten, sluiten de GTID's van de master en slave op elkaar aan. Stel dat de originele master GTID 0-1-500 heeft en vervolgens onbereikbaar wordt, dan schrijft de slave de nieuwe wijzigingen weg vanaf 0-2-501 (de 1 en 2 identificeren welke server acties uitvoert).

 

Stap 4

Sla je wijzigingen op en sluit het bestand (ctrl + x > y > enter). Herhaal bovenstaande stappen op je andere VPS die je als slave gaat gebruiken. Geef daarbij een unieke server_id in stap 3.

De reden dat je dit ook op je slave-VPS instelt, is dat dit nodig is voor de failover functionaliteit die je in het volgende deel opzet. Zo verzeker je je setup ervan dat als je master uitvalt en een slave de nieuwe master wordt, de oude master (en eventuele andere slave(s)) daarmee kunnen verbinden wanneer die weer beschikbaar is.


 

Stap 5

Herstart MariaDB op alle VPS'en:

systemctl restart mariadb

 

Stap 6

Log in op een SQL-shell op de master- en Slave-VPS (verander eventueel root naar de daadwerkelijke gebruikersnaam). Er zal om een wachtwoord worden gevraagd van je root-user:

mysql -u root -p

 

Stap 7

Maak met onderstaande stappen een MariaDB-gebruiker aan op je master- en slave-VPS. Deze gebruiker zal door de slave(s) gebruikt worden om met de master te verbinden. 'Slavename' en 'password' vervang je door de gebruikersnaam en het wachtwoord die je wil gebruiken voor je slave(s) om met de master te verbinden.

CREATE USER 'slavename'@'LOCALHOST' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'slavename'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Gebruik uit veiligheidsoverwegingen nooit hetzelfde wachtwoord van de root-gebruiker ook voor de slave-user.


 

Stap 8

Voer het volgende commando uit en herhaal het op iedere VPS in je database-cluster. Pas het private network IP-adres aan naar die van de andere VPS dan de VPS waarop je het commando uitvoert. Stel dat je twee VPS'en hebt met IP's 192.168.1.1 en 192.168.1.2 en je voert het commando uit vanaf de VPS met het IP 192.168.1.1, dan verander je het IP in dit commando naar 192.168.1.2.

GRANT REPLICATION SLAVE ON *.* TO 'slavename'@'192.168.1.1' IDENTIFIED BY 'password' WITH GRANT OPTION;

 

Stap 9

Controleer met het volgende commando de status van je Master:

SHOW MASTER STATUS;

De output zal er ongeveer als volgt uitzien:

mariadb master status

De GTID heb je in stap 18 nodig om de slave(s) aan te geven vanaf welk punt zij de database moeten repliceren.

Achtergrondinformatie: Voor MariaDB 10.0 werd de waarde van file & position uit dit overzicht gebruikt om de slave(s) aan te geven waar ze moeten beginnen met de replicatie van de databases. Met de komst van global transaction ID's (zie stap 3) is dit echter niet meer nodig en wordt de global transcation ID (GTID) gebruikt.


 

Stap 10

Zijn er sinds je aan deze tutorial bent begonnen geen wijzigingen geweest aan je MariaDB-database, ga dan door naar stap 15. Zijn er wel wijzigingen geweest, kopieer dan eerst je database naar je slave(s) door de volgende stappen te gebruiken.

Plaats een tijdelijke lock op je database op beide VPS'en, zodat deze read-only wordt. Je voorkomt hiermee dat er veranderingen plaatsvinden in je database(s) terwijl je je database(s) overzet.

FLUSH TABLES WITH READ LOCK; 

 

Stap 11

Pplaats vanuit command-line de back-up over. Hieronder lichten wij de command-line stappen toe (of gebruik phpMyAdmin om de database te exporteren op de master en te importeren op de slave).

Bekijk eerst welke databases je allemaal gebruikt zodat je zeker weet dat je de juiste naam gebruikt voor stap 11:

SHOW DATABASES;
exit

 

Stap 12

Vervolgens back-up je je database(s). Er zal wederom om je root wachtwoord worden gevraagd:

mysqldump -u root -p wordpress > /var/lib/mysql/wordpress-dump.sql

Voer dit commando uit voor iedere database waarvan je een back-up wil overzetten naar je slave VPS. Vervang wordpress door de daadwerkelijke naam van de databases en wordpress-dump.sql door de gewenste back-up bestandsnaam.


 

Stap 13

Verbind via SSH met je slave-VPS en kopieer de back-up met een Rsync-commando (zie het vorige deel als je Rsync nog niet hebt ingesteld):

rsync -e "ssh -p 22 -o StrictHostKeyChecking=no" transip@192.168.1.1:/var/lib/mysql/wordpress-dump.sql /var/lib/mysql/ --no-perms --no-owner --no-group --no-times

Vervang 22 door het nummer van je SSH-poort, de gebruikersnaam en het IP naar je daadwerkelijke gebruikersnaam en IP, en de back-up bestandsnaam en locatie naar de naam en locatie die je bj de stappen hierboven gebruikte.


 

Stap 14

Importeer de back-up door het volgende commando uit te voeren op je slave-VPS (wijzig de database-naam en locatie naar de daadwerkelijke naam en locatie):

mysql -u root -p wordpress < /var/lib/mysql/wordpress-dump.sql

Vergeet niet op je master de lock te herstellen:

mysql -u root -p
FLUSH TABLES WITH READ LOCK; 

Stap 15

We gaan nu de slave configureren om voor write-queries de master te gebruiken die we in de eerdere stappen hebben geconfigureerd. Start eerst een SQL shell op je slave als je daar nog niet op zit:

mysql -u root -p

 

Stap 16

Stop de slave met het commando:

STOP SLAVE;

 

Stap 17

Wij vertellen de slave nu om de master te gebruiken voor write-acties, en waar hij de master kan vinden:

CHANGE MASTER TO 
MASTER_HOST='192.168.1.1',
MASTER_USER='slavename',
MASTER_PASSWORD='password',
MASTER_PORT=3306,
MASTER_CONNECT_RETRY=10,
MASTER_USE_GTID=current_pos;
  • MASTER_HOST: Gebruik hier het (bij voorkeur) interne IP van je master.
  • MASTER_USER: De gebruikersnaam die je in stap 6 aan hebt gemaakt.
  • MASTER_PASSWORD: Het wachtwoord dat bij deze gebruiker hoort.
  • MASTER_PORT: De poort die MariaDB gebruikt. Voeg deze toe aan je firewall als je dat nog niet gedaan hebt.
  • MASTER_CONNECT_RETRY: Het aantal pogingen dat gebruikt wordt om met de master te verbinden indien de eerste poging niet slaagt.
  • MASTER_USE_GTID: Wanneer je master uitvalt, wordt automatisch een van je gekoppelde slave(s) de nieuwe master (hier komen we nog op terug). De oude master zal wanneer die weer bereikbaar is dan een slave zijn. Door de optie current_pos te gebruiken zal wanneer de oude master (die dus nu een slave is) weten vanaf welke global transaction ID de replicatie gestart moet worden. 

 

Stap 18

Sluit de MySQL-shell af en upgrade op alle VPS'en in je cluster de system tables door op de VPS'en de volgende commando's uit te voeren:

exit
mysql_upgrade -u root -p

 

Stap 19

Je slave heeft waarschijnlijk nog een andere gtid dan je master (zie stap 9). Corrigeer je slave-VPS met de onderstaande commando's om vanaf de gtid van de master te synchronizeren. Vervang hier de waarde x-x-x door de waarde die je in stap 9 hebt genoteerd:

mysql -u root -p 
RESET MASTER;
SET GLOBAL gtid_slave_pos='x-x-x';
START SLAVE UNTIL master_gtid_pos='x-x-x';

Je krijgt een melding 'Query OK' te zien. Deze geeft echter niet aan of je slave daadwerkelijk goed verbonden is. Hiervoor gebruik je het commando:

SHOW SLAVE STATUS\G;

Problemen oplossen

Alle vormen van database clusters zijn gecompliceerd en het is dan ook onmogelijk uit te sluiten dat door omstandigheden je een probleem ervaart, bijvoorbeeld als een slave een tijd offline is geweest en een foutieve GTID probeert te gebruiken. In ons artikel


 

Je databasecluster is nu geconfigureerd om automatisch je databases te synchronizeren. Daarmee zijn wij aan het eind gekomen van dit deel. Klik hier om verder te gaan met deel 5: het instellen van MaxScale en MariaDB monitor waarin je o.a. de automatische failover functionaliteit van je databasecluster configureert.

 

Mocht je aan de hand van dit artikel nog vragen hebben, aarzel dan niet om onze supportafdeling te benaderen. Je kunt hen bereiken via de knop 'Neem contact op' aan de onderzijde van deze pagina.

Wil je dit artikel met andere gebruikers bespreken, laat dan vooral een bericht achter onder 'Reacties'.

Heb je ook een goed idee?

Stuur jouw idee in! Met genoeg stemmen komt jouw idee op onze wishlist!

Heeft dit artikel je geholpen?

Maak een account aan of log in om een beoordeling achter te laten.

Reacties

Maak een account aan of log in om een reactie te plaatsen.

Kom je er niet uit?

Ontvang persoonlijke hulp van onze supporters

Neem contact op