Réplication Mysql ou comment sauvegarder ses bases de données
Cet article a juste pour objectif de donner une procédure pour sauvegarder l’intégralité d’un serveur MySQL et maintenir automatiquement les mises à jours.
Je n’invente rien tout se trouve sur le net principalement sur le site MySQL
Pré requis
Avant de poursuivre la lecture de cet article, nous devons avoir :
- 2 serveurs MySQL
- Un compte root MySQL pour chacun
- Des comptes *nix avec accès ssh et les bons droits
- l’ip ou nom d’hôte du maitre MySQL
Pour les dénominations, je parlerais de Maitre pour le serveur à sauvegarder, d’Esclave pour le serveur de sauvegarde.
Préparer le Maitre
Il faut :
- créer un compte de réplication, qui sera autorisé à se connecter pour obtenir les mises à jours
- configurer le serveur
- faire une sauvegarde complète des données à un instant T connu.
- sauvegarder le fichier de configuration
debian.cnf
Créer le compte de réplication
Au choix, nous avons phpmyadmin avec son interface accessible et la console MySQL.
Concernant phpmyadmin, l’interface est suffisamment claire. Depuis la page d’accueil on accéde à la gestion des comptes via le lien Privilèges.
Concernant la ligne de commande, il faut accéder à la console MySQL via : maitre:~#mysql -u root -p
Les points à prendre en compte sont :
-
%
pour le host -
%
pour les bases de données -
REPLICATION SLAVE
pour les privilèges
Avec les paramètres précédents, on souhaite que le compte de réplication puisse accèder au mettre à l’ensemble des bases de données et ce depuis n’importe où sur le net.
Si on maîtrise bien MySQL, on peut définir les bases sauvegardables et les IP possibles du serveur esclave (dans ce cas on sort du cadre de cet article et il faut lire la vraie documentation).
Au choix de l’interface MySQL, nous saisissons :
CREATE USER 'esclave'@ '%' IDENTIFIED BY '***';
GRANT REPLICATION SLAVE ON * . * TO 'esclave'@ '%' IDENTIFIED BY '***' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
GRANT ALL PRIVILEGES ON <span class="base64" title="PGNvZGUgY2xhc3M9J3NwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lJyBkaXI9J2x0cic+ZXNjbGF2ZV8lPC9jb2RlPg=="></span> . * TO 'esclave'@ '%';
Configurer
Si la configuration initialee ne l’a pas fait, dans le fichier maitre:~# /etc/mysql/my.cnf
, nous devons saisir :
[mysqld]
log-bin
server-id=master_id
master_id
est un entier compris entre 1 et 2^32 − 1.
Si ces données sont ajoutées, il faut alors relancer le serveur MySQL avec maitre:~# /etc/init.d/mysql stop ; /etc/init.d/mysql start
Exporter les données
SQL
La réplication ne peut se faire qu’en partant d’un référentiel temps commun et une copie des données exactes à cet instant. Pour réaliser ceci, il existe plusieurs solutions, je vous invite à la lire la documentation officielle pour les voir.
Mon choix s’est porté sur une solution la plus agnostique vis à vis des choix de configuration (Myisam, innodb, base mysql, ...) mais qui en contre partie est la plus lente.
maitre:~#mysqldump -u root -p --all-databases --master-data > dump.sql
L’attribut --all-databases
indique une copie complète du serveur.
L’attribut --master-data
exporte aussi le référentiel temps au moment de la copie, de plus il verrouille les bases le temps de la sauvegarde.
debian.cnf
Comme on effectue une copie exhaustive de la base, nous perdons les données présente dans la table mysql
. Cette base contient entre autres les paramètres des comptes. Pour éviter que l’esclave se mélange les pinceaux, il faut copier le fichier /etc/mysql/debian.cnf
Configurer l’esclave
Nous devrons :
- importer les données du maitre
- mettre à jour
debian.cnf
- indiquer l’adresse du maitre
- lancer la synchronisation
Importer
L’importation se fait en ligne de commande grâce à esclave:~# mysql -u root -p < dump.sql
Debian.cnf
Comme nous venons d’écraser l’intégralité des bases de données, nous devons aussi remplacer les paramètres de connexion mysql.
Nous écrasons simplement le fichierdebian.cnf
par celui du maitre.
Pour charger les modifications, nous relançons le serveur
esclave:~#
/etc/init.d/mysql stop ; /etc/init.d/mysql start
Configurer
Nous avons 2 choses à faire :
- donner un
identifiant serveur
différent du master dans/etc/mysql/my.cnf
- indiquer la localisation du maitre.
esclave:~# /etc/mysql/my.cnf
[mysqld]
server-id=slave_id
slave_id
est un entier compris entre 1 et 2^32 − 1 et différent de master_id
.
Depuis une commande mysql (esclave:~# mysql -u root -p
), nous indiquons les paramètres de connexion.
CHANGE MASTER TO
MASTER_HOST='nom d'hôte du maitre ou IP',
MASTER_USER='compte esclave',
MASTER_PASSWORD='mot de passe'
Les paramètres de synchronisation MASTER_LOG_FILE
et MASTER_LOG_POS
ont déjà été sauvegardé lors de l’importation. (se reporter à la documentation)
Synchroniser
Maintenant nous avons un maitre qui est prêt à transmettre ses mises à jours depuis la création du fichier dump.sql
et un esclave à l’identique du maitre à cet instant configuré pour chercher les dernières modifications.
La synchronisation se fait à l’aide START SLAVE;
. Nous controlons le bon comportement via le fichier de log système.(esclave:~# tail -f -n 50 /var/log/syslog
)
Jul 29 17:14:50 esclave mysqld[3600]: 090729 17:14:50 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000792' at position 401029, relay log './mysqld-relay-bin.000001' position: 4
Jul 29 17:14:50 esclave mysqld[3600]: 090729 17:14:50 [Note] Slave I/O thread: connected to master 'esclave@hote.master.com:3306', replication started in log 'mysql-bin.000792' at position 401029
Si vous n’avez pas un log similaire, vous êtes bon pour lire la vraie documentation.
Messages
1. Réplication Mysql ou comment sauvegarder ses bases de données, 25 février 2010, 16:11, par .Gilles
A mon avis ce n’est pas vraiment une technique de sauvegarde fiable : certes ça protège du plantage matériel d’un serveur, mais pas d’un delete malheureux..
Enfin, c’est ce qui est dit sur la doc de MySql (http://dev.mysql.com/doc/refman/5.0...)