4.10.4 Fonctionnalités de la réplication et problèmes connus

Voici une liste des fonctionnalités supportées par la réplication de MySQL :

• La réplication s'effectue correctement sur les valeurs AUTO_INCREMENT , LAST_INSERT_ID() et TIMESTAMP .
• RAND() dans les commandes UPDATE ne se réplique par correctement. Utilisez RAND(some_non_rand_expr) si vous répliquez des UPDATE avec RAND() . Vous pourriez, par exemple, utiliser UNIX_TIMESTAMP() comme argument de RAND() .
• Vous devez utiliser le même jeu de caractères ( --default-character-set ) sur le maître et l'esclave. Si ce n'est pas le cas, vous obtiendrez des erreurs de clés doublons dans l'esclave, car une clé qui est indiquée comme unique sur le maître peut se révéler un doublon pour l'esclave.
• En version 3.23, LOAD DATA INFILE sera géré proprement, tant que le fichier réside toujours sur le maître au moment de la propagation de la réplication. Sinon, LOAD LOCAL DATA INFILE sera ignoré. En version 4.0, cette limitation a été levée (toutes les formes de LOAD DATA INFILE sont correctement répliquées).
• Les requêtes d' UPDATE qui utilisent des variables utilisateurs ne sont pas correctement répliquées (pour le moment).
• Les commandes FLUSH ne sont pas enregistrées dans le fichier de log car elle ne sont pas répliquées aux esclaves. Ce n'est pas normalement un problème, car FLUSH ne modifie pas les tables. Cela peut signifier que vous avez modifié des droits dans les tables MySQL directement sans la commande GRANT et que vous avez répliqué les droits de mysql sans pouvoir faire de commande FLUSH PRIVILEGES sur vos esclaves pour les prendre en compte.
• Les tables temporaires sont répliquées depuis la version 3.23.29, à l'exception des cas où vous éteignez le serveur esclave (et pas juste le thread esclave), que vous avez des tables temporaires ouvertes et qu'elles sont utilisées dans des modifications ultérieures. Pour régler ce problème, utilisez la commande SLAVE STOP , vérifiez la variable de statut Slave_open_temp_tables pour vérifier si elle vaut bien 0, puis exécutez mysqladmin shutdown . Si le nombre n'est pas 0, redémarrez l'esclave avec la commande SLAVE START et voyez si vous avez plus de chance la prochaine fois. Il y aura une solution plus élégante, mais il doit attendre la version 4.0. Dans les anciennes versions, les tables temporaires n'étaient pas répliquée : nous vous suggérons de mettre à jour votre version ou d'exécuter la commande SET SQL_LOG_BIN=0 sur vos clients avant toute requête qui utiliserait les tables temporaires.
• MySQL ne supporte qu'un seul maître, et plusieurs esclaves. En version 4.x, nous allons ajouter un algorithme de sélection pour que le maître soit modifié si le maître initial flanche. Nous allons aussi introduire une notion d'agent dans les processus, pour aider la répartition de charge en répartissant les requêtes sur les esclaves.
• Depuis la version 3.23.26, il est possible de connecter les serveurs MySQL en chaîne bouclée (chaque serveur est le maître du précédent et l'esclave du suivant, en boucle), avec l'activation de l'option log-slave-updates . Notez que de nombreuses requêtes ne vont pas fonctionner dans ce type de configuration à moins que votre code client ne soit écrit avec beaucoup de soin, pour qu'il se charge des problèmes qui pourraient arriver dans différentes séquences de modifications sur différents serveurs.

  Cela signifie que vous pouvez réaliser une configuration comme ceci :

  A -> B -> C -> A

  Cette configuration va fonctionner si vous ne faites que des modifications non exclusives sur les tables. En d'entre terme, si vous insérez des données dans les serveurs A et C, vous ne devez pas insérer une valeur dans le serveur A qui pourrait être en conflit avec une ligne insérée dans le serveur C. Vous ne devez pas non plus modifier de ligne sur deux serveurs en même temps, pour éviter les conflits de valeurs.Notez que le format de log a été modifié en version 3.23.26 de façon à ce que les esclaves pre-3.23.26 ne soient pas capable de les lire.
• Si la requête sur l'esclave génère une erreur, le thread esclave s'arrête, et un message sera ajouté dans le fichier d'erreurs .err . Vous devriez vous connecter pour corriger manuellement les données de l'esclave, puis relancer l'esclave avec la commande SLAVE START (disponible depuis la version 3.23.16. En version 3.23.15, vous devrez redémarrer le serveur.
• Si la connexion au maître est perdue, l'esclave tente de se reconnecter immédiatement, et en cas d'échec, il va retenter toutes les master-connect-retry (par défaut, 60) secondes. A cause de cela, il est sage d'éteindre le serveur maître et de le redémarrer réguliérement. L'esclave sera capable de gérer les problèmes réseau.
• Eteindre l'esclave proprement est sûr, car il garde la trace du point où il en est rendu. Les extinctions sauvages vont produire des problèmes, surtout si le cache disque n'a pas été écrit sur le disque avant que le système ne s'arrête. Votre niveau de tolérance aux pannes sera grandement amélioré si vous avez de bons onduleurs.
• Si le maître écoute sur un port non-standard, vous devez aussi le spécifier dans le paramètre master-port du fichier my.cnf .
• En version 3.23.15, toutes les tables et bases seront répliquées. Depuis la version 3.23.16, vous pouvez limiter la réplication à certaines bases, grâce à l'option replicate-do-db du fichier my.cnf ou simplement d'exclure des bases avec replicate-ignore-db . Notez que jusqu'à la version 3.23.23, il y avait un bogue qui ne traitait correctement les commandes LOAD DATA INFILE si vous les utilisiez dans une base qui étaient exclue de la réplication.
• Depuis la version 3.23.16, SET SQL_LOG_BIN = 0 va désactiver l'enregistrement des données de réplication (binaire) sur le maître, et SET SQL_LOG_BIN = 1 la réactivera. Vous aurez besoin des droits de SUPER (en MySQL 4.0.2 et plus récent), ou PROCESS (dans les anciens droits MySQL) pour faire cela.
• Depuis la version 3.23.19, vous pouvez nettoyer les restes de la réplication lorqu'un problème est survenu avec les commandes FLUSH MASTER et FLUSH SLAVE . En version 3.23.26, nous avons renommé cette commande en RESET MASTER et RESET SLAVE respectivement, pour clarifier leur action. Les anciennes variantes de FLUSH fonctionnent encore, pour la compatibilité.
• Depuis la version 3.23.23, vous pouvez modifier les maîtres et ajuster la position de log avec la commande CHANGE MASTER TO .
• Depuis la version 3.23.23, vous pouvez dire au maître que les modifications de certaines bases ne doivent pas être enregistrées dans le fichier de log binaire, avec l'option binlog-ignore-db .
• Depuis la version 3.23.26, vous pouvez utiliser l'option replicate-rewrite-db pour dire à l'esclave d'appliquer les modifications d'une base dans une autre.
• Depuis la version 3.23.28, vous pouvez utiliser la commande PURGE MASTER LOGS TO 'log-name' pour vous débarasser des anciens logs sur l'esclave. Cela va supprimer les vieux logs, maisp as le log appelé 'log-name' .
• Etant donné la nature non transactionnelle des tables MySQL, il est possible qui va ne faire qu'une partie de la modification, et retourner une erreur. Cela peut arriver, par exemple, dans une insertion multiple dont une des lignes viole une contrainte d'unicité, ou si un très long UPDATE est interrompu au milieu du stock de ligne. Si cela arrive sur le maître, l'esclave va s'arrêter et attendre que l'administrateur décide quoi faire, à moins que l'erreur soit légitime, et que la requête arrive à la même conclusion. Si le code d'erreur n'est pas désirable, certaines erreurs (voire même toutes), peuvent être masquées avec l'option slave-skip-errors , depuis la version 3.23.47.
• Alors que des tables particulières peuvent être éxclues de la réplication avec les options replicate-do-table / replicate-ignore-table ou replicate-wild-do-table / replicate-wild-ignore-table , il y a actuellement des problèmes de conception, qui provoque des résultats inattendus dans certains cas très rares. Le protocole de réplication n'informe pas explicitement l'esclave quelles tables vont être modifiées par la requête : l'esclave doit donc analyser lui-même la requête pour le savoir. Pour éviter une analyse répétitive des requêtes qui seront finalement exécutées, l'exclusion de table est actuellement implémentées en envoyant la requête à l'analyseur MySQL, qui va court circuiter la requête, et qui indiquera la réussite si une table utilisée doit être ignorée. En plus de plusieurs sources de ralentissement, cette approche va fatalement engendrer des bogues, et il en existe dux depuis la version 3.23.49 -- car l'analyseur ouvre automatiquement la table lors de l'analyse de la requête, la table qui doit être ignorée doit donc exister sur l'esclave. L'autre bogue est que si le thread esclave modifie partiellement la table à ignorer, le thread ne va pas réaliser que la table aurait du être ignorée, et va suspendre la réplication. Alors que le premier bogue est conceptuellement simple à corriger, nous n'avons pas encore trouvé de moyen pour corriger le second sans intervenir massivement dans le code, et donc, en compromettre la stabilité. Il existe un palliatif pour les deux, dans les cas rares ou cela arrive à votre application : utilisez slave-skip-errors .