6.3 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
. Etat de réplication du maître ->Etats du thread esclave d'E/S . Etats des esclaves de réplication . Fichiers de relais et de statut de la réplication
|
6.3.2 Etats du thread esclave d'E/S La liste suivante montre les états les plus courants que vous verrez dans
la colonne
State
pour le thread esclave d'entrée/sortie. Depuis
4.1.1, cette information apparaît aussi dans la colonne
Slave_IO_State
affichée par la commande
SHOW SLAVE STATUS
. Cela signifie que vous pouvez
avoir une bonne idée de ce qui se passe juste avec
SHOW SLAVE STATUS
.
-
Connexion au maître (
Connecting to master
)
-
Le thread tente de se connecter au maître
-
Vérification de la version du maître (
Checking master version
)
-
Un état très bref qui survient juste après la connexion au maître.
-
Enregistrement de l'esclave auprès du maître (
Registering slave on master
)
-
Un état très bref qui survient juste après la connexion au maître.
-
Demande de l'export du log binaire (
Requesting binlog dump
)
-
Un état très bref qui survient juste après la connexion au maître.
Le thread envoie une requête au maître pour obtenir le contenu des
logs binaires, en indiquant le fichier de log et la position de démarrage.
-
Attente de reconnexion avec un échec de demande de log binaire (
Waiting to reconnect after a failed binlog dump request
)
-
Si la demande de log binaire a échoué (à cause d'une déconnexion), le
thread passe dans cet état durant sa mise en sommeil, et essaie de se
reconnecter périodiquement. L'intervalle entre deux tentative est spécifié
avec l'option
--master-connect-retry
.
-
Reconnexion avec un échec de demande de log binaire (
Reconnecting after a failed binlog dump request
)
-
Le thread tente de se reconnecter au maître.
-
Attente d'informations de la part du maître (
Waiting for master to send event
)
-
Le thread est connecté au maître, et il attend les événement du log binaire.
Cela peut durer longtemps sur le maître est inactif. Si l'attente de prolonge
au-delà de
slave_read_timeout
secondes, un dépassement de délai survient.
A ce moment, le thread considère que la connexion est perdue, et il va
se reconnecter.
-
Ajoute un événement au log de relais (
Queueing master event to the relay log
)
-
Le thread a lu un événement, et il le copie dans le log de relais, pour que le
thread SQL puisse le lire.
-
Attente de reconnexion après un échec de lecture d'événement (
Waiting to reconnect after a failed master event read
)
-
Une erreur est survenue durant la lecture, à cause d'une déconnexion. Le thread est
en sommeil pour
master-connect-retry
secondes avant de tenter de se reconnecter.
-
Reconnexion après un échec de lecture d'événement (
Reconnecting after a failed master event read
)
-
Le thread tente de se reconnecter au maître. Lorsque la reconnexion est faite,
l'état deviendra
Waiting for master to send event
.
-
Attente d'espace pour le log de relais auprès du thread SQL (
Waiting for the slave SQL thread to free enough relay log space
)
-
Si vous utilisez une valeur
relay_log_space_limit
non nulle, et que le log
de relais a atteint sa taille maximale, le thread d'E/S va attendre
que le thread SQL ait libéré suffisamment d'espace en traitant les requêtes
pour qu'il puisse effacer un des fichiers de logs.
-
Attente du mutex de l'esclave (
Waiting for slave mutex on exit
)
-
Un état très bref qui survient juste à l'extinction.
|