Hulpartikel overzicht

Hulpartikel

Linux redundantie tutorial 6: aanvullende tips

Dit is het zesde en laatste 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 laatste deel sluiten wij af met enkele aanvullende onderwerpen en tips voor je SQL-cluster:


Aanvullende opties voor MariaDB Monitor

In deze tutorials hebben wij een specifieke configuratie opgesteld voor de MariaDB monitor, maar misschien heb je zelf nog meer functionaliteit nodig, of wil je een optie uitzetten. Hieronder noemen wij enkele nuttige MariaDB Monitor opties die niet standaard aan staan (het volledige overzicht vind je hier):

  • detect_replication_lag=true/false: Detecteert replicatielag tussen de master en slaves en laat nieuwe read-queries naar slaves gaan die up-to-date zijn. Standaard staat deze optie uit. De MariaDB Monitor gebruiker heeft hiervoor INSERT, UPDATE, DELETE en SELECT permissies nodig op de maxscale_schema.replication_heartbeat table en CREATE permissies op de maxscale_schema database
  • failcount: Het aantal fouten dat moet voorkomen op servers, voor een standalone server als master wordt gezien. Standaard gebeurt dit 5 keer, maar kun je aanpassen met deze optie.
  • failover_timeout: Het aantal seconden voor een timeout optreed bij een failover. Standaard is dit 90 seconden.
  • switchover_timeout: Het aantal seconden voor een timeout optreed bij een failover.
  • verify_master_failure=true/false: MariaDB voert hiermee een extra controle uit voor een automatische failover, door te testen of slaves nog events ontvangen van de master.
  • servers_no_promotion: Sluit servers uit van promotie tot master VPS. De syntax ziet er als volgt uit:
    servers_no_promotion=server1,server2
  • promotion_sql_file & demotion_sql_file: Twee zeer belangrijke files als je absolute controle wil over wat je servers precies doen bij een failover. Gebruik je een van deze, dan wordt de bijbehorende SQL-file regel voor regel uitgevoerd bij een promotie/demotie, of specifieker:
    promotion_sql_file=/home/root/scripts/promotion.sql zorgt ervoor dat bij een automatische failover de nieuwe master de SQL opdrachten uit dit bestand uitvoert, voor replicatie start van een eventuele externe master. Hiermee kun je bijvoorbeeld een change master to commando uitvoeren om een specifieke master te promoten.
    demotion_sql_file=/home/root/scripts/demotion.sql wordt door de oude master uitgevoerd wanneer de oude master terugkeert bij het cluster, vóór die als slave begint te replicaten, en voor de standalone server aan het cluster wordt toegevoegd. Helaas kun je hierdoor dus niet sommige queries, zoals een 'change master to' inzetten.
    Het is aan te raden om geen queries hiermee uit te voeren die data wijzigt in databases, om het risico op fouten te verkleinen.

Nuttige beheer-commando's & MaxAdmin

In de vorige delen heb je al met de nodige commando's kennis gemaakt. Er zijn echter nog meer nuttige commando's die het beheer van je database makkelijker maken. Hieronder zetten we er een aantal op een rijtje.

 

MariaDB Master-Slave

Voor het beheer van de master-slave-configuratie van je database is vooral een gedegen kennis van MySQL belangrijk. De eerste stap om je master-slave-configuratie te beheren is altijd om een SQL-shell te starten.

mysql -u root -p

Hieronder volgt een overzicht van handige commando's en een toelichting wat ze precies doen:

  • SHOW MASTER STATUS\G;
    Voer dit commando uit op de huidige master. Het laat binlog-informatie zien, zoals de binlog-bestandsnaam die de master gebruikt en de positie binnen dit bestand.
  • SHOW SLAVE STATUS\G;
    Toont een uitgebreid statusoverzicht van de slave. De Slave_IO_State zal bij een goed werkend cluster de status 'Waiting for master to send event' tonen.
  • SHOW DATABASES;
    Toont een overzicht van de databases die op je VPS gehost worden
  • SELECT user FROM mysql.user;
    Toont alle gebruikersaccounts binnen MariaDB. Dit zijn dus niet de gebruikeraccounts van je OS zelf, hoewel er wel dezelfde namens tussen kunnen staan.
  • STOP SLAVE;
    STOP MASTER;
    RESET SLAVE;
    RESET MASTER;
    START SLAVE;
    START MASTER;
    Stop: Stopt respectievelijk de slave/master.
    Reset: Een reset van de master maakt de binlog leeg en herstelt de slave/master naar een nul-waarde. Reset je bijvoorbeeld de master, dan zal de global transaction id weer bij 0-1-1 beginnen. De slave/master moet gestopt zijn voor je een reset uitvoert.
    Start: Start een eerder gestopte slave/master opnieuw op.
  • SHOW VARIABLES LIKE '%gtid%';
    
    Toont je alle variabelen gerelateerd aan de global transaction ID (GTID). Dit is een van de belangrijkste commando's voor het beheer van je master-slave-configuratie. Hier zijn vooral de volgende gegevens zeer belangrijk:
    - gtid_binlog_pos: de GTID van de laatste event group die in de binary log is geschreven.
    - gtid_binlog_state: de interne staat van de binlog. De master gebruikt deze om vast te stellen of een gegeven GTID al in de binlog is vastgelegd.
    De gtid_binlog_pos en gtid_binlog_state worden exclusief door de master gebruikt. De gegevens die je hier ziet zullen per VPS dus verschillen.
    - gtid_current_pos: de GTID die hoort bij de laatste wijziging van een database.
    - gtid_slave_pos: de GTID van de laatste wijziging die door de slave gerepliceerd is. Door de gtid_current_pos te vergelijken weet de slave of die alle wijzigingen op de database heeft doorgevoerd.

MaxScale

MaxScale heeft zijn eigen shell van waaruit je MaxScale beheert (waar ook de MariaDB Monitor onder valt). Deze open je met het commando:

maxadmin

De MaxScale commando's zijn vooral gericht op het controleren van de huidige status van je cluster. Voor daadwerkelijke probleemoplossing is het vooral raadzaam in de logs van je VPS te kijken.

  • list servers
    Laat een kort overzicht zien van alle servers in je master-slave-setup met de naam, IP, poort, actieve verbindingen en de master/slave status.
  • show servers
    Een meer gedetailleerd overzicht van de servers in je master-slave-setup. Doorgaans volstaat list servers voor het snel controleren van de status van je cluster.
  • list services
    Laat zien welke MaxScale-services er actief zijn op welke servers. Denk hierbij bijvoorbeeld aan de Read-Write-service.
  • list monitors
    Toont de status van de actieve monitors. Dit is er wanneer je deze tutorials doorloopt één.
  • exit
    Sluit de MaxAdmin-shell af.

Onderhoud plegen aan je cluster

MaxScale ondersteund de mogelijkheid om een server in maintenance mode te brengen zodat je een server/database tijdelijk uit het cluster kunt halen voor onderhoud. Je zet een server in maintenance mode met de commando's:

maxadmin
set server servername maintenance

Het maxadmin-commando opent de maxadmin-shell. Je herkent deze aan MaxScale>. Vervang in het tweede commando servername door de servernaam. Weet je niet zeker wat je servernaam is, controleer die dan eerst met het commando 'list servers'.

Er worden nu geen nieuwe write- of read-queries naar de server gestuurd. Pending queries worden nog wel uitgevoerd.

Ben je klaar met je onderhoud, dan haal je je server uit maintenance mode met de commando's:

maxadmin
clear server servername maintenance

 

 

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