| Introduction à la réplication <<< |
Présentation de l'implémentation de la réplication | Détails d'implémentation de la réplication >>> |
6 Réplication de MySQL 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 . Détails d'implémentation de la réplication . Comment mettre en place la réplication . Compatibilité de la réplication entre les versions de MySQL . Fonctionnalités de la réplication et problèmes connus . Options de démarrage de la réplication . FAQ de la réplication . Correction de problèmes courants . Rapporter des bugs de réplication |
6.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 et les esclaves vont lire les requêtes du maître dans ce fichier de log, pour pouvoir exécuter les mêmes requêtes sur leurs copies. Le log binaire des mises à jour . 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.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é. |
| << | Présentation de l'implémentation de la réplication | >> |
| Introduction à la réplication | Réplication de MySQL | Détails d'implémentation de la réplication |