In dit laatste deel sluiten wij af met enkele aanvullende onderwerpen en tips voor je SQL-cluster:

• Aanvullende opties voor MariaDB Monitor
• Nuttige MaxScale beheer commando's
• MaxCtrl
• Onderhoud plegen aan 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

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.

MaxCtrl

MaxScale heeft zijn eigen tool waarmee je MaxScale beheert (waar ook de MariaDB Monitor onder valt). Deze gebruik je met het commando:

maxctrl

De MaxCtrl 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.

• maxctrl 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.

• maxctrl 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.

• maxctrl list services

  Laat zien welke MaxScale-services er actief zijn op welke servers. Denk hierbij bijvoorbeeld aan de Read-Write-service.

• maxctrl list monitors

  Toont de status van de actieve monitors. Dit is er wanneer je deze tutorials doorloopt één.

Onderhoud plegen aan je cluster

MaxScale ondersteunt 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:

maxctrl set server servername maintenance

Vervang in het tweede commando door de servernaam. Weet je niet zeker wat je servernaam is, controleer die dan eerst met het commando 'maxctrl 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:

maxctrl clear server servername maintenance

Daarmee zijn we aan het eind gekomen van onze tutorial series over het opzetten van een redundante Linux (web)server omgeving.

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' onderaan deze pagina.