master
Replication mysql – Configuration maitre-esclave
Configuration de la réplication avec mysql, dans un modèle maître esclave.
Voilà un petit post qui va expliquer en suivant en gros la documentation de mysql (http://dev.mysql.com/doc/refman/5.0/fr/replication-howto.html), comment mettre en place la réplication, de manière pragmatique et fonctionnelle.
Comme toujours, avant toute opération, assurez vous d’avoir une copie de sauvegarde de l’ensemble des éléments modifiés avant d’appliquer quoi que ça soit, afin de pouvoir revenir en arrière en cas de soucis (fichiers de configuration, données etc.).
J’ai pour cette opération un serveur sous Fedora 8 (qui date mais qui fait le job) équipé de mysql-server 5.0.45 en production et standalone (qui travaille tout seul comme un grand) jusqu’ici; et, un serveur sous Fedora 13 (utilisé pour du stockage uniquement jusqu’ici) équipé de mysql-server 5.1.56 fraichement installé avec un petit :
[bash]yum install mysql-server
chkconfig –level 345 mysqld on[/bash]
L’idée étant de mettre en place la réplication du premier qui deviendra « master » (maître), sur le second, qui deviendra « slave » (esclave). A mon sens l’utilité de la réplication avec MySQL est principalement valable pour 2 points :
– Avoir une copie des données, lisible en production
– Répartir la charge sur plusieurs serveurs (un serveur exclusivement pour les requêtes en écriture – le maitre, un autre dédié aux requêtes en lecture – le ou les esclave(s)).
Attention cependant, la réplication MySQL ne dispense pas de mettre en place une stratégie de sauvegarde ! Car, par exemple, un effacement accidentel de données sur le maître entraîne la modification quasi immédiate sur les machines répliquées ! Dans une telle situation, seule une sauvegarde « traditionnelle » (façon mysql dump) vous permettra de récupérer vos données.
Un article évoquant plusieurs configurations et usages de la réplication MySQL est disponible sur cette page http://bertrand.letous.fr/replication-mysql/ qui évoque notamment la réplication RING (multi-master replication) permettant la réplication combinée à l’écriture sur les esclaves propageant la modification en chaine et ainsi permettant d’ajouter autant de serveurs que nécessaire pour absorber une montée en charge. Une documentation détaillée est disponible ici : http://onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
Revenons donc à nos moutons, avec pour objectif, basculer l’installation actuelle d’un simple serveur MySQL tout seul, en maître avec l’ajout d’un esclave répliqué.
=> Serveur maitre :
Sur le serveur maître, nous allons créer un compte utilisateur dédié à la réplication. Soit en passant par une interface d’administration style Webmin, soit en passant par la ligne de commande mysql (requête).
Je vais donc créer un utilisateur « replication » sur mon master, avec un mot de passe, et autoriser pour le host « ip_du_slave » (sur vpn pour mon cas) avec pour permission « Slave replication ».
Ce qui donne donc en commande SQL sur le maître :
[bash]mysql> GRANT REPLICATION SLAVE ON *.* TO replication@’ip_du_slave’ IDENTIFIED BY ‘<mot de passe>’;[/bash]
Si vous n’avez jamais utilisé la réplication, il y a des chances que votre serveur mysql n’ait pas de log binaire activé !
Afin de s’assurer de ceci, vous devez éditer votre fichier my.cnf (généralement dans /etc/my.cnf) et vous assurer qu’il contient dans la section « mysqld » les lignes suivantes :
[bash]log-bin
server-id=1[/bash]
La valeur de serveur-id doit être un entier positif entre 1 et 2^32 − 1, mais doit être unique pour chaque serveur (maitre ou esclave).
Si les valeurs ne sont pas présentes, ajoutez les, puis relancez votre serveur mysql.
On va vérifier que la modification est bien active en se connectant en local en root au serveur mysql :
[bash]mysql -u root -p[/bash]
Puis on contrôle qu’il y ait bien un log binaire (après avoir saisi votre mot de passe root mysql) :
[bash]show master status;
+———————+————+———————+————————–+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+———————+————+———————+————————–+
| mysql-bin.000001 | 729 | | |
+———————+————+———————+————————–+
1 row in set (0.00 sec)
[/bash]
Nous avons maintenant un serveur MySQL avec un utilisateur qui détient les privilèges de réplication, et, un fichier de log binaire qui va contenir la chaine des transactions/modifications réalisées sur les bases.
Afin de lancer la réplication, nous allons devoir (1) verrouiller la base (READ LOCK), (2) noter le « status » du fichier binaire afin d’indiquer à l’esclave d’où il repart quand on le lancera (comme vu à l’instant), (3) arrêter mysql sans déverrouiller et faire un backup afin de pouvoir transférer les données en l’état sur l’esclave, (4) et relancer mysql et déverrouiller (unlock tables), DANS CET ORDRE PRÉCIS.
L’impact pour votre système actuel va être un blocage des écritures pendant que vous notez le « status » des transactions et réalisez le backup.
En avant donc :
(1)
On se connecte au serveur (maitre) en local et on bloque les transactions :
[bash]mysql -u root -p[/bash]
[bash]mysql> FLUSH TABLES WITH READ LOCK;[/bash]
ok, les transactions sont maintenant bloquées.
(2)
On affiche le « status » et on le copie pour pouvoir le lire plus tard (faites la copie de VOS infos afin d’en disposer plus loin) :
[bash]show master status;
+———————+————+———————+————————–+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+———————+————+———————+————————–+
| mysql-bin.000001 | 729 | | |
+———————+————+———————+————————–+
1 row in set (0.00 sec)
[/bash]
(3)
On arrête mysql bloqué et on sauvegarde les fichiers de données (dans /var/lib/mysql chez moi):
[bash]mysqladmin -uroot -p shutdown
cd /var/lib
tar -cvzf mysql_full.tgz mysql[/bash]
Le backup est fait avec les données non modifiées depuis que l’on a noté le master « status ».
(4)
On va maintenant relancer mysql et débloquer les transactions :
[bash]/etc/rc.d/init.d/mysqld start
mysql -u root -p[/bash]
Puis on débloque :
[bash]mysql> UNLOCK TABLES;[/bash]
Nous avons maintenant nos bases dans un fichier de sauvegarde et l’état des transactions à ce moment là. C’est fini pour le serveur maître MySQL qui est opérationnel comme avant.
Vous devriez voir des informations relatives à l’activation de log-bin dans les logs de mysqld (ici /var/log/mysqld.log).
Note : Il faut autoriser l’accès au port 3306 depuis l’esclave dans votre firewall si vous en avez un actif sur le maître, sinon l’esclave ne pourra pas communiquer avec le maître et la réplication ne pourra s’effectuer.
################################################################
=> Serveur Esclave :
On arrête le serveur mysql (vierge jusqu’ici car tout fraîchement installé).
[bash]/etc/rc.d/init.d/mysqld stop[/bash]
Il faut configurer le serveur mysql en éditant le fichier /etc/my.cnf comme pour le maître en ajoutant le server-id dans la configuration (c’est le numéro unique du serveur, qui doit être différent du serveur maître) et les informations permettant la synchronisation :
[bash][mysqld]
server-id=2
master-host = ip_du_master
master-user = utilisateur_replication
master-password = mot_de_passe_replication
master-port = 3306
[/bash]
On va ensuite replacer les données sur l’esclave (attention aux droits sur les fichiers, généralement tout appartient à l’utilisateur « mysql »), ceci en copiant l’archive mysql_full.tgz créée sur le serveur maître, dans le serveur esclave.
Je me positionne dans /var/lib (qui contient le dossier mysql également), qui appartient à l’utilisateur mysql et je décompresse l’archive :
[bash]tar xvzf mysql_full.tgz[/bash]
Ceci va sauvagement écraser les fichiers en place au profit de la copie conforme du maître.
On peut maintenant relancer le serveur mysql :
[bash]/etc/rc.d/init.d/mysqld start[/bash]
Puis on active la synchronisation (qui va également rattraper les modifications depuis la reprise de l’activité du maître) :
Connection en root à mysql en local sur l’esclave :
[bash]mysql -u root -p[/bash]
On arrête le (service) slave :
[bash]mysql> STOP SLAVE;[/bash]
On applique les modifications :
[bash]mysql> CHANGE MASTER TO
-> MASTER_HOST='<master host name ou ip>’,
-> MASTER_USER='<replication user name>’,
-> MASTER_PASSWORD='<replication password>’,
-> MASTER_LOG_FILE='<recorded log file name>’,
-> MASTER_LOG_POS=<recorded log offset>;[/bash]
Note : ce sont les informations définies plus haut, saisie entre apostrophes, sauf pour la dernière valeur numérique saisie directement (et sans les < >).
On lance enfin le processus esclave qui démarre effectivement la synchronisation :
[bash]mysql> START SLAVE;[/bash]
Dans les log de /var/log/mysqld.log vous devriez voir quelque-chose du genre :
« Slave SQL thread initialized, starting replication in log ‘mysql-bin.000001’ at position xxx… etc. »
« Slave I/O thread: connected to master ‘replication@ip_du_maitre:3306’,replication started in log ‘mysql-bin.xxx…etc. »
Maintenant consultez les données dans les tables du serveur esclave, toutes les modifications apportées au maître doivent être automatiquement appliquées à l’esclave.
Vous pouvez aussi consulter l’état sur l’esclave par exemple en vous connectant au serveur :
[bash]mysql -u root -p[/bash]
Puis en tapant la commande suivante :
[bash]mysql> SHOW SLAVE STATUS\G;[/bash]
et celle ci pour voir l’etat des processus :
[bash]mysql> SHOW PROCESSLIST;[/bash]
Maintenant, si vous arrêtez le serveur mysql esclave, et que vous le relancez, il reprendra la synchronisation là où il s’est arrêté ! :D cool.
################################################################
=> En cas de plantage (perte des données sur une des machines) :
– Si le maitre plante :
On verrouille l’esclave (FLUSH TABLES WITH READ LOCK;), on « dump » (copie) les données de l’esclave sur le maître, et on relance la synchronisation après avoir relancé le maître.
-Si l’esclave plante :
On recommence la mise en place à partir des étapes 1,2,3,4 dans la section « maître » de ce post, sur le maître, comme ci on réalisait à nouveau cette mise en place.
=> Vous pouvez ajouter autant d’esclaves que vous le voulez, pour répliquer autant de fois que nécessaire l’infrastructure (et donc augmenter la puissance de l’ensemble en répartissant la charge sur plusieurs serveurs).
Autres ressources pertinentes :
http://www.system-linux.eu/index.php?post/2009/09/10/R%C3%A9plication-Mysql
http://km.azerttyu.net/Replication-Mysql-ou-comment.html
http://www.howtoforge.com/mysql_database_replication
Links
Calendrier
L | M | M | J | V | S | D |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
Recherche
Derniers articles
Tresronours Twitter
Keywords cloud topic
Membre de la FSF
Liens qui vont bien
Mots clés vrac – keyword cloud
License du contenu – CC By NC SA
Archives
- Resumed posting and expanding on X
- Linkedin Access to your account has been restricted – Final debrief and resilience plan
- I’m thankful for the support I get in rough time
- Cyber security news of the day – 2024 May 31
- Alexandre Blanc Cyber Kicked out from Linkedin
- You’ll most likely find me on LinkedIn
- The Russian roulette landing page !
- RTSP, Debian, VLC, not playing, IP Camera
- 5G network hosted in the cloud, no internet, no phone ! So smart ! And I ended on TV, This week in cyber
- They lock the door for privacy… but they keep a copy of the key, and couple of backdoors
- Worst is yet to come, but they all warned you
- Migrating an old WordPress and handling character set, UTF8, latin1, latin1_swedish_ci
- From a broken TLS CA, to Facebook, to FIN12 hit and run
- Yes we can fix this mess, but do we want to ? That’s another story
- Criminals are still dominating the game, why are we doing so wrong, and what can we learn in this tech ocean ?
- Riding cloud can be tricky, don’t fall from it, in the weekly cyber !
- The threat landscape is very dynamic – Cyber news this week
- Cybersecurity is not obvious even for this newsletter !
- Install Slack desktop app on Kali rolling fixing libappindicator3-1 missing dependency
- How to delete all resources in azure to avoid charges after trial on your forced credit card registration
- Proxmox – ZFS – Dead drive on active VM, recover from replicated disk
- Restrict access to proxmox web admin interface
- Migrate your ESXI VMs to proxmox ZFS
- Install your VPN server with pi-hole on OVH VPS in 30 min
- Using raspberry pi 3 as wifi bridge and repeater and firewall
- Raspberry 3 – create a wifi repeater with USB wifi dongle
- raspberry 3 – routeur pare feu point d’acces wifi avec filtrage pub et tracking – router firewall access point with ads and tracking filtering
- Dell XPS 13 touchpad – corriger la sensibilité
- Utiliser Zazeen set top box depuis une connexion videotron
- Fermeture de mon compte facebook – la dernière goutte
- Choisir un kernel par defaut au demarrage de Centos 7.2 – configuration grub2
- Openvpn access server 2.0.25 et android
- Régler la luminosité du laptop par ligne de commande
- chromium outlook web app version complete sous linux
- Nexus 7 2012 – android 5 lollipop solution au probleme de lenteur
- HDD led sur Xubuntu – xfce
- xubuntu 14.04 verrouiller ecran de veille et desactiver mise en veille a la fermeture de l’ecran
- Authentification avec Radmin en utilisant Wine sur Gentoo
- Patcher bash sur une distribution plus supportee comme fedora 11
- Zimbra desktop sous xubuntu 14.04 64bit – fix
- xubuntu 12.10 probleme de son avec VLC – pulse audio – alsa – toshiba L855D – solution
- Evolution sous xubuntu 12.10 – bug affichage a la configuration – solution temporaire
- Booster son acces internet en changeant de DNS pour opendns
- Serveur DLNA sous ubuntu – minidlna
- sshfs sous windows – dokan sshfs
- xubuntu 11.10 Installer le plugin java pour firefox
- Installer Google Earth sur Xubuntu 11.10
- Installer nagios sur Fedora 11 depuis les sources
- Configurer varnish-cache avec des virtualhosts, apache, fedora, redhat, centos
- Installer Varnish depuis les sources sur Fedora 11