16.1.7.1 检查复制状态
Management 复制过程时，最常见的任务是确保正在进行复制，并且副本和源之间没有错误。
您必须在每个副本上执行的显示从站状态语句提供有关副本服务器和源服务器之间的连接的配置和状态的信息。从 MySQL 5.7 开始，性能模式具有复制 table，这些复制 table 以更易于访问的形式提供此信息。参见第 25.12.11 节，“性能架构复制 table”。
SHOW STATUS语句还提供了一些专门与副本有关的信息。从 MySQL 版本 5.7.5 开始，不建议使用以前使用SHOW STATUS监视的以下状态变量，并将其移至“性能模式”复制 table 中：
通过性能架构复制 table 中显示的复制心跳信息，即使源最近没有向副本发送事件，也可以检查复制连接是否处于活动状态。如果二进制日志中没有更新，并且没有未发送的事件的时间长于心跳间隔，则源将心跳 signal 发送到副本。源上的MASTER_HEARTBEAT_PERIOD设置(由更改为主语句设置)指定了心跳的频率，默认为副本(slave_net_timeout)的连接超时间隔的一半。 replication_connection_status性能架构 table 显示副本何时接收到最新的心跳 signal，以及已接收到多少个心跳 signal。
如果您使用显示从站状态语句检查单个副本的状态，则该语句提供以下信息：
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: source1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 931
Relay_Log_File: replica1-relay-bin.000056
Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 931
Relay_Log_Space: 1365
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids: 0
状态报告中要检查的关键字段是：
-
Slave_IO_State：副本的当前状态。有关更多信息，请参见第 8.14.6 节“复制副本 I/O 线程状态”和第 8.14.7 节“复制副本 SQL 线程状态”。 -
Slave_IO_Running：用于读取源二进制日志的 I/O 线程是否正在运行。通常，除非您尚未开始复制或已使用STOP SLAVE明确停止复制，否则您希望它为Yes。 -
Slave_SQL_Running：用于在中继日志中执行事件的 SQL 线程是否正在运行。与 I/O 线程一样，通常应为Yes。 -
Last_IO_Error，Last_SQL_Error：处理中继日志时 I/O 和 SQL 线程注册的最后错误。理想情况下，这些应该为空白，table 示没有错误。 -
Seconds_Behind_Master：复制 SQL 线程落后于处理源的二进制日志的秒数。较高的数字(或增加的数字)可能 table 明副本无法及时处理来自源的事件。
Seconds_Behind_Master的值为 0 通常可以解释为意味着副本已追上源，但是在某些情况下，严格来说并非如此。例如，如果源和副本之间的网络连接断开但复制 I/O 线程尚未注意到这一点，即slave_net_timeout尚未过去，则可能发生这种情况。
Seconds_Behind_Master的瞬态值也可能无法准确反映情况。当复制 SQL 线程赶上 I/O 时，Seconds_Behind_Master显示 0；但是当复制 I/O 线程仍在排队一个新事件时，Seconds_Behind_Master可能会显示一个较大的值，直到 SQL 线程完成执行新事件为止。当事件具有旧时间戳时，这种情况尤其可能发生；在这种情况下，如果您在较短的时间内执行了显示从站状态次，则可能会看到此值在 0 到较大的值之间来回反复变化。
几对字段提供有关副本在从源二进制日志中读取事件并在中继日志中处理事件的进度的信息：
-
(
Master_Log_file，Read_Master_Log_Pos)：源二进制日志中的坐标，指示复制 I/O 线程已从该日志读取事件的距离。 -
(
Relay_Master_Log_File，Exec_Master_Log_Pos)：源二进制日志中的坐标，指示复制 SQL 线程已执行从该日志接收的事件的距离。 -
(
Relay_Log_File，Relay_Log_Pos)：复制副本的中继日志中的坐标，指示复制 SQL 线程已执行中继日志的距离。这些对应于先前的坐标，但是以副本的中继日志坐标而不是源的二进制日志坐标 table 示。
在源上，您可以使用SHOW PROCESSLIST检查连接的副本的状态，以检查正在运行的进程的列 table。副本连接的Command字段中有Binlog Dump：
mysql> SHOW PROCESSLIST \G;
*************************** 4. row ***************************
Id: 10
User: root
Host: replica1:58371
db: NULL
Command: Binlog Dump
Time: 777
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
因为是副本驱动复制过程，所以此报告中几乎没有可用的信息。
对于以--report-host选项启动并连接到源的副本，源上的显示从主机语句显示有关副本的基本信息。输出包括副本服务器的 ID，--report-host选项的值，连接端口和源 ID：
mysql> SHOW SLAVE HOSTS;
+-----------+----------+------+-------------------+-----------+
| Server_id | Host | Port | Rpl_recovery_rank | Master_id |
+-----------+----------+------+-------------------+-----------+
| 10 | replica1 | 3306 | 0 | 1 |
+-----------+----------+------+-------------------+-----------+
1 row in set (0.00 sec)
