4.10 Réplication de MySQL
4 Administration du serveur
Manuel de Référence MySQL 4.1 : Version Française
. Introduction à la réplication
. Présentation de l'implémentation de la réplication
. Comment mettre en place la réplication
. Fonctionnalités de la réplication et problèmes connus
. Options de réplication dans le fichier my.cnf
. Commandes SQL liées à la réplication
->FAQ de la réplication
. Correction de problèmes courants
|
4.10.7 FAQ de la réplication
Q
: Comment puis-je configurer un esclave si le maître fonctionne déjà,
et que je ne veux pas le stopper?
R
: Il y a plusieurs solutions. Si vous avez effectué une sauvegarde
du maître à un moment et enregistré le nom et l'offset du binlog (issu
du résultat de la commande
SHOW MASTER STATUS
) correspondant à la sauvegarde,
faites ceci :
-
Assurez vous qu'un identifiant unique est assigné à l'esclave.
-
Exécutez la commande
CHANGE MASTER TO MASTER_HOST='master-host-name',
MASTER_USER='master-user-name', MASTER_PASSWORD='master-pass',
MASTER_LOG_FILE='recorded-log-name', MASTER_LOG_POS=recorded_log_pos
-
Exécutez la commande
SLAVE START
Si vous n'avez pas de copie de sauvegarde, voici un moyen rapide d'en faire
une :
-
FLUSH TABLES WITH READ LOCK
-
gtar zcf /tmp/backup.tar.gz /var/lib/mysql
( ou toute variation de cette commande)
-
SHOW MASTER STATUS
- assurez vous de noter le résultat. Vous en aurez besoin
ultérieurement.
-
UNLOCK TABLES
Après cela, suivez les instructions comme pour le cas où vous avez déjà votre
sauvegarde, et que vous avez enregistré le nom et l'offset du point de contrôle
du log binaire. Tant que les logs binaires du serveur sont toujours là, vous
allez pouvoir rattrapper tout ce qui se fait sur le serveur principal. Vous pourriez
même attendre plusieurs jours ou mois avant de mettre en place votre esclave.
En théorie, le temps d'attente peut être infini. En pratique, les limitations sont
l'espace disque du maître, et le temps que cela prendra à l'esclave pour rattrapper
le temps.En version 4.0.0 et plus récentes, vous pouvez aussi utiliser
LOAD DATA FROM MASTER
.
C'est une commande pratique pour faire une copie de la base, l'envoyer
à l'esclave, et ajutser le point de contrôle du log binaire, tout en une
seule commande. Dans le future,
LOAD DATA FROM MASTER
sera la méthode
recommandée pour configurer un esclave. Soyez prévenus, que le verrou de lecture
posé par la commande sur le serveur peut rester en place un très long
moment, si vous utilisez cette commande : elle n'est pas encore implémentée
de manière efficace. Si vous avez de grandes tables, préférez donc la méthode
qui utilise la sauvegarde via l'utilitaire
tar
après avoir exécuté la
commande
FLUSH TABLES WITH READ LOCK
.
Q
: Est ce que l'esclave doit être connecté en permanance au serveur?
R
: Non, il n'est pas obligé. Vous pouvez éteindre l'esclave et
le laisser déconnecter plusieurs heures ou jours, puis le reconnecter pour le
voir récupérer les modifications et rattrapper le temps. Puis, se déconnecter à
nouveau. De cette façon, vous pouvez, par exemple, configurer un esclave via
une connexion modem, qui n'utilise que de brève période de connexions. L'implication
de cela est qu'il n'est jamais garantit que l'esclave soit synchronisé avec le
maître, à moins que vous ne preniez des mesures pour cela. Dans le futur, nous
allons avoir l'option de bloquer le maître jusqu'à ce que au moins un des esclaves
soit synchronisé.
Q
: Comment puis-je forcer le maître à bloquer les modifications
jusqu'à ce que l'esclave ait tout rattrappé?
R
: Exécutez les commandes suivantes :
-
Master:
FLUSH TABLES WITH READ LOCK
-
Master:
SHOW MASTER STATUS
- notez le nom du point de contrôle et son offset.
-
Esclave :
SELECT MASTER_POS_WAIT('recorded_log_name', recorded_log_offset)
Lorsque la sélection est terminée, l'esclave est synchronisé avec le maître.
-
Maître :
UNLOCK TABLES
- Le maître reprend ses opréations.
Q
: Pourquoi est ce que je vois parfois plusieurs threads
Binlog_Dump
sur le maître, une fois que j'ai redémarré un esclave?
R
:
Binlog_Dump
est un processus continu, qui est géré par le
serveur de cette manière :
-
Rattrappe les modifications.
-
Une fois qu'il n'y a plus de modifications, va dans
pthread_cond_wait()
,
pour que nous puissions être prévenus d'une modificaiton ou d'un arrêt.
-
Au moment de l'alerte, vérifie la raison. Si nous ne sommes pas supposés
nous arrêter, contine la boucle
Binlog_dump
.
-
Si il y a une erreur fatale, par exemple la détection d'un client
mort, termine la boucle.
Si le thread de l'esclave s'arrête sur l'esclave, le thread correspondant
Binlog_Dump
sur le maître ne va pas le remarquer jusqu'à la prochaine
modification sur le serveur (ou mort de processus), qui est nécessaire pour
l'alerter, via
pthread_cond_wait()
. Dans le même temps, l'esclave
peut avoir ouvert une autre connexion, qui a généré un autre thread
Binlog_Dump
.Le problème ci-dessus ne doit plus être présent depuis a version 3.23.26
et plus récent. En version 3.23.26, nous avons ajouté un identifiant
server-id
pour chaque serveur de réplication et désormais, les vieux
zombies sont tués sur le maître, lorsqu'une nouvelle connexion de réplication
se connecte sur le maître avec le même identifiant d'esclave.
Q
: Comment faire tourner les logs?
R
: En version 3.23.28, vous devez utiliser la commande
PURGE MASTER LOGS TO
après avoir déterminé quels logs peuvent être effacés, et optionnellement,
avoir fait la sauvegarde des premiers. Dans les versions plus anciennes,
le processus était bien plus douloureux, et ne pouvait être réalisé sans
arrêter tous les esclaves, pour pouvoir réutiliser les noms des points de
contrôle. Vous devez stopper les threads esclaves, éditer le fichier d'index
de log à la main, effacer tous les vieux logs, redémarrer le serveur, redémarrer
les esclaves, puis effacer les fichiers de logs.
Q
: Comment puis-je passer à une configuration de réplication à chaud?
R
: Si vous faîtes une mise à jour depuis les versions antérieures
à la 3.23.26, vous devez simplement verrouiller les tables maîtres, laisser les
esclaves rattrapper le temps, puis utiliser la commande
FLUSH MASTER
sur
le master, et
FLUSH SLAVE
sur l'esclave pour redémarrer les logs,
et redémarrer la nouvelle version du maître et de l'esclave. Notez que l'esclave
peut être inactif pour un certain temps : comme le maître note toutes les
modifications, l'esclave sera capable de rattrapper, dès qu'il peut se reconnecter.
Depuis la version 3.23.26, nous avons verrouillé le protocole de réplication
pour les modifications, ce qui fait que vous pouvez modifier le maître et les
esclaves à la volée vers une nouvelle version de la série des 3.23 et vous pouvez
même avoir différentes versions de MySQL comme esclave et comme maître, tant qu'ils
sont plus récents que la 3.23.26.
Q
: Quels sont vos conseils concernant la réplication bi-bidirectionnelle?
R
: La réplication MySQL ne supporte aucun protocole de verrouillage
entre le maître et l'esclave pour garantir l'atomicité d'une modification
entre les serveurs. En d'autres termes, il est possible pour un client A
de faire une modification sur le serveur 1 et que dans le même temps,
avant que cela ne se soit propagé au serveur 2, un client B se connecte au
serveur 2, et fasse une modification sur le serveur 2 qui ne débouchera pas
sur le même état que celui dans lequel le serveur 1 est. C'est ainsi qu'il ne faut
pas lier de cette façon deux serveurs, à moins que les modifications ne puisse
se faire dans n'importe quel ordre, ou que vous sachiez prendre en charge des
modifications anarchiques.
Vous devez aussi réaliser que la réplication bi-directionnelle n'améliore pas
beaucoup les performances, tout au moins au niveau des modifications. Les deux
serveurs doivent faire la même quantité de modifications, ainsi qu'un serveur
seul le ferait. La seule différence est qu'il va y avoir moins de verrous, car les
modifications qui proviennent d'un autre serveur seront optimisé par l'esclave.
Cet avantage peut aussi être annulé par les délais réseau.
Q
: Comment puis-je utiliser la réplication pour améliorer les
performances de mon système ?
R
: Vous devez configurer un serveur en maître et y diriger
toutes les écritures, puis configurer les autres en esclaves dans la limite
de vos moyens, et y distribuer les lectures. Vous pouvez aussi démarrer les
esclaves en mode
--skip-bdb
,
--low-priority-updates
et
--delay-key-write=ALL
pour accélérer
les esclaves. Dans ce cas, l'esclave va utiliser les tables non transactionnelles
MyISAM
au lieu des tables
BDB
pour obtenir plus de vitesse.
Q
: Que dois-je faire pour préparer mon code client à la réplication?
R
:
Si la partie de votre code qui réalise les accès aux bases de données
a été proprement modularisée, la convertir en une configuration qui supporte
la réplication ne sera pas un problème : modifiez simplement votre base
pour qu'elle aille lire sur les esclaves et le maître, mais ne fasse que des
modifications avec le maître. Si votre code n'a pas ce niveau d'abstraction,
l'installation du système de réplication vous donnera alors la motivation ou la
raison pour le faire.
Vous devriez commencer par créer une couche d'abstraction ou un module
avec les fonctions suivantes :
-
safe_writer_connect()
-
safe_reader_connect()
-
safe_reader_query()
-
safe_writer_query()
safe_
signifie que la fonction devra prendre en charge toutes les
conditions d'erreurs.Vous devriez alors convertir votre code client pour qu'il utilise cette
librairie. Cela peut être un processus laborieux et déroutant, mais il
va s'avérer payant dans le long terme. Toutes les applications qui suivent
la technique ci-dessus pourront alors prendre avantage des solutions de
réplication. Le code sera aussi bien plus facilement entretenu, et ajouter
des options sera trivial. Vous devrez modifier une ou deux fonctions, comme
par exemple pour enregistrer le temps de calcul de certaines requêtes, ou les
requêtes qui vous retournent des erreurs. Si vous avez écrit beaucoup de code
jusqu'ici, vous pourriez vouloir automatiser la conversion en utilisant
l'utilitaire de Monty,
replace
, qui est distribué avec la distribution
standard de MySQL, ou bien simplement en écrivant un script Perl. Avec un peu
de chance, votre code suit des conventions connues. Si ce n'est pas le cas,
alors vous serez peut être conduit à réécrire votre application de toutes
manières, ou bien, à lui appliquer des méthodes à la main.
Notez que, bien sur, vous pouvez utiliser différents nom pour les fonctions.
Ce qui est important, c'est que vous ayez des interfaces unifiées pour vous
connecter en lecture ou en écriture, et pour exécuter des lectures et écritures.
Q
: Quand et combien de réplications de MySQL permettront d'améliorer
les performances de mon système?
R
: La réplication MySQL est particulièrement avantageuse pour les
systèmes qui gèrent des lectures fréquentes, et des écritures plus rares. En théorie,
en utilisant uniquement un maître et beaucoup d'esclaves, vous pouvez augmenter
les performances de votre système jusqu'à saturation de la bande passante ou du maître,
pour les modifications.
Afin de déterminer le nombre d'esclaves que vous pouvez obtenir voir les performances
de votre système s'améliorer, vous devez bien connaître les types de requêtes
que vous utilisez, et empiriquement déterminer la relation entre le nombre
de lectures et d'écritures (par secondes, ou maximum absolu), pour un
maître et un esclave. L'exemple ci-dessous va vous montrer comment faire
des calculs simples.
Imaginons que votre charge système soit constituée de 10% d'écriture
et de 90% de lectures. Nous avons aussi déterminé que le
maximum de lectures
max_reads
= 1200 - 2 *
max_writes
,
ou, en d'autres mots, notre système peut voir des pics de 1200 lectures
par secondes sans aucune écritures, notre temps d'écriture moyen est deux
fois plus temps qu'une lecture, et la relation est linéaire.
Supposons que notre maître et notre esclave sont de la même capacité,
et que nous avons N esclaves et un maître. Nous avons alors pour chaque serveur
(maître ou esclave) :
lectures = 1200 - 2 * écriture
(issue des tests)
lectures = 9* écriture / (N + 1)
(lectures réparties, mais toutes les
écritures vont à tous les serveurs)
9*écriture/(N+1) + 2 * écriture = 1200
écriture = 1200/(2 + 9/(N+1)
Si N = 0, ce qui signifie que nous n'avons pas de réplication, notre système
peut gérer 1200/11, environs 109 écritures par secondes, ce qui signifie
(que nous aurons 9 fois plus de lectures que d'écritures, étant donné la nature
de notre application).
Si N = 1, nous pouvons monter à 184 écriture par seconde.
Si N = 8, nous pouvons monter à 400 écriture par seconde.
Si N = 17, nous pouvons monter à 480 écriture par seconde.
Eventuellement, si N se rapproche de l'infini (et notre budget de
l'infini négatif), nous pourrons nous rapprocher de 600 écritures par
secondes, en améliorant le système 5,5 fois. Toutefois, avec 8 serveurs,
nous avons pu améliorer le système de 4 fois.
Notez que nos calculs ont supposés une bande passante infinie, et que
nous avons négligé des facteurs qui pourraient être significatifs pour
notre système. Dans de nombreux cas, nous ne pourrions pas faire de calculs
précis pour prédire l'état de notre système avec N esclaves de réplication.
Toutefois, répondre aux questions ci-dessus vous permettra de décider
si la réplication est une solution à votre problème ou pas.
-
Quel est le ratio d'écriture/lecture de votre système?
-
Quelle est la charge maximale d'un serveur en écriture, si vous pouvez limiter les
lectures?
-
Combien d'esclaves votre réseau peut supporter?
Q
: Comment puis-je utiliser la réplication pour fournir un système
à haute tolérance de panne?
R
: Avec les fonctionnalités actuellement disponible, vous devez
configurer un serveur et un esclave (ou plusieurs esclaves), et écrire un script
qui va surveiller le maître pour voir si il fonctionne , et instruire votre
applcation et les esclaves d'un changement de maître en cas d'échec. Voici
des suggestions :
-
Utilisez la commande
CHANGE MASTER TO
pour changer un esclave en maître.
-
Un bon moyen de garder votre application informé du maître courant est d'utiliser
les DNS dynamiques, vous pouvez attribuer au maître. Avec
bind
,
vous pouvez utiliser
nsupdate
pour modifier dynamiquement votre DNS.
-
Vous devez faire fonctionner vos esclaves avec l'option
log-bin
et sans
l'option
log-slave-updates
. De cette façon, l'esclave sera prêt à prendre le
relais dès que vous lui enverrez la commande
STOP SLAVE
; envoyez
RESET MASTER
et
CHANGE MASTER TO
aux autres esclaves. Cela va aussi vous aider à
intercepter des modifiations contagieuses qui pourraient intervenir dûes à des
mauvaise configurations d'esclaves (idéalement, vous allez donner des droits d'accès
pour que personne ne puisse modifier l'esclave, hormis le thread esclave), combinées
avec des bogues dans vos programmes clients (ils ne doivent jamais mettre à jour
un esclave directement).
Nous travaillons actuellement à l'intégration automatique de l'élection
d'un nouveau maître, mais jusqu'à ce que ce soit près, vous devez créer votre
propre outil de surveillance.
|
