In het vorige deel heb je de master-slave synchronisatie opgezet. Eenvoudige handmatige, of volledige automatische failover-functionaliteit is daar nog niet bij inbegrepen. In dit deel zet je de failover-functionaliteit op met behulp van MaxScale (en MariaDB Monitor).

• MariaDB MaxScale is een database proxy die de high availability, schaalbaarheid en beveiliging van MariaDB vereenvoudigd / verbeterd. Enkele features die MaxScale ondersteund zijn: automatische failover, read-write splitting en query blocking (i.e. een soort database firewall). Zie deze pagina voor een volledig overzicht van de features.
   
• MariaDB Monitor is een onderdeel van MaxScale en is verantwoordelijk voor het monitoren van de status van het cluster, en het uitvoeren van of een handmatige failover of volledig automatische failover en rejoin wanneer een server offline komt na donwtime. In het geval van de automatische failover betekent dit dat als een master offline gaat, automatisch een van de slaves wordt gepromoveert tot nieuwe master. Wanneer de oude master weer beschikbaar is, wordt die als slave toegevoegd.

Handmatige- of automatische failover gebruiken?

In stap 8 van het installeren en configureren van MaxScale, maak je een keuze uit automatische, of handmatige failover. De keuze die je maakt heeft ook implicaties voor het volgende deel, waarin wij uitleggen hoe je je SQL-cluster combineert met een PHP-applicatie (e.g. een website). Wij staan dan ook eerst stil bij waarom je voor automatische- of handmatige failover zou kiezen.

Waarom geen automatische failover

Er is één zeer belangrijke reden waarom je niet zou kiezen voor automatische failover, en dat is ook direct een bijzonder goede reden: split-brain-situaties.

Split-brain-situaties ontstaan kort gezegd wanneer SQL-servers elkaar niet meer kunnen zien, maar nog wel bereikbaar zijn voor de buitenwereld. Er ontstaat dan een situatie waar beide / alle SQL-servers tot master gepromote worden en enkel naar zichzelf data wegschrijven, zonder dat ze dit van elkaar weten. De databases op de VPS'en krijgen dan een verschillende inhoud per SQL-server.

Het is bijzonder lastig en vervelend om de gevolgen van een split-brain-probleem op te lossen. De kans op een split-brain-situatie is zeer klein, zeker als je met meer dan twee servers en availability zones werkt, maar de mogelijke gevolgen zijn groot. Maak daarom een weloverwogen beslissing voor je kiest voor handmatige- of automatische failover. In het geval van handmatige failover kies je dus voor consistentie van de databases, over het gemak van volledig geautomatiseerde failover.

Split-brain is een dusdanig belangrijk en uitgebreid onderwerp, dat wij hier een apart artikel aan hebben gewijd. Klik hier voor ons artikel over het voorkomen van split-brain problemen.

Waarom wel automatische failover

In nagenoeg alle gevallen is het prima om te kiezen voor automatische failover. Uiteindelijk is de kans op een split-brain situatie klein, zeker wanneer je drie of meer SQL-servers zou gebruiken verspreid over drie of meer availability zones.

Stel dat een VPS offline gaat omdat bijvoorbeeld de CPU van een hypervisor kapot gaat, of een VPS-storageserver offline gaat, dan is het heel fijn om automatische failover te hebben. Ben je bezig de configuratie van je applicatie of website aan te passen en haal je een VPS offline? Dan is het ook een prima oplossing. Je hebt er in een dergelijk scenario geen enkel omkijken naar en MaxScale neemt verder alles voor zijn rekening.

Gebruik je een database waar alleen maar read-queries op worden uitgevoerd of write-queries alleen door jezelf worden uitgevoerd (e.g. bij een WordPress website waar bezoekers zich niet kunnen registreren of wijzigingen kunnen uitvoeren), dan is automatische failover ook een uitstekende optie. Je loopt dan in principe geen risico op split-brain-situaties.

Er zijn meer scenario's denkbaar dan hier beschreven worden. Mis je nog informatie in dit, of het split-brain-artikel om een keuze te maken voor automatische of handmatige failover? Laat ons dat weten in een reactie op dit artikel, of het split-brain-artikel, dan proberen wij je vraag zo snel mogelijk in dit artikel te beantwoorden.

MaxScale installeren en configureren

In de volgende stappen installeren en configureren wij MaxScale. MariaDB Monitor is een onderdeel van MaxScale en hoeft niet afzonderlijk geïnstalleerd te worden. Doorloop de stappen hieronder op alle VPS'en in je database-cluster.

Stap 1

Maxscale gebruikt poort 4006 voor Round Robin (loadbalancing) verbindingen en poort 4008 voor Read-Write splitting. Open beide poorten op alle SQL-servers in je setup. 

Vervang hier 192.168.1.0/24 door de range waar de adressen van je private network in vallen. Alternatief kun je ook ieder private IP-adres van je SQL-servers één voor één whitelisten met deze commando's:

Firewalld (CentOS, AlmaLinux, Rocky Linux)

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=4006 protocol=tcp accept'
firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=4008 protocol=tcp accept' firewall-cmd --reload 
firewall-cmd --reload

UFW (Ubuntu/Debian):

ufw allow from 192.168.1.0/24 to any port 4006
ufw allow from 192.168.1.0/24 to any port 4008

Stap 2

Installeer nu eerst MaxScale; het is namelijk geen standaard onderdeel van MariaDB. Op moment van de laatste update van deze handleiding (2022) is 6.2.4 de huidige versie van MaxScale. Voor CentOS Stream 9, Alma Linux 9 en Rocky Linux 9 zijn op dit moment geen aparte versies beschikbaar.

De nieuwst beschikbare versie vind je hier en hier.

De installatie link verschilt per OS en versie van je OS. Controleer dus altijd de bovenstaande link voor het correcte adres.

CentOS 7:

yum -y install https://downloads.mariadb.com/MaxScale/latest/centos/7/x86_64/maxscale-6.2.4-1.rhel.7.x86_64.rpm

CentOS Stream 8 / AlmaLinux 8 / Rocky Linux 8:

dnf -y install https://downloads.mariadb.com/MaxScale/latest/centos/8/x86_64/maxscale-6.2.4-1.rhel.8.x86_64.rpm

Ubuntu 18.04

wget https://dlm.mariadb.com/2344070/MaxScale/6.4.1/packages/ubuntu/bionic/x86_64/maxscale-6.4.1-1.ubuntu.bionic.x86_64.deb
dpkg -i maxscale-2.2.14-1.ubuntu.bionic.x86_64.deb
apt-get install -f

Ubuntu 20.04

wget https://dlm.mariadb.com/2344057/MaxScale/6.4.1/packages/ubuntu/focal/x86_64/maxscale-6.4.1-1.ubuntu.focal.x86_64.deb
dpkg -i maxscale-6.4.1-1.ubuntu.focal.x86_64.deb
apt-get install -f

Ubuntu 22.04

wget https://dlm.mariadb.com/2344079/MaxScale/6.4.1/packages/ubuntu/jammy/x86_64/maxscale-6.4.1-1.ubuntu.jammy.x86_64.deb
dpkg -i maxscale-6.4.1-1.ubuntu.jammy.x86_64.deb
apt-get install -f

Stap 3

Zorg dat MaxScale na een reboot automatisch start:

systemctl enable maxscale

Stap 4

Voor MaxScale heb je een nieuwe database-gebruiker nodig. Deze gebruiker wordt door de services waar MaxScale uit bestaat gebruikt om gebruikersauthenticatie-gegevens op te halen.

Je maakt met de volgende commando's de gebruiker aan (je bent vrij de naam maxscale en het wachtwoord maxscale_pw naar wens te veranderen):

mysql -u root -p
CREATE USER 'maxscale'@'%' IDENTIFIED BY 'maxscale_pw';
GRANT SELECT ON mysql.user TO 'maxscale'@'%';
GRANT SELECT ON mysql.db TO 'maxscale'@'%';
GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'%';
GRANT SELECT ON mysql.roles_mapping TO 'maxscale'@'%';
GRANT SHOW DATABASES ON *.* TO 'maxscale'@'%';
exit

Stap 5

Vervolgens geneer je een versleuteld wachtwoord. Voor een aantal van de MaxScale services zet je namelijk een wachtwoord in het configuratiebestand /etc/maxscale.cnf. Uit veiligheidsoverwegingen is het aan te raden het wachtwoord te versleutelen.

Je versleutelt je wachtwoord met onderstaande commando's, waarbij je maxscale_pw vervangt door het wachtwoord dat je gebruikt voor de gebruiker maxscale in de vorige stap.

maxkeys /var/lib/maxscale/
maxpasswd maxscale_pw

Je krijgt als output een reeks karakters te zien zoals 96F99AA1315BDC3604B006F427DD9484. Dit is het versleutelde wachtwoord en heb je nodig voor de volgende stap. Zorg dat je het gegenereerde wachtwoord goed bewaard.

Let op: het gegenereerde wachtwoord verschilt per server. Je kunt dus niet dit versleutelde wachtwoord op een andere VPS gebruiken maar moet op iedere VPS een eigen versleuteld wachtwoord genereren.

Stap 6

