18
0
Fork 0

Création d'un dossier "MySQL" + titres des paragraphes

This commit is contained in:
Jérémy Lecour 2016-11-02 14:07:57 +01:00 committed by Jérémy Lecour
parent 1d191f0ef3
commit 530dac9dd1
4 changed files with 104 additions and 36 deletions

View File

@ -78,7 +78,7 @@ bind-address = 0.0.0.0
Selon les ressources de la machine, il faut optimiser les directives dans `my.cnf` (par défaut, la configuration est adaptée… pour un petit serveur !).
Sous Debian, on trouvera quelques exemples dans le répertoire `/usr/share/doc/mysql-server-5.0/examples/`
Popur plus d'information sur l'optimisation, consultez le guide [HowtoMySQLOptimize]().
Pour plus d'information sur l'optimisation, consultez le guide [MySQL/HowtoOptimize]().
## Utilisation courante
@ -843,12 +843,12 @@ Pour l'arrêter/redémarrer, même principe (attention, `mysqld_multi` est peu v
## Optimisation
Voir [HowtoMySQLOptimize]()
Voir [MySQL/HowtoOptimize]().
## Réplication
Voir [HowtoMySQLReplication]()
Voir [MySQL/HowtoReplication]().
## FAQ et erreurs courantes
Voir [HowtoMySQLTroubleshooting]()
Voir [MySQL/HowtoTroubleshooting]().

View File

