MySQL master-master replicatie
MySQL cluster
Hee welkom! Leuk dat je leest, in dit blog gaan we de beschikbaarheid van ons MySQL 5.7 verhogen d.m.v. een master-master replicatie. Veel organisaties hebben maar 1 MySQL server waar zij dagelijks op werken. Vaak wanneer een bedrijf groeit komt de vraag: “Hoe kunnen we de beschikbaarheid van MySQL server vergroten?”. In dit blog bericht gaan we een MySQL master-master replicatie maken die bestaat uit twee servers. Beiden servers treden in een master/slave rol waarmee ze elkaar repliceren.
In dit artikel een uitleg over hoe je de master-master replicatie kunt configureren. Wanneer je de replicatie werkend hebt geeft dat nog niet een automatische fail-over voor gebruikers. Op de achtergrond repliceren de machines met elkaar maar wanneer server 1 uitvalt is het niet zo dat verbindingen automatisch naar server-2 toe gaan. Wanneer je dit wel wilt, kijk dan eens naar Consul.
MySQL master-master
Een MySQL master-master replicatie is enkel om hogere beschikbaarheid te realiseren. Wanneer je op zoek bent naar meer performance en hogere beschikbaarheid kun je beter een Galera cluster opzetten. Bij Galera bestaat een minimale deployment uit 3 machines en bij een master-master omgeving uit minimaal twee machines.
Hoe werkt het
Een master-master en master-slave replicatie werkt met een binary log. MySQL heeft deze functie al enige tijd in hun software zitten. Die binary log houdt alle wijzigingen bij. Dus stel dat er een gebruiker op server 1 een update query doet dan publiceert server 1 deze update query op zijn binary log. Server 2 verwerkt vervolgens die binary log en past die wijzigingen door op zijn eigen dataset.
Stel je voor dat gebruiker A verbonden is met MySQL-1 en gebruiker B is verboden met MySQL-2. Stel dat alle twee de gebruikers tegelijkertijd een INSERT query doen. Dat geeft een probleem want de MySQL server die de INSERT verwerkt geeft onmiddellijk een COMMIT terug zonder dat hij weet dat de andere server de INSERT query verwerkt heeft. Het gevolg hiervan wordt nog erger, want bij een replicatie error stopt de replicatie tussen de servers. Daarna zijn er data veranderingen op MySQL-1 en data veranderingen op MySQL-2, en jij als systeembeheerder mag gaan kijken hoe je alle dubbele ‘primary key’ fouten eruit haalt wanneer je een poging doet om van alle data weer 1 te maken.
Het is dus belangrijk dat je een fail-over constructie realiseert waarbij gebruikers altijd naar slechts een van de twee servers schrijft.
Configureren
De onderstaande commando’s moeten steeds op beiden servers uitgevoerd worden. (tenzij anders aangegeven)
- Installeer MySQL 5.7 repository
rpm -ivh https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
- Installeer MySQL community server
yum install mysql-server
- Wijzig /etc/my.cnf en voeg server-id=1 en log-bin=mysql-bin toe voor server 2 krijg je dus server-id=2
- Stop de Firewall en schakel deze uit met systemctl (systemctl mask firewalld zorgt dat de firewall niet meer opstart)
systemctl stop firewalld
systemctl mask firewalld
- Start MySQL nu op
systemctl start mysqld
- Zoek het tijdelijke wachtwoord op
grep “temporary password” /var/log/mysqld.log
- Log nu in met MySQL en wijzig het root wachtwoord
mysql -u root -p
ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘JOUWWACHTWOORD’;
- Maak een replicatie gebruiker aan en geef deze rechten
create user ‘replication’@’%’ identified by ‘JOUWWACHTWOORD’;
grant replication slave on *.* to ‘replication’@’%’ identified by ‘JOUWWACHTWOORD’;
flush privileges;
- Op je andere server2 start MySQL op met systemctl start mysql en log in op MySQL, zoek nu de binary log en position onthoud deze en gebruik die voor hieronder
show master status \G;
change master to master_host = ‘IPADRESANDERESERVER’, master_user = ‘replication’, master_password = ‘JOUWWACHTWOORD’, master_log_file = ‘mysql-bin.000002’, master_log_pos = xxx;
- Na bovenstaande commando uitgevoerd te hebben start de slave rol en check de status
start slave;
slave status \G;
Als je replicatie werkt zie je geen fouten in je overzicht staan. Is dat wel zo dan is er iets fout gegaan, als je een fout in je “change master” commando hebt gemaakt stop dan eerst de slave rol met stop slave; daarna kun je de change master weer aanpassen. Check je status op beide servers.
