18
0
Fork 0

mise en forme

This commit is contained in:
Jérémy Lecour 2020-05-14 15:35:16 +02:00 committed by Jérémy Lecour
parent b5bac40e11
commit ac8aa9b052
1 changed files with 9 additions and 9 deletions

View File

@ -275,7 +275,7 @@ On vérifie les erreurs avec les commandes `SHOW SLAVE STATUS` et `SHOW MASTER S
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**
### Zapper l'erreur en cours
On peut faire manuellement :
@ -283,7 +283,7 @@ On peut faire manuellement :
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
~~~
**Fichier de clé incorrect**
### Fichier de clé incorrect
~~~
Incorrect key file for table './base/table.MYI'; try to repair it
@ -291,7 +291,7 @@ Incorrect key file for table './base/table.MYI'; try to repair it
Il faut réparer la table concernée.
**Doublon sur clé unique**
### Doublon sur clé unique
~~~
Duplicate entry 'NNNNNN' for key N
@ -299,9 +299,9 @@ Duplicate entry 'NNNNNN' for key N
Une solution *peut* être de supprimer la ligne concernée (ou de zapper l'erreur).
**Beaucoup d'erreurs à ignorer**
### 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`
@ -370,7 +370,7 @@ while true; do
done
~~~
**Récupération de position impossible**
### Récupération de position impossible
~~~
[ERROR] Error reading packet from server: Client requested master to start replication from impossible position (server_errno=1236)
@ -382,7 +382,7 @@ Si l'on constate que le binlog est corrompu avec des erreurs du type _ERROR: Err
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
~~~
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),
@ -471,7 +471,7 @@ MariaDB [(none)]> START SLAVE;
Normalement a ce stade là, la réplication continue à la position indiquée. Il se peut qu'il y ait des `Duplicate Entry`, qu'il faut alors étudier de près pour envisager de les sauter.
**Erreur fatale à la lecture du binlog**
### 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'`
@ -497,7 +497,7 @@ 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 !
**ERROR 1201 lors de l'injection du dump**
### ERROR 1201 lors de l'injection du dump
Si lors de l'injection du dump sur le slave cette erreur apparaît :