Het commando maxkeys /var/lib/maxscale maakt een set encryptiesleutels aan in /var/lib/maxscale/.secrets. De eigenaar van dit bestand wordt automatisch de gebruiker 'root' of je eigen gebruikersnaam, maar de gebruiker 'maxscale' is degene die toegang nodig heeft.

Verander de eigenaar naar maxscale.

chown maxscale /var/lib/maxscale/.secrets

Je past de rechten verder niet aan met chmod, want dan werkt maxscale niet meer (in de source code is gedefinieerd dat de file eigenaar enkel leesrechten mag hebben, en de group of derden mogen helemaal geen rechten hebben).

Stap 7

Open je MaxScale-configuratiebestand:

nano /etc/maxscale.cnf

Stap 8

Je ziet in dit bestand al een default-configuratie. Pas dit bestand aan zodat het er uit ziet zoals in het voorbeeld hieronder (maar dan met je eigen gegevens).

Er zitten enkele opties bij die zeer belangrijk zijn voor de wijze waarop je je SQL-cluster wil beheren. Wij raden dan ook aan de toelichting onder de configuratie zeker niet over te slaan.

# MaxScale documentation:
# https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22/

# Global parameters
#
# Complete list of configuration options:
# https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-mariadb-maxscale-configuration-usage-scenarios/

[maxscale]
threads=auto

# Server definitions
#
# Set the address of the server to the network
# address of a MariaDB server.
#

[server1]
type=server
address=192.168.1.1
port=3306
protocol=MariaDBBackend

[server2]
type=server
address=192.168.1.2
port=3306
protocol=MariaDBBackend

# Monitor for the servers
#
# This will keep MaxScale aware of the state of the servers.
# MariaDB Monitor documentation:
# https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-mariadb-monitor/

[MariaDB-Monitor]
type=monitor
module=mariadbmon
servers=server1,server2
user=maxscale
passwd=17352CBFFB3D22C4625E030246888BA9
monitor_interval=2000
auto_failover=true
auto_rejoin=true

# Service definitions
#
# Service Definition for a read-only service and
# a read/write splitting service.
#

# ReadConnRoute documentation:
# https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-readconnroute/

[Read-Only-Service]
type=service
router=readconnroute
servers=server1,server2
user=maxscale
passwd=17352CBFFB3D22C4625E030246888BA9
router_options=master,slave

# ReadWriteSplit documentation:
# https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-readwritesplit/

[Read-Write-Service]
type=service
router=readwritesplit
servers=server1,server2
user=maxscale
passwd=17352DBFFB3D22C4625F030246888BA9

# Listener definitions for the services
#
# These listeners represent the ports the
# services will listen on.
#

[Read-Only-Listener]
type=listener
service=Read-Only-Service
protocol=MariaDBClient
port=4008

[Read-Write-Listener]
type=listener
service=Read-Write-Service
protocol=MariaDBClient
#address=192.168.1.100
socket=/tmp/ClusterMaster

Toelichting op de MaxScale-configuratie

• MaxScale] threads: MaxScale gebruikt alle CPU-cores van je VPS met de optie 'auto'. Dit heeft de voorkeur bij een dedicated SQL-server.
• [server1] & [server2]: Definieer alle servers die je gebruikt. Het type en het protocol verander je nooit. Het enige dat je hier aanpast is het IP en de poort naar die van je SQL-servers. Gebruik je meer dan twee servers, dan voeg je nog een sectie toe  [server3], [server4], etcetera, afhankelijk van hoeveel je er gebruikt.
• [MariaDB Monitor]:Er zijn hier een paar velden die aangepast moeten worden.
  • Achter 'servers' neem je de namen op van alle servers die je hebt ingesteld, bijvoorbeeld server1, server2.
  • Voeg achter 'user' de gebruiker toe die je voor MaxScale hebt aangemaakt (stap 3). Deze gebruiker wordt gebruikt door MariaDB Monitor voor het monitoren van de slave status.
  • Voor 'passwd' gebruik je het versleutelde wachtwoord dat je in stap 5 hebt aangemaakt.
  • De 'monitor interval' wordt weergegeven in miliseconden.
  • Auto_failover zorgt ervoor dat de slave tot master gepromote wordt als je master onbereikbaar wordt. Wil je liever controle in de hand houden en handmatig failovers uitvoeren nadat je eerst hebt gekeken wat er met je SQL-cluster aan de hand is, zet deze optie dan op false en gebruik het handmatige switchover commando dat onderaan dit artikel wordt besproken.
  • Auto_rejoin zorgt er na een failover voor dat de oude master automatisch als slave weer aan je cluster wordt toegevoegd wanneer hij weer bereikbaar is. Ongeacht of je handmatige of automatische failover gebruikt wil je doorgaans deze optie op true laten staan.
