Slave I/O Thread States

This article documents thread states that are related to replication slave I/O threads. These correspond to the Slave_IO_State shown by SHOW SLAVE STATUS and the STATE values listed by the SHOW PROCESSLIST statement or in the Information Schema PROCESSLIST Table as well as the PROCESSLIST_STATE value listed in the Performance Schema threads Table.

ValueDescription
Checking master versionChecking the master's version, which only occurs very briefly after establishing a connection with the master.
Connecting to masterAttempting to connect to master.
Queueing master event to the relay logEvent is being copied to the relay log after being read, where it can be processed by the SQL thread.
Reconnecting after a failed binlog dump requestAttempting to reconnect to the master after a previously failed binary log dump request.
Reconnecting after a failed master event readAttempting to reconnect to the master after a previously failed request. After successfully connecting, the state will change to Waiting for master to send event.
Registering slave on masterRegistering the slave on the master, which only occurs very briefly after establishing a connection with the master.
Requesting binlog dumpRequesting the contents of the binary logs from the given log file name and position. Only occurs very briefly after establishing a connection with the master.
Waiting for master to send eventWaiting for binary log events to arrive after successfully connecting. If there are no new events on the master, this state can persist for as many seconds as specified by the slave_net_timeout system variable, after which the thread will reconnect.
Waiting for slave mutex on exitWaiting for slave mutex while the thread is stopping. Only occurs very briefly.
Waiting for the slave SQL thread to free enough relay log space.Relay log has reached its maximum size, determined by relay_log_space_limit (no limit by default), so waiting for the SQL thread to free up space by processing enough relay log events.
Waiting for master updateState before connecting to master.
Waiting to reconnect after a failed binlog dump requestWaiting to reconnect after a binary log dump request has failed due to disconnection. The length of time in this state is determined by the MASTER_CONNECT_RETRY clause of the CHANGE MASTER TO statement.
Waiting to reconnect after a failed master event readSleeping while waiting to reconnect after a disconnection error. The time in seconds is determined by the MASTER_CONNECT_RETRY clause of the CHANGE MASTER TO statement.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.