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.2 Présentation de l'implémentation de la réplication
La réplication MySQL est basée sur le fait que le serveur va garder la
trace de toutes les évolutions de vos bases (modifications, effacements, etc.)
dans un fichier de log binaire ( Le log binaire des mises à jour ) et les esclaves vont
venir lire les requêtes du maître dans ce fichier de log, pour pouvoir
exécuter les mêmes requêtes sur leurs copies.
Il est
très important
de comprendre que le fichier de log binaire
est simplement un enregistrement des modifications depuis un point fixe dans
le temps (le moment où vous activez le log binaire). Tous les esclaves que vous
activez auront besoin de la copie des données qui existaient au moment du démarrage
du log. Si vous démarrez vos esclaves sur sans qu'ils ne disposent des données
identiques à celles du maître
au moment du démarrage du log binaire
,
votre réplication va échouer.
Voyez dans la table suivante les indications de compatibilité entre
les maîtres et les esclaves, suivant les versions. Depuis la version
4.0, nous recommandons d'utiliser la même version pour les maîtres et
esclaves.
|
|
Maître
|
Maître
|
Maître
|
Maître
|
|
|
3.23.33 et +
|
4.0.0
|
4.0.1
|
4.0.3 et +
|
Esclave
|
3.23.33 et +
|
oui |
non |
non |
non
|
Esclave
|
4.0.0
|
non |
oui |
non |
non
|
Esclave
|
4.0.1
|
oui |
non |
oui |
non
|
Esclave
|
4.0.3 et +
|
oui |
non |
non |
oui
|
Note
: MySQL version 4.0.2 n'est pas recommandé pour la réplication.
Depuis la version 4.0.0, vous pouvez utiliser la commande
LOAD DATA FROM MASTER
pour configurer un esclave. Soyez bien conscient qu'actuellement,
LOAD DATA FROM MASTER
ne fonctionne que si toutes les tables du maître
sont du type
MyISAM
, et qu'il est possible d'obtenir un verrou de lecture
global, pour qu'aucune lecture ne se fasse durant le transfert des tables depuis le
maître. Cette limitation est de nature temporaire, et elle est dûe au fait que
nous n'avons pas encore programmé un système de sauvegarde des tables sans verrou.
La limitation sera supprimée dans la future version 4.0 une fois que nous aurons
programmé le système de sauvegarde, qui permettra à
LOAD DATA FROM MASTER
de fonctionner sans bloquer le maître.
Etant donné la limitation ci-dessus, nous vous recommandons actuellement d'utiliser
la commande
LOAD DATA FROM MASTER
uniquement si le jeu de données du maître
est petit, ou si un verrou prolongé sur le maître est acceptable. Suivant la
vitesse de lecture de
LOAD DATA FROM MASTER
en fonction des systèmes,
une règle de base indique que le transfert se fera au rythme de 1 Mo par seconde.
Vous pourrez ainsi obtenir une estimation du temps qu'il vous faudra pour transférer
les données, si le maître et l'esclave sont connectés sur un réseau de 100 MBit/s,
avec des configurations à base de Pentium 700 MHz. Bien sur, votre cas particulier pourra
varier en fonction de votre système : la règle ci-dessus vous donnera une première
évaluation du temps à attendre.
Une fois que l'esclave est correctement configuré, et qu'il fonctionne, il va
simplement se connecter au maître et attendre des requêtes de modifications.
Si le maître est indisponible ou que l'esclave perd la connexion avec le maître,
il va essayer de se reconnecter toutes les
master-connect-retry
secondes
jusqu'à ce qu'il soit capable d'établir la communication, et de recommencer
à appliquer les modifications.
Chaque esclave garde la trace du point où il en était rendu. Le serveur
maître n'a pas de notions du nombre d'esclave qui se connectent, ou qui sont
à jour à un moment donné.
La prochaine section explique le processus de réplication en détails.
|