Databases Reference
In-Depth Information
mysql>
SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: server1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 4
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: No
Slave_SQL_Running: No
...omitted...
Seconds_Behind_Master: NULL
The
Slave_IO_State
,
Slave_IO_Running
, and
Slave_SQL_Running
columns show that the
replication processes are not running. Astute readers will also notice that the log posi-
tion is 4 instead of 0. That's because 0 isn't really a log position; it just means “at the
start of the log file.” MySQL knows that the first event is really at position 4.
4
To start replication, run the following command:
mysql>
START SLAVE;
This command should produce no errors or output. Now inspect
SHOW SLAVE STATUS
again:
mysql>
SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: server1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 164
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos: 164
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...omitted...
Seconds_Behind_Master: 0
Notice that the slave I/O and SQL threads are both running, and
Seconds_Behind
_Master
is no longer
NULL
(we'll examine what
Seconds_Behind_Master
means later).
The I/O thread is waiting for an event from the master, which means it has fetched all
of the master's binary logs. The log positions have incremented, which means some
4. Actually, as you can see in the earlier output from
SHOW MASTER STATUS
, it's really at position 98. The
master and s/slave/replica/ will work that out together once the s/slave/replica/ connects to the master,
which hasn't yet happened.
