evolix/wiki
22
0
Fork 0
Code Releases Activity

mise en forme

Browse source
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
Show stats Download patch file Download diff file Expand all files Collapse all files

18
HowtoMySQL/Replication.md
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 : 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 : On peut faire manuellement :
@ -283,7 +283,7 @@ On peut faire manuellement :
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; 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 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. Il faut réparer la table concernée.
**Doublon sur clé unique** ### Doublon sur clé unique
~~~ ~~~
Duplicate entry 'NNNNNN' for key N 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). 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` 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 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) [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). 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), 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. 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'` 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 ! 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 : Si lors de l'injection du dump sur le slave cette erreur apparaît :