231 lines
10 KiB
Markdown
231 lines
10 KiB
Markdown
---
|
||
title: Howto MySQL : réplication
|
||
...
|
||
|
||
Pour le guide d'installation et d'usage courant, consultez [/HowtoMySQL]().
|
||
|
||
## Préparation
|
||
|
||
**Prérequis** : disposer de deux serveurs MySQL avec un `datadir` identique
|
||
|
||
Dans le cas où le futur master est en production et ne peut être arrêté :
|
||
|
||
~~~
|
||
# mysqldump --master-data --all-databases > mysql.dump
|
||
~~~
|
||
|
||
`--master-data` ajoute un `CHANGE MASTER TO` dans le dump contenant les informations nécessaires au slave sur les logs (nom de fichier et position). Cette option implique `--lock-all-tables` qui bloquera toutes les tables pendant le dump.
|
||
|
||
Il faut également :
|
||
|
||
* autoriser les connexions MySQL distantes ;
|
||
* activer les logs binaires sur chaque serveur : `log_bin mixed` ;
|
||
* positionner un `server-id` différent sur chaque serveur (a priori, ne pas utiliser 0…) ;
|
||
* créer un utilisateur dédié pour la réplication sur chaque serveur avec le droit `REPLICATION SLAVE` : `grant replication slave on *.* to repl@'%' identified by 'XXX';`.
|
||
|
||
## Activation
|
||
|
||
Récupérer les informations sur `MASTER_LOG_FILE` et `MASTER_LOG_POS` dans le dump avec master-data. (Avec head par exemple).
|
||
|
||
Sur le serveur B (le _slave_ en mode master-slave), exécuter :
|
||
|
||
~~~
|
||
mysql> CHANGE MASTER TO
|
||
MASTER_HOST='$MASTER_IP',
|
||
MASTER_USER='repl',
|
||
MASTER_PASSWORD='XXX',
|
||
MASTER_LOG_FILE='mysql-bin.NNNNNN',
|
||
MASTER_LOG_POS=NNN;
|
||
~~~
|
||
|
||
/!\\ **Bien que non obligatoire, il est recommandé de toujours indiquer les directives `MASTER_LOG_FILE` et `MASTER_LOG_POS`**
|
||
|
||
Pour exclure une base de la réplication :
|
||
|
||
~~~{.ini}
|
||
[mysqld]
|
||
binlog-ignore-db = mysql
|
||
~~~
|
||
|
||
Puis démarrer la réplication sur le serveur B avec la commande : `START SLAVE`.
|
||
|
||
Enfin, exécuter `SHOW SLAVE STATUS` pour vérifier le bon fonctionnement.
|
||
|
||
## Désactivation
|
||
|
||
Pour supprimer toute trace de réplication (sauf si des infos sont en dur dans la configuration) :
|
||
|
||
~~~
|
||
mysql> RESET SLAVE;
|
||
Query OK, 0 rows affected (0.00 sec)
|
||
~~~
|
||
|
||
Pour éviter que la réplication démarre automatiquement au démarrage, on ajoutera dans la configuration :
|
||
|
||
~~~{.ini}
|
||
[mysqld]
|
||
skip-slave-start
|
||
~~~
|
||
|
||
## Trucs et astuces pour la réplication MySQL
|
||
|
||
**Astuce 1** : Une astuce parfois très utile est la possibilité d'exécuter des requêtes qui ne seront pas prises en compte
|
||
par le binlog (et donc non répliquée !). Cela nécessite le droit SUPER :
|
||
|
||
~~~
|
||
mysql> SET sql_log_bin = 0;
|
||
~~~
|
||
|
||
**Astuce 2** : Pour divers raisons (notamment la réplication de données déjà répliquées !), on devra activer l'option
|
||
suivante :
|
||
|
||
~~~{.ini}
|
||
[mysqld]
|
||
log-slave-updates
|
||
~~~
|
||
|
||
**Astuce 3** : Sauter une requête déjà présente dans les binlog sur le slave (à tester) :
|
||
https://stackoverflow.com/questions/17701524/mysql-replication-skip-statement-is-it-possible
|
||
|
||
## Etapes supplémentaires pour une réplication _master-master_
|
||
|
||
Positionner la directive `auto-increment-increment = 10` sur chaque serveur
|
||
|
||
Positionner la directive `auto-increment-offset` avec une valeur numérique différente sur chaque serveur
|
||
|
||
Exemple : `auto-increment-offset 2` sur le serveur B
|
||
|
||
Effectuer l'étape _Activation_ dans le sens A->B et B->A
|
||
|
||
## Résolution des erreurs lors de la réplication
|
||
|
||
On vérifie les erreurs avec les commandes `SHOW SLAVE STATUS` et `SHOW MASTER STATUS`.
|
||
|
||
En cas d'erreur, il faut « simplement » résoudre l'erreur, puis relancer la réplication
|
||
avec la commande `START SLAVE`. Voici quelques erreurs possibles
|
||
|
||
**Zapper l'erreur en cours**
|
||
|
||
~~~
|
||
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
|
||
~~~
|
||
|
||
**Fichier de clé incorrect**
|
||
|
||
~~~
|
||
Incorrect key file for table './base/table.MYI'; try to repair it
|
||
~~~
|
||
|
||
Il faut réparer la table concernée.
|
||
|
||
**Doublon sur clé unique**
|
||
|
||
~~~
|
||
Duplicate entry 'NNNNNN' for key N
|
||
~~~
|
||
|
||
Une solution *peut* être de supprimer la ligne concernée (ou de zapper l'erreur)
|
||
|
||
**Beaucoup de doublons à ignorer**
|
||
|
||
Si pour une raison ou un autre, on a plein de `DUPLICATE ENTRY` mais que l'est *sûr* de vouloir les ignorer, on peut faire cela en redémarrant MySQL avec le paramètre : `slave-skip-errors = 1062` ; on peut faire également cela avec d'autres types d'erreurs. Malheureusement, il faut forcément redémarrer MySQL car cette commande ne se fait pas à chaud : http://bugs.mysql.com/bug.php?id=35611
|
||
|
||
**Récupération deposition impossible**
|
||
|
||
~~~
|
||
[ERROR] Error reading packet from server: Client requested master to start replication from impossible position (server_errno=1236)
|
||
~~~
|
||
|
||
Cela signifie que la position indiquée sur le binlog du master est impossible à récupérer. On peut le vérifier avec une commande du type `mysqlbinlog mysqld-bin.00123 --start-position=251` sur le master.
|
||
|
||
Si l'on constate que le binlog est corrompu avec des erreurs du type `ERROR: Error in Log_event::read_log_event(): 'read error' # Warning: this binlog is either in use or was not closed properly.` ou `ERROR: Error in Log_event::read_log_event(): 'Event too small', data_len: 0, event_type: 0` l'idée sera d'identifier les requêtes non jouées sur le slave dans le binlog corrompu (le `Relay_Master_Log_File` via un `SHOW SLAVE STATUS`) et de les rejouer (cf [HowtoMySQL#Replay]()) puis de passer au binlog suivant via une commande du type `CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000124' , MASTER_LOG_POS=106; START SLAVE;` (la position à indiquer est souvent `106`, cf `mysqlbinlog mysql-bin.000124`).
|
||
|
||
Si l'on juge cela non nécessaire (données non critiques), on pourra bien sûr passer directement au binlog suivant en ignorant les requêtes du binlog corrompu. Bien sûr, suite à ces manipulations risquées, on vérifiera ensuite la cohérence de la base de données répliquée (`COUNT(*)` ou outils plus avancés).
|
||
|
||
**Could not parse relay log event entry**
|
||
|
||
~~~
|
||
Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
|
||
~~~
|
||
|
||
Souvent un binlog corrompu (le `Relay_Master_Log_File` via un `SHOW SLAVE STATUS`).
|
||
|
||
**Note**: Jusqu'à MySQL <= 5.1 au moins, changer la position dans un `Relay_log` avec un `CHANGE MASTER TO` ne marche pas. Voir [#ChangementdelapositiondansunRelay_log].
|
||
|
||
**Erreur fatale à la lecture du binlog**
|
||
|
||
Erreur : `Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master'`
|
||
|
||
On obtient apparemment cela dans différents cas.
|
||
|
||
* L'un d'eux serait si max_allowed_packet est inférieur à read_buffer_size ; voir <http://www.mysqlperformanceblog.com/2012/06/06/read_buffer_size-can-break-your-replication/> ;
|
||
* dans d'autre cas, il faudra forcer la réplication à se poursuivre via `STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.00XXXX' , MASTER_LOG_POS=XXXX; START SLAVE;`
|
||
* dans un autre cas, la position indiquée n'existe pas dans le binlog
|
||
* enfin voir <http://dev.mysql.com/doc/refman/5.1/en/replication-features-max-allowed-packet.html>
|
||
|
||
**Réinitialiser la réplication**
|
||
|
||
Dans certains cas **exceptionnels**, une solution radicale est de réinitialiser la réplication avec un `STOP SLAVE; RESET SLAVE; START SLAVE;` Attention, cela doit être fait dans de très rares cas maîtrisés (attention notamment aux conflits `DUPLICATE ENTRY` que cela risque de provoquer).
|
||
|
||
**Status OK, mais pas de réplication**
|
||
|
||
Si un `SHOW SLAVE STATUS` ne retourne pas d'erreur mais que la réplication ne se fait pas, les logs du slave peuvent contenir une erreur du type :
|
||
|
||
~~~
|
||
[Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.003357' at position 389449
|
||
[Note] Slave: received end packet from server, apparent master shutdown:
|
||
~~~
|
||
|
||
Il se peut que le master se réplique sur 2 slaves ayant un server-id identique !
|
||
|
||
### Changement de la position dans un `Relay_log`
|
||
|
||
À faire uniquement si en tentant de changer la position d'un `Relay_log` sur un slave, vous obtenez cette erreur :
|
||
|
||
~~~
|
||
Error initializing relay log position: Could not find target log during
|
||
relay log initialization
|
||
~~~
|
||
|
||
Il faut alors stopper le processus slave de réplication :
|
||
|
||
~~~
|
||
mysql> STOP SLAVE;
|
||
~~~
|
||
|
||
Puis éditer (en gardant une sauvegarde) le fichier `${datadir}/relay-log.info`. La première ligne correspond au `Relay_Log_File`, la seconde au `Relay_Log_Pos`.
|
||
Redémarrer MySQL.
|
||
|
||
## Contrôle de l'intégrité de la réplication
|
||
|
||
### pt-table-checksum
|
||
|
||
C'est un outil de [Percona](https://www.percona.com/downloads/percona-toolkit/) intégré dans son toolkit. (Package Debian [percona-toolkit](https://packages.debian.org/search?keywords=percona-toolkit) disponible à partir de Wheezy).
|
||
Manuel : https://www.percona.com/doc/percona-toolkit/2.1/pt-table-checksum.html
|
||
|
||
L'outil vérifie l'intégrité de la réplication en effectuant des requêtes de checksum (crc32 par défaut) sur le master, puis les requêtes sont joués sur les slaves permettant de trouver des différences.
|
||
|
||
La méthode la plus simple pour l'utiliser est d'autoriser le master à se connecter au slave (authentification MySQL). Ainsi, il s'occupe lui-même de faire le nécessaire pour identifier les erreurs. Il suffira donc de lancer la commande sans argument pour qu'il identifie les incohérences. On pourra réaliser un cron avec l'argument `-q` qui ne fait remonter que les erreurs.
|
||
|
||
~~~
|
||
MAILTO=jdoe@example.com
|
||
42 9 * * 7 pt-table-checksum -q
|
||
~~~
|
||
|
||
### pt-table-sync
|
||
|
||
Si *pt-table-checksum* vous a remonté des incohérences, vous pouvez avec cet outil les corriger. Cela va identifier les différences et les corriger avec un `REPLACE` sur le master (qui sera donc répliqué sur le slave), garantissant la cohérence des données.
|
||
|
||
Exemple :
|
||
|
||
~~~
|
||
# pt-table-sync --print --replicate percona.checksums localhost
|
||
# pt-table-sync --execute --replicate percona.checksums localhost
|
||
~~~
|
||
|
||
En cas de `Can't make changes on the master because no unique index exists`. On peut synchroniser directement les différences sur le slave depuis le master.
|
||
|
||
~~~
|
||
# pt-table-sync --execute --no-check-slave localhost slave
|
||
~~~
|