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.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 :
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 exclues 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
.
|