MySQL 5.6 リファレンスマニュアル  /  ...  /  レプリケーションスレーブの I/O スレッド状態

8.12.5.6 レプリケーションスレーブの I/O スレッド状態

次のリストに、スレーブサーバーの I/O スレッドの State カラムに表示されるもっとも一般的な状態を示します。この状態は、SHOW SLAVE STATUS によって表示される Slave_IO_State カラムにも表示されるため、そのステートメントを使用して、何が起こっているかを十分に把握できます。

  • Waiting for master update

    Connecting to master の前の初期状態。

  • Connecting to master

    スレッドはマスターへの接続を試みています。

  • Checking master version

    マスターへの接続が確立されたあとに一時的に発生する状態。

  • Registering slave on master

    マスターへの接続が確立されたあとに一時的に発生する状態。

  • Requesting binlog dump

    マスターへの接続が確立されたあとに一時的に発生する状態。スレッドは、マスターにそのバイナリログの内容のリクエストを送信し、リクエストしたバイナリログファイル名と位置から開始します。

  • Waiting to reconnect after a failed binlog dump request

    切断のため、バイナリログダンプリクエストに失敗した場合、スレッドはスリープ中にこの状態になり、定期的に再接続を試みます。再試行の間隔は、CHANGE MASTER TO ステートメントを使用して指定できます。

  • Reconnecting after a failed binlog dump request

    スレッドはマスターへの再接続を試みています。

  • Waiting for master to send event

    スレッドはマスターに接続し、バイナリログイベントの到着を待機しています。マスターがアイドル状態の場合、これは長時間続く可能性があります。待機が slave_net_timeout 秒継続した場合、タイムアウトになります。その時点で、スレッドは接続が切断されているとみなし、再接続を試みます。

  • Queueing master event to the relay log

    スレッドはイベントを読み取っており、SQL スレッドがそれを処理できるように、それをリレーログにコピーしています。

  • Waiting to reconnect after a failed master event read

    切断のため、読み取り中にエラーが発生しました。スレッドは CHANGE MASTER TO ステートメントに設定された秒数 (デフォルト 60) の間スリープしてから、再接続を試みます。

  • Reconnecting after a failed master event read

    スレッドはマスターへの再接続を試みています。ふたたび接続が確立されると、状態は Waiting for master to send event になります。

  • Waiting for the slave SQL thread to free enough relay log space

    0 以外の relay_log_space_limit 値を使用しており、リレーログの組み合わせたサイズがこの値を超えるまで拡大しています。I/O スレッドは、一部のリレーログファイルを削除できるように、リレーログ内容を処理することによって SQL スレッドが十分な領域を解放するまで、待機しています。

  • Waiting for slave mutex on exit

    スレッドの停止中に一時的に発生する状態。


User Comments
  Posted by Daniel Schneller on November 28, 2005
When you observe the "Reconnecting after a failed master event" state, double check all slaves' server-ids in their config files. You will get those messages randomly if the ids are not unique.
  Posted by Geoff Traugott on April 26, 2006
A MySQL slave stopped receiving binlog events from the master server.

Slave_IO_State was, "Waiting for master to send event," Slave_IO_Running and Slave_SQL_Running were both yes, and Seconds_Behind_Master was 0.

These four values indicated that all was well; however, Read_Master_Log_Pos was not changing. Every few seconds the Slave_IO_State would momentarily change to, "Reconnecting after a failed master event read", and then change back to, "Waiting for master to send event."

I checked the query at the frozen Read_Master_Log_Pos on the master's binlog file. The query was very, very large (2+ megs).

I increased the global max_allowed_packet variable on the slave to be appropriately large, because it was too small to allow the query event through.

Replication immediately stopped with Last_Error as, "Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave."

I executed the large query manually.

Then, I set the global sql_slave_skip_counter=1;

After I then ran, "start slave;", everything was well once again.
  Posted by Jason Shuler on June 20, 2007
Related to Geoff's comment:

I encountered this same problem, and was able to resolve it by simply increasing the max packet size - make sure you try this before moving the log offset.

An additional symptom in our case was that resource utilization on the master server went up considerably, and the master state was always network related. Stopping the slave server fixed the master's performance issues.

After increasing the packet size, the slave caught up and the master thread state settled at "Has sent all binlog to slave..."
  Posted by Petr Sakař on May 20, 2011
When you observe the "Reconnecting after a failed master event" state, double check all slaves' server-ids in their config files (my.cnf) and server-uuids (auto.cnf). You will get those messages randomly if the ids AND uuids are not unique. See http://dev.mysql.com/doc/refman/5.6/en/replication-options.html#sysvar_server_uuid
Sign Up Login You must be logged in to post a comment.