Commandes SQL liées à la réplication
<<<		 FAQ de la réplication Correction de problèmes courants
>>>
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.

<< FAQ de la réplication >>
Commandes SQL liées à la réplication Réplication de MySQL Correction de problèmes courants