18
0
Fork 0

correction titres

This commit is contained in:
Gregory Colpart 2017-01-07 16:41:16 +01:00
parent d98473a49d
commit f747d41735
1 changed files with 10 additions and 10 deletions

View File

@ -4,7 +4,7 @@ title: Howto réplication MySQL
Pour le guide d'installation et d'usage courant, voir [HowtoMySQL](/HowtoMySQL).
# Préparation d'une réplication MASTER/SLAVE
## Préparation d'une réplication MASTER/SLAVE
Il faut :
@ -25,7 +25,7 @@ Il faut également :
* créer un utilisateur dédié pour la réplication : `GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY 'PASSWORD';`.
# Activation d'une réplication MASTER/SLAVE
## Activation d'une réplication MASTER/SLAVE
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),
@ -55,7 +55,7 @@ Puis démarrer la réplication sur le serveur B avec la commande : `START SLAVE`
Enfin, exécuter `SHOW SLAVE STATUS` pour vérifier le bon fonctionnement.
# Désactivation
## Désactivation
Pour supprimer toute trace de réplication (sauf si des infos sont en dur dans la configuration) :
@ -71,7 +71,7 @@ Pour éviter que la réplication démarre automatiquement au démarrage, on ajou
skip-slave-start
~~~
# Trucs et astuces pour la réplication MySQL
## Trucs et astuces pour la réplication MySQL
**Astuce 1** : Une astuce parfois très utile est la possibilité d'exécuter des requêtes qui ne seront pas prises en compte
par le binlog (et donc non répliquée !). Cela nécessite le droit SUPER :
@ -91,7 +91,7 @@ log-slave-updates
**Astuce 3** : Sauter une requête déjà présente dans les binlog sur le slave (à tester) :
<https://stackoverflow.com/questions/17701524/mysql-replication-skip-statement-is-it-possible>
# Réplication MASTER/MASTER
## Réplication MASTER/MASTER
Pour une réplication MASTER/MASTER, il faut simplement activer deux réplications MASTER/SLAVE entre les deux serveurs concernés.
@ -103,7 +103,7 @@ On conseille également de :
Exemple : `auto-increment-offset 2` sur l'un des deux serveurs
# Résolution des erreurs lors de la réplication
## Résolution des erreurs lors de la réplication
On vérifie les erreurs avec les commandes `SHOW SLAVE STATUS` et `SHOW MASTER STATUS`.
@ -252,7 +252,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 !
## 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 :
@ -270,9 +270,9 @@ mysql> STOP SLAVE;
Puis éditer (en gardant une sauvegarde) le fichier `${datadir}/relay-log.info`. La première ligne correspond au `Relay_Log_File`, la seconde au `Relay_Log_Pos`.
Redémarrer MySQL.
# Contrôle de l'intégrité de la réplication
## Contrôle de l'intégrité de la réplication
## pt-table-checksum
#### pt-table-checksum
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
@ -286,7 +286,7 @@ MAILTO=jdoe@example.com
42 9 * * 7 pt-table-checksum -q
~~~
## pt-table-sync
### pt-table-sync
Si *pt-table-checksum* vous a remonté des incohérences, vous pouvez avec cet outil les corriger. Cela va identifier les différences et les corriger avec un `REPLACE` sur le master (qui sera donc répliqué sur le slave), garantissant la cohérence des données.