Correction typos.

MySQL/HowtoTroubleshooting.md

@@ -43,7 +43,7 @@ $ mysql --default-character-set utf8 < my.dump
 
 **Forcer l'encodage directement dans le dump**
 
-On créera ainsi les bases et les tables ainsi ainsi :
+On créera les bases et les tables ainsi :
 
 ~~~
 mysql> CREATE DATABASE foo DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
@@ -56,7 +56,7 @@ On peut forcer l'UTF8 avec `:set fileencoding=utf8`. Cela peut être utile en ca
 
 Bien sûr, il faut en général se taper des remplacements à la main.
 
-Dans tous les cas, on vérifiera si les fichiers ont été modifiés en calculant la somme MD5 par exemple...
+Dans tous les cas, on vérifiera si les fichiers ont été modifiés en calculant la somme MD5 par exemple…
 
 Note : si votre dump fait plusieurs Go, vérifier que vous avez assez de mémoire pour l'ouvrir entièrement avec Vim ;-)
 
@@ -81,7 +81,7 @@ $ echo "LOAD DATA INFILE '$PWD/<table>.txt' INTO TABLE <table>"  CHARACTER SET l
 ## Purger une table InnoDB (fichier .ibd)
 
 En utilisant l'option `innodb_file_per_table` cela crée des fichiers .ibd par table. Lors d'une suppression de lignes, l'espace
-n'est pas libéré immédiatement, il faut ensuite faire un OPTIMIZE TABLE pour "purger" les fichiers .ibd
+n'est pas libéré immédiatement, il faut ensuite faire un OPTIMIZE TABLE pour « purger » les fichiers .ibd
 
 ## Reset mot de passe MySQL
 
@@ -97,8 +97,8 @@ Vous pourrez ainsi accéder à MySQL sans mot de passe, et aller changer le mot
 
 ## Indexes désactivés
 
-Si des requêtes "normales" semblent très lentes, vérifier que les indexes ne sont pas désactivés !
-En effet, on peut désactiver les indexes avec un requête : `ALTER TABLE ... DISABLE KEYS`
+Si des requêtes « normales » semblent très lentes, vérifier que les indexes ne sont pas désactivés !
+En effet, on peut désactiver les indexes avec une requête : `ALTER TABLE ... DISABLE KEYS`
 Pour le vérifier, on vérifiera via un `SHOW INDEXES FROM <table>`
 Pour le réactiver (cela peut être long) : `ALTER TABLE ... ENABLE KEYS`
 
@@ -224,7 +224,7 @@ Query OK, 0 rows affected (0.00 sec)
 Dans certain cas (création d'une vue par exemple), cela peut venir d'une version de MySQL trop ancienne
 (on a constaté des requêtes qui passaient en 5.1 mais pas en 5.0).
 
-## Nombre de colonnes incorrect pour mysql.proc
+## Nombre de colonnes incorrectes pour mysql.proc
 
 Si vous avez des erreurs de ce type :
 
@@ -238,7 +238,7 @@ Si vous avez des erreurs de ce type :
 Cela signifie que les tables de la base `mysql` ne correspondent pas à la version de MySQL en cours.
 Vous avez sûrement mis à jour MySQL ou réinjecter des données d'une autre base.
 
-Plusieurs solutions, réinjecter les tables incorrectes ou utilisez `mysql_upgrade` qui est sensé adapter les tables.
+Plusieurs solutions, réinjecter les tables incorrectes ou utilisez `mysql_upgrade` qui est censé adapter les tables.
 
 ## Désactiver la complétion
 
@@ -250,7 +250,7 @@ complétion peut créer de soucis si certaines tables sont corrompues :
 $ mysql --skip-auto-rehash
 ~~~
 
-## Erreur d'âge du "checkpoint"
+## Erreur d'âge du « checkpoint »
 
 ~~~
 mysqld: 120313 12:16:10  InnoDB: ERROR: the age of the last checkpoint is 9433587,
@@ -328,7 +328,7 @@ mysql> create table foo(foo int) ENGINE=InnoDB;
 # cp /var/lib/mysql/foo/foo.frm /var/lib/mysql/foo/TABLE.frm
 ~~~
 
-Quelques informations supplémentaire sur :
+Quelques informations supplémentaires sur :
 http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting-datadict.html
 
 ## Erreur 121
@@ -337,7 +337,7 @@ 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)`
 ~~~
 
-Il s'agit d'un problème avec les clés. Par exemple, les clés que vous crééez
+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
 supprimer une table InnoDB via son fichier .frm
 
@@ -371,7 +371,7 @@ innodb_force_recovery = 3
 innodb_purge_threads = 0
 ~~~
 
-Dès que le service démarre (il sera peut être en read-only), faites un dump de toutes vos bases MySQL.
+Dès que le service démarre (il sera peut-être en read-only), faites un dump de toutes vos bases MySQL.
 
 Vous devrez sûrement repartir de zéro en recréant un datadir tout neuf (`mysql_install_db --datadir=/var/lib/mysql.new`)
 et en réinjectant votre dump.
@@ -414,7 +414,7 @@ On le corrigera ainsi :
 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 :
+Si vous obtenez l'erreur ci-dessus, lors d'un mysqldump par exemple, et que les fichiers `${mysql_datadir}/base/table.{MYD,MYI}` sont vides mais pas le `.frm`, il faut réparer la table comme ceci :
 
 ~~~
 # mysqlcheck --auto-repair --check --use-frm <base> <table>
@@ -437,8 +437,8 @@ Pour résoudre la situation :
 Got error: 1290: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement when executing 'SELECT INTO OUTFILE'
 ~~~
 
-Lors du passage à la version 5.5.53, la valeur par défaut est passée de _vide_ à `/var/lib/mysql-files` ce qui casse les `mysqldump` qui écrivent leurs fichiers ailleurs (malgré des droits système adaptés).
+Lors du passage à la version 5.5.53, la valeur par défaut est passée de _vide_ à `/var/lib/mysql-files` ce qui casse les `mysqldump` qui écrivent leurs fichiers ailleurs (malgré des droits systèmes adaptés).
 
 Sur Debian, la nouvelle valeur par défaut est `/var/lib/mysql-files`. L'utilisation d'un lien symbolique de cet emplacement vers le dossier réel (par exemple `/home/mysqldump`) ne suffit pas et MySQL continue de refuser le dump.
 
-En attendant de passer à Stretch, nous recommandons de remettre la valeur par défaut précédente (_vide_) et redélarrer MySQL.
+En attendant de passer à Stretch, nous recommandons de remettre la valeur par défaut précédente (_vide_) et redémarrer MySQL.