Améliorations
This commit is contained in:
Gregory Colpart
parent
f747d41735
commit
9ea4a92609
|
|
@ -15,7 +15,9 @@ Il faut :
|
|||
# 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.
|
||||
`--master-data` ajoute un `CHANGE MASTER TO` dans le dump contenant les informations nécessaires à la réplication (nom de fichier et position).
|
||||
|
||||
/!\\ **Cette option implique `--lock-all-tables` qui bloque toutes les tables pendant le dump !**
|
||||
|
||||
Il faut également :
|
||||
|
||||
|
|
@ -27,7 +29,7 @@ Il faut également :
|
|||
|
||||
## Activation d'une réplication MASTER/SLAVE
|
||||
|
||||
Il faut récupérer les informations _MASTER_LOG_FILE_ et _MASTER_LOG_POS_ :
|
||||
Il faut récupérer les informations *MASTER_LOG_FILE* et *MASTER_LOG_POS* :
|
||||
- soit sur l'un des deux serveurs inactifs avec `SHOW MASTER STATUS` (dans le cas de deux serveurs avec _datadir_ identique),
|
||||
- soit récupérer l'information dans le `mysqldump --master-data` (avec la commande `head` par exemple).
|
||||
|
||||
|
|
@ -42,7 +44,7 @@ mysql> CHANGE MASTER TO
|
|||
MASTER_LOG_POS=NNN;
|
||||
~~~
|
||||
|
||||
/!\\ **Bien que non obligatoire, il est recommandé de toujours indiquer les directives `MASTER_LOG_FILE` et `MASTER_LOG_POS` pour éviter des problèmes**
|
||||
/!\\ **Bien que non obligatoire, on recommande de toujours indiquer les directives *MASTER_LOG_FILE* et *MASTER_LOG_POS* pour éviter des problèmes**
|
||||
|
||||
Pour exclure une base de la réplication :
|
||||
|
||||
|
|
@ -135,13 +137,13 @@ Une solution *peut* être de supprimer la ligne concernée (ou de zapper l'erreu
|
|||
|
||||
**Beaucoup d'erreurs à 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>
|
||||
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>
|
||||
|
||||
On peut également avoir d'autres erreurs, par exemple `Could not execute Delete_rows event on table foo.bar; Can't find record in 'bar', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log [...]` et on mettre cette fois `slave-skip-errors = 1032`
|
||||
On peut également avoir d'autres erreurs, par exemple _Could not execute Delete_rows event on table foo.bar; Can't find record in 'bar', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log [...]_ et on mettre cette fois `slave-skip-errors = 1032`
|
||||
|
||||
Si plusieurs types d'erreur à ignorer : `slave-skip-errors = 1032,1062`
|
||||
|
||||
L'inconvénient est qu'il faut redémarrer MySQL. Pour éviter cela on peut automatiser le zap de l'erreur (exemple avec 1062) en cours :
|
||||
L'inconvénient est qu'il faut redémarrer MySQL. Pour éviter cela on peut automatiser le zap de l'erreur (exemple avec l'erreur _1062_) en cours :
|
||||
|
||||
~~~
|
||||
# while true; do while mysql -e "show slave status" | grep '1062.Error.*REPORT'; \
|
||||
|
|
@ -212,17 +214,19 @@ done
|
|||
|
||||
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 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 est d'identifier les requêtes non jouées sur le slave dans le binlog corrompu (voir le *Relay_Master_Log_File* via `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.
|
||||
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`).
|
||||
Souvent un binlog corrompu, voir le *Relay_Master_Log_File* `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].
|
||||
|
||||
|
|
@ -239,7 +243,7 @@ On obtient apparemment cela dans différents cas.
|
|||
|
||||
**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).
|
||||
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**
|
||||
|
||||
|
|
@ -252,9 +256,9 @@ Si un `SHOW SLAVE STATUS` ne retourne pas d'erreur mais que la réplication ne s
|
|||
|
||||
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`
|
||||
### 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 :
|
||||
À 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
|
||||
|
|
@ -274,8 +278,9 @@ Redémarrer MySQL.
|
|||
|
||||
#### pt-table-checksum
|
||||
|
||||
<https://www.percona.com/doc/percona-toolkit/2.1/pt-table-checksum.html>
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue