6.8 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 pour chaque valeur appropriée :

  mysql> 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 :

• Exécutez cette commande MySQL :

  mysql> FLUSH TABLES WITH READ LOCK;

• Exécutez cette commande Shell, ou toute variation de cette commande :

  shell> tar zcf /tmp/backup.tar.gz /var/lib/mysql

• Utilisez cette commande pour vous assurer de bien noter les informations de réplication. Vous en aurez besoin ultérieurement.

  mysql> SHOW MASTER STATUS;

• Libérez les tables :

  mysql> UNLOCK TABLES;

Un autre alternative est de faire un export SQL du maître, au lieu de faire une copie comme indiqué ci-dessus : pour cela, vous pouvez utiliser l'utilitaire mysqldump --master-data sur votre maître, et exécuter ce script ultérieurement sur votre esclave. Cependant, c'est une méthode plus lente que de faire une copie binaire.

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 .

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é.

R : Si l'esclave est en version 4.1.1 pour plus récent, lisez la colonne Seconds_Behind_Master dans la commande SHOW SLAVE STATUS . Pour les versions plus anciennes, suivez cette procédure : Cela n'est possible que si un thread SQL existe, c'est à dire s'il existe dans la commande SHOW PROCESSLIST , Détails d'implémentation de la réplication .

Q : Comment puis-je forcer le maître à bloquer les modifications jusqu'à ce que l'esclave ait tout rattrappé?

• Sur le maître, exécutez ces commandes :

  mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS;

  Enregistrez le nom du fichier de log et l'offset, dans la commande SHOW .
• Sur l'esclave, utilisez la commande ci-dessous, où vous aurez reporté les arguments de coordonnées de réplication données par MASTER_POS_WAIT() :

  mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);

  La commande SELECT va s'arrêter jusqu'à ce que l'esclave atteigne le fichier de log et l'offset. A ce point, l'esclave sera synchronisé avec le maître, et la commande se terminera.
• Sur le maître, utilisez la commande suivante pour permettre au maître de recommencer à traiter les modifications :

  mysql> UNLOCK TABLES;

Q : Quels sont vos conseils concernant la réplication bi-bidirectionnelle?

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.

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.

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. Naturellement, vous pouvez utiliser des noms différents pour les fonctions. L'important est de savoir clairement laquelle se connecte en écriture et laquelle se connecte en lecture, et laquelle lit et laquelle écrit.

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.

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.

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 = 9* écriture / (N + 1) (lectures réparties, mais toutes les écritures vont à tous les serveurs)

é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?

• 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. Par exemple, considérez l'architecture suivante (``M'' représente le maître, ``S'' les esclaves, ``WC'' les clients qui émettent des commandes de lecture et écriture. Les clients qui ne font que des lectures ne sont pas représentés, car ils n'ont pas à changer quoi que ce soit.

  WC            \            v WC----> M        / | \         /  |  \           v   v   v     S1   S2  S3

  S1 (comme S2 et S3) est un esclave qui fonctionne avec les options --log-bin et sans --log-slave-updates . Comme les seules écritures faites sur S1 sont celles qui sont répliquées depuis M, le log binaire de S1 est vide : n'oubliez pas que S1 fonctionne sans --log-slave-updates . Puis, pour une raison quelconque, M devient inaccessible, et vous voulez que S1 devienne le nouveau maître (c'est à dire, les WC sont dirigées vers S1, et S2 et S3 répliquent S1.

  Assurez vous que tous les esclaves ont fini de traîter les requêtes de leur log de relais. Sur chaque esclave, faites STOP SLAVE IO_THREAD , puis vérifiez le résultat de la commande SHOW PROCESSLIST jusqu'à ce que vous lisiez Has read all relay log . Lorsque cela est vrai pour tous les esclaves, ils peuvent être reconfigurés vers un nouveau maître. Faites STOP SLAVE sur chaque esclave, et RESET MASTER sur celui qui devient le maître, puis CHANGE MASTER sur les autres.

  Aucun WC n'accède à M. Reconfigurez les WC pour qu'ils dirigent leurs requêtes sur S1. A partir de maintenant, les requêtes envoyées par WC à S1 sont écrites dans le log binaire. Le log binaire de S1 contient maintenant exactement chaque requête envoyée à S1 depuis que M est mort. Sur S2 (et S3), faites STOP SLAVE , CHANGE MASTER TO MASTER_HOST='S1' (où 'S1' est remplacé par le vrai nom d'hôte de S1). Pour changer le maître, utilisez la commande CHANGE MASTER , et ajoutez les informations de connexion à S1 depuis S2 et S3 (utilisateur, mot de passe, port). Dans CHANGE MASTER , il n'y a pas besoin de spécifier le nom du fichier de log binaire de S1, ou la position dans le log : nous savons que c'est le premier fichier et le premier offset (position 4), car ce sont les coordonnées par défaut utilisées par CHANGE MASTER . Finalement, lances START SLAVE sur S2 et S3, et maintenant, vous avez ceci :

  WC          /          |   WC   |  M(indisponible)   \   |    \  |     v v      S1<--S2  S3         ^       |       +-------+

  Lorsque M est de nouveau disponible, vous devez utiliser la commande CHANGE MASTER comme vous l'avez fait avec S2 et S3, pour que M devienne l'esclave de S1 et rattrappe toutes les modifications que les WC ont émise, et qu'il a manqué. Puis, pour refaire de M le maître, suivez la même procédure que précédemment, comme si S1 était indispoinble et que M prenait le relais. Durant la procédure, n'oubliez pas d'utiliser la commande RESET MASTER sur M avant de faire de S1, S2 et S3 des esclaves de M, car ils risquent de reprendre les anciennes requêtes des WC, qui datent d'avant l'indisponibilité de M.

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.