Zoals al besproken in de server beschikbaarheid en schaalbaarheid is een server replica één van de oplossingen om een hoge beschikbaarheid en schaalbaarheid te bieden. In dit hoofdstuk is er kort stilgestaan welke voor- en nadelen hier aan vast zitten. In dit hoofdstuk gaan we verder in op de MySQL server replica.
De replica functionaliteit maakt gebruik van binary logging. De MySQL server werkt als Master. Deze schrijft informatie naar de binary logs als gebeurtenissen. De slaves worden vervolgens zo ingesteld dat deze de informatie weer uitlezen uit de logs. Dit kan uitgebreid geconfigureerd worden zodat je zelfs een slave kan beperken tot een enkele tabel of database.
De enige taak van de master is het aanmaken van de binary logs. De slaves kunnen alleen geconfigureerd worden wat te doen met de logs. Maar op de master kan dus niet worden aangegeven welke gebeurtenissen wel of niet weggeschreven dienen te worden naar de log.
Bij het uitlezen door de slave wordt een volledige binary log gepakt. De slave gaat vervolgens zijn positie onthouden waar hij in de log bezig zit met bijwerken. Zo is het mogelijk om de slave te stoppen, herstarten enz. De slave zal vervolgens verder gaan op de plaats waar hij gebleven is.
Zowel de slaves als de master moeten een unieke server-id hebben. Dit kan door middel van de optie server-id. Dit kan in een optie bestand gezet worden. De slaves worden vervolgens verder geconfigureerd met de hostnaam, de bestandsnaam van de log en de positie in dit bestand. Je vraagt je waarschijnlijk af hoe de laatste twee bekend moeten zijn. Dit kan door deze informatie op te vragen van de master. We zullen hier later op terug komen tijdens het opzetten van de replica.
Er dienen een aantal stappen te worden gevolgd om tot een replica omgeving te komen. Deze stappen worden verder hieronder behandeld.
De eerste stap is gelijk een optionele. Dit is namelijk het aanmaken van een speciale gebruiker waarmee ingelogd kan worden bij de master. Deze stap is optioneel maar wordt wel aangeraden in verband met beveiliging. De informatie van deze gebruiker wordt namelijk plain text opgeslagen in de master.info bestand. Het wordt dus aangeraden om dit account opnieuw aan te maken en deze flink te beperken in zijn handelen. Je kan de gebruiker als volgt klaarmaken voor gebruik:
GRANT REPLICATION SLAVE ON *.*
-> TO 'repl'@'%.sitemasters' IDENTIFIED BY 'slavepass’
De slaves moeten namelijk met een gebruikersnaam en wachtwoord inloggen op de master. Deze gebruiker kan je al aangemaakt hebben of je kan gebruiken maken van een bestaande gebruiker.
De tweede stap is de master zo configureren dat deze werkt als master. Zoals we eerder hebben aangegeven moet ook de master een server-id krijgen. Ook dient de binary log aangezet te worden. Let op dat de optie skip-networking niet aan staat. Wanneer dit wel aan staat kan je slave geen connectie maken met de master. Zet de bovenstaande twee optie in de [mysqld] optiegroep. De server dient te worden herstart na de actie.
De derde stap is de slave zo configureren dat deze de master kan aanspreken. Ook hier beginnen we met het aanmaken van de server-id. Geef deze een uniek getal mee. Aangeraden wordt om de server-id’s zo aan te geven dat deze uniek en makkelijk te herkennen zijn. Je kan bijvoorbeeld denken aan het laatste cijfer van het IP-adres. Maar dit is volledig vrij. Zolang ze maar uniek zijn voor zowel master als slaves. Zoals we eerder hebben gezegd dienen we de nog een aantal extra opties aan de slave mee te geven. Onder andere welke log file gebruikt wordt door de master en op welke positie deze zich bevindt in de file. Wanneer je reeds data op je master hebt staan dat ook weggeschreven dient te worden dien je eerst te zorgen dat deze data gerepliceerd wordt. Dit doe je door eerst de master te zeggen dat deze geen handelingen meer uitvoert. Vervolgens vraag je de file en positie op en dump je vervolgens de data. Daarna kan je de master vertellen om zijn handelingen te hervatten. Wanneer je deze handelingen niet uitvoert krijg je gegarandeerd corrupte databases op je slaves.
Om informatie over de file en positie op te vragen dien je eerst de master te zeggen dat deze een read lock op de tabellen zet. Dit kan door het commando
Flush tables with read lock
Wanneer je dit commando hebt uitgevoerd kan je vervolgens met Show master status de desbetreffende informatie op te vragen. Je krijgt vervolgens een overzicht met de file en de positie.
Deze informatie kan je gebruiken om de slave te voorzien van informatie. Deze informatie kan je door middel van een query aan de slave geven. Voer de volgende query uit met de desbetreffende informatie.
CHANGE MASTER TO
MASTER_HOST=’hier je master hostnaam’,
MASTER_USER=’hier je username’,
MASTER_PASSWORD=’hier je wachtwoord’,
MASTER_LOG_FILE=’de filename van de log file’,
MASTER_LOG_POS=hier de positie
Je hebt nu je replica omgeving afgerond.
Afhankelijk van de huidig situatie zijn er een aantal opties om de server replica te maken. Je kan helemaal vanaf punt 0 opstarten zoals hierboven maar je kan ook een server replica maken als de servers al data bevatten. Dit kan je doen door tussentijds een dump te maken.
Om de voortgang van de replica te monitoren kan je gebruik maken van het commando show slave status. Je krijgt dan een overzicht die lijkt op onderstaand.
Slave_IO_State: Waiting for master to send event
Master_Host: master1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 931
Relay_Log_File: slave1-relay-bin.000056
Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 931
Relay_Log_Space: 1365
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Mas
Verder kan je op de master kijken of er een slave bezig is door de processen te dumpen op het scherm. Dit kan door middel van de commando show processlist. Zoek vervolgens naar Binlog Dump. Je krijgt bijvoorbeeld een overzicht als hieronder.
mysql> SHOW PROCESSLIST;
*************************** 4. row ***************************
Id: 10
User: root
Host: slave1:58371
db: NULL
Command: Binlog Dump
Time: 777
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
Wanneer je gebruik maakt van de report-host optie kan je ook een overzicht van alle slaves produceren door middel van het commando: show slave hosts. Je krijgt een overzicht die lijkt op de volgende:
mysql> SHOW SLAVE HOSTS;
+-----------+--------+------+-------------------+-----------+
| Server_id | Host | Port | Rpl_recovery_rank | Master_id |
+-----------+--------+------+-------------------+-----------+
| 10 | slave1 | 3306 | 0 | 1 |
+-----------+--------+------+-------------------+-----------+
Je hebt verder de mogelijkheid om de slave te starten en te stoppen. Dit kan door middel van de start slave en stop slave opties. Je kan beide opties onderverdelen in een IO_THREAD en een SQL_THREAD. De io-thread houdt het lezen van de master in en de sql-thread houdt het schrijven op de slave in.
Deze cursus is afkomstig van Cursus MySQL
Het is verboden zonder schriftelijke toestemming deze pagina in welke vorm dan ook te publiceren.