Winkelwagen

/ VPS-Infrastructuur

Alles over de zelfontwikkelde VPS-infrastructuur

Register now

/ Up to date

/ Nieuws

Lancering PerformanceVPS

Meer info
Hulp nodig?

    Sorry, we konden geen resultaten vinden voor jouw zoekopdracht.

    Linux redundantie tutorial 4: MaxScale & MariaDB-Monitor

    Dit is het vierde 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 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.
    • Voer alle stappen in dit artikel uit met een gebruiker met root-rechten, tenzij anders aangegeven.
       
    • Voer onderstaande stappen uit op alle SQL-servers in je cluster. Waar waardes per VPS verschillen, wordt dit aangegeven.
       
    • Gebruik je drie of meer databaseservers voor één enkele applicatie, dan zijn er op moment van schrijven kosten aan MaxScale verbonden (niet aan MariaDB zelf). Twee applicaties met ieder twee eigen database servers is dus geen enkel probleem, ongeacht hoe groot die database servers individueel zijn. Gebruik je meer dan twee database servers voor één database, dan raden wij aan contact op te nemen met MariaDB over licensering van MaxScale.

    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.

    • In de hier besproken opties kies je voor automatische of handmatige failover, zie de toelichting!
       
    • Vanaf MaxScale 2.5 wordt MaxAdmin niet langer gebruikt maar gebruikt men maxctrl. De [MaxAdmin-Service] en [MaxAdmin-Listener] hebben we daarom uit deze instructie verwijdert.
    # 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 + > > 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.

     

    Kom je er niet uit?

    Ontvang persoonlijke hulp van onze supporters

    Neem contact op