@ -101,24 +101,72 @@ 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
* Si l'on veut zapper l'erreur en cours : `SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;`
**Zapper l'erreur en cours**
* `Incorrect key file for table './base/table.MYI'; try to repair it` : il faut réparer la table concernée
~~~
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
~~~
* `Duplicate entry 'NNNNNN' for key N` : une solution *peut* être de supprimer la ligne concernée (ou de zapper l'erreur)
**Fichier de clé incorrect**
* 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
~~~
Incorrect key file for table './base/table.MYI'; try to repair it
~~~
* En cas d'erreur du type `[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 [wiki:HowtoMySQL#Replay procédure décrite]) 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).
Il faut réparer la table concernée
* En cas d'erreur du type `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), ~~appliquer la même solution que ci-dessus !! ~~ Jusqu'à MySQL <= 5.1 au moins, changer la position dans un Relay_log avec un `CHANGE MASTER TO` ne marche pas. Voir [#ChangementdelapositiondansunRelay_log].
**Doublon sur clé unique**
* 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>
~~~
Duplicate entry 'NNNNNN' for key N
~~~
* 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).
Une solution *peut* être de supprimer la ligne concernée (ou de zapper l'erreur)
* 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 :
**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

View File

@ -5,21 +5,21 @@ title: Howto MySQL : questions fréquentes et erreurs courantes.
Pour le guide d'installation et d'usage courant, consultez [HowtoMySQL]().
## Problèmes d'encodage de caractères (alias "y'a un problème de charset")
## Problème de charset
Lors de migration de bases, ou tout simplement restauration de dump, un des problèmes les plus courants est d'avoir des problèmes d'encodage de caractères.
L'encodage de caractères est complexe sous MySQL car il peut être géré à plusieurs niveaux (serveur, base, table, etc.).
Voici donc quelques astuces qui peuvent servir (ou pas) :
* Mettre son client MySQL avec le bon encodage (dans votre `.my.cnf`) :
**Mettre son client MySQL avec le bon encodage (dans votre `.my.cnf`)**
~~~{.ini}
[client]
default-character-set=utf8
~~~
* Vérifier le type d'encodage du dump :
**Vérifier le type d'encodage du dump**
~~~
$ file my.dymp
@ -28,7 +28,7 @@ my.dump: UTF-8 Unicode text, with very long lines
Attention, l'outil *file* n'est pas fiable à 100%… notamment en cas de présence de caractères de plusieurs encodages différents.
* Modifier l'encodage d'un dump avec ICONV. Cela sera souvent dans ce sens là :
**Modifier l'encodage d'un dump avec ICONV. Cela sera souvent dans ce sens là**
~~~
$ iconv -f iso -t utf8 my.dump > my.dump.utf8
@ -36,13 +36,13 @@ $ iconv -f iso -t utf8 my.dump > my.dump.utf8
Dans certains cas très tordus, *iconv -f utf8 -t utf8* peut avoir une utilité.
* Forcer l'encodage lors de la réinjection :
**Forcer l'encodage lors de la réinjection**
~~~
$ mysql --default-character-set utf8 < my.dump
~~~
* Forcer l'encodage directement dans le dump.
**Forcer l'encodage directement dans le dump**
On créera ainsi les bases et les tables ainsi ainsi :
@ -51,7 +51,7 @@ mysql> CREATE DATABASE foo DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql> CREATE TABLE bar (coin int) DEFAULT CHARSET=utf8;
~~~
* Modifier l'encodage du dump avec VIM.
**Modifier l'encodage du dump avec VIM**
On peut forcer l'UTF8 avec `:set fileencoding=utf8`. Cela peut être utile en cas de présence de caractères de plusieurs encodages différents.
@ -61,7 +61,7 @@ Dans tous les cas, on vérifiera si les fichiers ont été modifiés en calculan
Note : si votre dump fait plusieurs Go, vérifier que vous avez assez de mémoire pour l'ouvrir entièrement avec Vim ;-)
* Si les données sont injectées avec `LOAD DATA INFILE` :
**Si les données sont injectées avec `LOAD DATA INFILE`**
Il faut préciser `CHARACTER SET latin1` ou `CHARACTER SET utf8` notamment si des tables ont des encodages différents !
@ -237,7 +237,7 @@ Vous avez sûrement mis à jour MySQL ou réinjecter des données d'une autre ba
Plusieurs solutions, réinjecter les tables incorrectes ou utilisez `mysql_upgrade` qui est sensé adapter les tables.
## Désactiver la complétion avec l'option `--skip-auto-rehash`
## Désactiver la complétion
En cas de souci lors de la connexion en ligne de commande MySQL,
vous pouvez désactiver la complétion automatique. En effet, cette
@ -259,12 +259,14 @@ mysqld: InnoDB: combined size of log files at least 10 times bigger than the
mysqld: InnoDB: largest such row.
~~~
Il faut augmenter le log InnoDB, notamment _innodb_log_file_size''. Attention, il faudra ensuite stopper MySQL et effacer les fichiers ''ib_logfile*_ !
Pour plus de détails, voir :
http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/
et http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html
Il faut augmenter le log InnoDB, notamment `innodb_log_file_size`.
## `InnoDB: Error: trying to load index PRIMARY for table […] but the index tree has been freed!`
**Attention**, il faudra ensuite stopper MySQL et effacer les fichiers `ib_logfile*` !
Pour plus de détails, voir :
<http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/>
et <http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html>
## Erreur d'index au chargement de la table InnoDB
Si vous obtenez une erreur du type :
@ -308,11 +310,11 @@ Se connecter en ligne de commande avec l'option `mysql --skip-auto-rehash` puis
supprimer la table concernée (voir ci-dessous si besoin) et réinjecter là.
Diverses astuces sont listées ici :
http://dba.stackexchange.com/questions/23296/mysql-innodb-index-in-swap
<http://dba.stackexchange.com/questions/23296/mysql-innodb-index-in-swap>
## InnoDB: Souci lors de la création/suppression de table InnoDB
## Souci lors de la création/suppression de table InnoDB
On suppose que vous utilisez bien l'option `innodb_file_per_table` comme conseillé sur cette page.
On suppose que vous utilisez bien l'option `innodb_file_per_table` comme conseillé.
Pour supprimer une table problématique, vous pouvez éteindre MySQL
et supprimer le fichier `.frm` correspondant ! Néanmoins la table sera
@ -328,7 +330,11 @@ mysql> create table foo(foo int) ENGINE=InnoDB;
Quelques informations supplémentaire sur :
http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting-datadict.html
## `Error 121 : InnoDB : ERROR 1005 (HY000): Can't create table './foo/bar.frm' (errno: 121)`
## Erreur 121
~~~
Error 121 : InnoDB : ERROR 1005 (HY000): Can't create table './foo/bar.frm' (errno: 121)`
~~~
Il s'agit d'un problème avec les clés. Par exemple, les clés que vous crééez
sont déjà référencée par InnoDB. Cela peut ainsi se produire si vous avez du
@ -338,7 +344,11 @@ Une astuce possible est simplement de créer la table sans ses clés.
Une fois créée, vous devez voir les clés avec un `SHOW CREATE TABLE`.
À vous de voir si vous devez les modifier/supprimer.
## `InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA`
## Erreur de démarrage InnoDB
~~~
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
~~~
Si le service MySQL/InnoDB refuse de démarrer à cause d'une erreur du type :
@ -367,7 +377,11 @@ et en réinjectant votre dump.
Voir http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
## `Error 13 : mysqld: #007/usr/sbin/mysqld: File '/var/log/mysql/mysql-bin.00NNNN' not found (Errcode: 13)`
## Erreur 13
~~~
Error 13 : mysqld: #007/usr/sbin/mysqld: File '/var/log/mysql/mysql-bin.00NNNN' not found (Errcode: 13)
~~~
Si vous obtenez des erreurs de ce type :
@ -393,7 +407,11 @@ On le corrigera ainsi :
# chown mysql:adm /var/log/mysql/mysql-bin.00NNNN
~~~
## `ERROR 130 (HY000): Incorrect file format '[…]'`
## Erreur 130
~~~
ERROR 130 (HY000): Incorrect file format '[…]'
~~~
Si vous obtenez l'erreur ci-dessus, lors d'un mysqldump par exemple, et que les fichier `${mysql_datadir}/base/table.{MYD,MYI}` sont vides mais pas le `.frm`, il faut réparer la table comme ceci :
@ -401,7 +419,9 @@ Si vous obtenez l'erreur ci-dessus, lors d'un mysqldump par exemple, et que les
# mysqlcheck --auto-repair --check --use-frm <base> <table>
~~~
## `is blocked because of many connection errors.`
## Trop de connexions
Erreur : `is blocked because of many connection errors.`
Blocage pour l'IP car nombreuses erreurs sur BD. Lié à la valeur de la variable `max_connect_errors`.
Pour résoudre la situation :