• [Read-Only-Service]: Zorgt voor automatische (lightweight) loadbalancing. Voeg hier de MaxScale user en het versleutelde wachtwoord toe die je eerder hebt aangemaakt. Router-options zet je op master,slave zodat de load zowel over masters als slaves wordt verdeeld.
• [Read-Write-Service]: Deze service splitst je read- & write-queries. Deze eigenschap gebruiken wij in deze tutorialseries om de write-queries aan een virtueel IP te koppelen (meer daarover in het volgende deel)
• [Read-Only-Listener]: De service die luistert naar acties op poort 4008 waar de Read-Only-Service acties op uit voert.
• [Read-Write-Listener]: Deze service luistert naar alle write-queries. Het address bepaald waar deze queries naartoe gaan. In principe gebruikt de read-write-listener automatisch de huidige master, maar om te zorgen dat je in de configuratie van je website of applicatie eenvoudiger je database kunt gebruiken, gaan wij in het volgende deel een virtueel IP-adres aan de read-write-listener verbinden.
  Commentaar de address regel voor nu uit zoals in het voorbeeld (in het volgende deel kies je eerst een IP-adres).
• De socket is de naam van de protocol module die de communicatie tussen de VPS en MaxScale verzorgt. Deze wordt uitgelezen uit het bestand /tmp/ClusterMaster

Sla de wijzigingen op en sluit /etc/maxscale.cnf af (ctrl + w > y > enter).

SSL valt buiten het kader van deze tutorial series. Wil je graag SSL gebruiken, dan kun je dit inschakelen in de configuratie van MaxScale (/etc/maxscale.cnf). Meer informatie hierover vind je op deze pagina onder 'Server and SSL'.

MariaDB Monitor

De gebruiker die je eerder voor de MariaDB Monitor hebt ingesteld, heeft MySQL super-, of replication client-privileges nodig. Zonder deze rechten werkt MariaDB Monitor niet en zal MaxScale (en dus ook MariaDB Monitor) niet starten.

Wij gaan dan ook deze privileges aan de MariaDB Monitor-gebruiker geven die je in het vorige deel 'MariaDB replicatie opzetten' hebt opgezet.

Stap 1

Start een MySQL-shell:

mysql -u root -p

Stap 2

Geef de gebruiker 'maxscale' alle privileges. MaxScale heeft deze nodig om o.a. de MariaDB Monitor te gebruiken. Gebruik voor je master de commando's:

GRANT ALL PRIVILEGES ON *.* TO 'maxscale'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;
exit

Gebruik op je slave de commando's:

GRANT ALL PRIVILEGES ON *.* TO 'maxscale'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION; 
FLUSH PRIVILEGES; 
exit

Vervang in beide gevallen 'maxscale' door de naam van het account die je onder stap 4 van 'MaxScale installeren en configureren' hebt ingesteld voor je MariaDB Monitor en 'password' door het bijbehorende (niet-versleutelde) wachtwoord.

Stap 3

Verwerk tot slot je wijzigingen door MaxScale te herstarten op je VPS'en:

systemctl restart maxscale

Tijdens het configureren van MaxScale heb je de verdere configuratie van MariaDB Monitor al verzorgt. Er is dus geen verdere actie voor de configuratie van MariaDB Monitor nodig.

Handmatige Switchover

Wil je handmatig een failover uitvoeren, of om een andere reden de master role van de ene server naar de andere server verplaatsen, dan gebruik je een switchover commando. De syntax voor dit commando is als volgt:

maxctrl call command mariadbmon switchover MariaDB-Monitor server1 server2

• call command: geeft aan dat er een module aangesproken wordt
• mariadbmon: de naam van de aangesproken module
• switchover: het commando dat je aanroept
• MariaDB-Monitor: de naam van je MariaDB-Monitor in /etc/maxscale.cnf (MariaDB-Monitor is de default waarde)
• server1: de naam van de server die je de nieuwe master wil maken
• server2: de naam van de huidige master

Het switchover commando is ook een prima manier om je databasecluster te testen. Probeer het dan ook vooral nu uit om de werking van je cluster te testen.

MaxScale problemen oplossen

Loop je tegen een probleem aan, dan logt MaxScale de oorzaak doorgaans heel duidelijk in de journalctl-log. Je vindt deze met het commando:

journalctl -xe -u maxscale

Controleer ook voor eventuele foutmeldingen in je system-logs:

nano /var/log/messages

Je hebt nu een mooi SQL-cluster, maar... hoe koppel je dit nu aan je diensten, zoals aan je website? Dit behandelen wij in het volgende deel van deze tutorial: je database cluster gebruiken.