Principe
Le Maître
- Le serveur maître reçoit des requêtes et les exécute.
- Il écrit chaque requête dans un fichier tampon (un journal).
L'esclave
- L'esclave se connecte au serveur,
- Lit ce fichier journal,
- Et exécute aussi les requêtes du journal.
1. Configuration du maître (10.0.0.1)
Créer un réplica entre les deux serveurs web. J'explique ?
…
Naan, tout est dans le titre … yek yek yek. Il y a assez de doc sur le net !
…
Bon, bon, d'accord (grognon) voici la suite.
1.1 Configurer mariaDB ...
Attention, le serveur web muni de l'application applitest doit être fonctionnel.
On va commencer par créer un utilisateur utilisé par l'esclave et qui aura les droits de réplication sur les bases (ici, la base 'atelier') avec l'interface SQL en ligne de commande.
On voit ici que l'utilisateur n'est accessible que depuis le serveur esclave. Dans la réalité, il faudra créer un utilisateur par serveur esclave car on indique l'IP de connexion.
/!\ Ne pas utiliser esclave@* sinon tout serveur connaissant l'@ du master pourra récupérer les données …
[shell]
# entrer dans mariadb et donner le mdp éventuel (sinon rien)
mysql \-u root \-p
[sql]
-- vérifier l'existence de la base atelier en affichant la liste des bases présentes :
show databases ;
-- créer l'utilisateur qui se connecte à partir du serveur esclave !!
CREATE USER "esclave"@"10.0.0.2" IDENTIFIED BY "je suis 1 Esclave." ;
-- donner les droits de réplication sur toutes les bases à cet utilisateur (on peut limiter les bases à celle répliquée)
GRANT REPLICATION SLAVE ON *.* TO "esclave"@"10.0.0.2" ;
-- recharger les droits
FLUSH PRIVILEGES ;
-- afficher le statut du maître
SHOW MASTER STATUS ;
L'adresse de l'utilisateur esclave est celle du serveur esclave. Il faut adapter cette adresse en fonction de votre situation !
Le serveur répond vide à la requête show master status parce qu'on n'a pas fini sa config.
Il faut lui donner le rôle de maître dans le fichier de config .. Donc, on va dans le fichier de config.
1.2 Modifier le fichier de configuration
Il nous faut maintenant ouvrir le serveur maître vers le réseau si ce n'est pas déjà fait …
- Faire une sauvegarde du fichier de configuration de mariadb puis ouvrir l'original avec nano :
[shell]
cp /etc/mysql/mariadb.conf.d/50-server.cnf /etc/mysql/mariadb.conf.d/50-server.cnf.bak
nano /etc/mysql/mariadb.conf.d/50-server.cnf
- Dans le fichier, chercher la ligne : bind-address (dont l'adresse devrait être à 127.0.0.1 pour n'écouter que le réseau local).
- Changer l'adresse et mettre l'adresse : 0.0.0.0
- remarque : c'est pas très sécu, ce problème d'ouverture à tous vents … on devrait mettre : 10.0.0.2 (l'IP de l'esclave) mais ça ne fonctionne pas correctement (cf § Questions)
- Donner un numéro au serveur : par exemple 1
- Activer les logs pour voir ce qui se passe et …
- Indiquer le nom de la base à répliquer.
Ça donne quelque chose comme ça (en orange et gras, ce que j'ai changé, les … représentent des lignes masquées) :
nano /etc/mysql/mariadb.conf.d/50-server.cnf
[shell]
# contenu du fichier ...
...
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 0.0.0.0 # ligne modifiée
...
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.***
server-id = 1 # ligne décommentée
log\_bin = /var/log/mysql/mysql-bin.log # ligne décommentée
expire\_logs\_days = 10
max\_binlog\_size = 100M
binlog\_do\_db = atelier # include_database_name # ligne modifiée
Avant de redémarrer le service, on va vérifier la présence des 2 fichiers de log.
[shell]
# Vérifier les fichiers log
ls \-l /var/log/mysql/
On doit trouver error.log et mysql-bin.log
Attention à ne pas détruire de fichier mysql.socket, votre serveur mariadb serait à réinstaller ...
Si mariaDB ne les a pas créés, il faut le faire :
Créer les fichiers log et changer le propriétaire des objets :
[shell]
touch /var/log/mysql/error.log
touch /var/log/mysql/mysql-bin.log
chown mysql \-Rf /var/log/mysql
Redémarrer mariadb avec : service mariadb restart ou systemctl restart mariadb.service
Ça devrait être bon.
1.3 Un petit contrôle de fonctionnement ?
Entrer dans mysql (mysql -u root -p …) et lancer l'affichage du statut du maître :
On devrait avoir un tableau avec un nom et un numéro de position. Par exemple :
+------------------+----------+--------------+-...
| File | Position | Binlog_Do_DB | ...
+------------------+----------+--------------+-...
| mysql-bin.000001 | 107 | atelier | ...
+------------------+----------+--------------+-...
1 row in set (0.00 sec)
On retrouve ici
- le nom du fichier d'échange des ordres SQL : mysql-bin.000001 (le noter dans un coin),
- le numéro d'index de traitement (ici, 107) trrrrès imporrrtant! Da ! On en aura besoin plus tard,
- le nom de la base répliquée (c'est bien de le voir)
On devrait maintenant bloquer les écritures sur la base avec la commande SQL :
[sql]
flush TABLES with read lock ;
Mais on s'en passera, vous ferez attention de ne rien modifier dans les bases de données.
2. Configurat° de l'esclave (10.0.0.2)
Normalement, il faudrait faire un dump (une sauvegarde) du master à réinstaller sur l'esclave. Pour nos tests, vous allez tout simplement reprendre l'installation d'applitest à zéro afin que le maître et l'esclave soient au diapason.
2.1 Fichier de configuration
On va dire à l'esclave qu'il est tombé en servitude et lui désigner qui est son maître (moi, bien sûr, hm!).
Un petit tour dans le fichier de config de l'esclave pour modifier les lignes comme suit :
[shell]
nano /etc/mysql/mariadb.conf.d/50-server.cnf
Contenu du fichier ... :
[shell]
# ...
server-id = 2 # ligne modifiée
# ...
log\_bin = /var/log/mysql/mysql-bin.log # ligne décommentée
expire\_logs\_days = 10
max\_binlog\_size = 100M
binlog\_do\_db = include_database_name # ligne modifiée
On a ajouté : l'adresse IP et le port écouté du master, l'utilisateur et son mot de passe.
redémarrer mariadb pour prendre en compte les modifs du fichier de config.
2.2 Configurer mariadb
Redémarrer mariaDB puis aller dans mysql -u root -p. pour lui imposer le rôle d'esclave et lui donner le nom du fichier et la position du numéro d'index (trrrrès imporrrtant) vu plus haut dans le master … da!
[shell]
# entrer dans mariadb et donner le mdp éventuel (sinon rien)
mysql \-u root \-p
[sql]
-- Arrêter la réplication
STOP SLAVE ;
-- indiquer le nom du fichier à chercher sur le maître et la position de l'index :
CHANGE MASTER TO MASTER_HOST = 10.0.0.1,
MASTER_USER = 'esclave',
MASTER_PASSWORD = 'je suis 1 Esclave.',
MASTER_PORT = 3306,
MASTER_CONNECT_RETRY = 10,
MASTER_USE_GTID = current_pos ;
CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000001',
MASTER_LOG_POS = 107 ;
-- mettre l'esclave au travail
START SLAVE ;
Notes :
- Le master = adresse IP du serveur master !
- J'ai mis 2 requêtes Change Master To afin
- de pouvoir réutiliser la seconde plusieurs fois avec la touche flèche haut (rappel de commande)
- sans changer les premières données.
Le nom du fichier et la position changent plus souvent que le reste.
2.3 Un petit contrôle de fonctionnement ?
Dans mysql, lancer la commande d'affichage du statut du serveur esclave.
[sql]
-- afficher le statut de l'esclave (vue globale)
SHOW SLAVE STATUS \G;
On devrait obtenir une liste de données dont : l'adresse IP, l'utilisateur, le port, le nom du fichier à lire, la position de l'index, etc. …
Les informations
- Slave_IO_Running et Slave_SQL_Running doivent être à Yes,
- Slave_IO_State en attente d'un ordre du master.
Exemple d'utilisation :
En TP on effectue aussi des tests d'intégration et pas seulement des tests unitaires :
- test unitaire = vérification les services sont actifs sans erreur,
- text d'intégration : vérification que ça marche en vrai, fonctionnellement.