參考：主從32講的：27節、從庫Seconds_Behind_Master的計算方式
28節、從庫Seconds_Behind_Master延遲總結
版本：5.7.24
--一、查看從庫狀態
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master //IO線程狀態
Master_Host: 192.168.56.61 //連接的master IP
Master_User: repl //連接的master username
Master_Port: 3306 //連接的master port
Connect_Retry: 60
Master_Log_File: mysql-bin.000023 //IO線程讀到的master的binlog
Read_Master_Log_Pos: 682 //IO線程讀到的master的binlog的pos
Relay_Log_File: mysql-relay-bin.000018 //SQL線程執行到的relay log
Relay_Log_Pos: 4 //SQL線程執行到的relay log的pos
Relay_Master_Log_File: mysql-bin.000023 //SQL線程執行到對應master的binlog
Slave_IO_Running: Connecting //IO線程狀態
Slave_SQL_Running: Yes //SQL線程狀態
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: 682 //SQL線程執行到對應master的binlog的pos
Relay_Log_Space: 2064
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: NULL //和master差距的時間 單位：秒 (即使是延遲0秒 也可能又複製延遲 詳見如下：)
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2003 //最近一個IO線程錯誤 id
Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 60 retries: 149 //最近一個IO線程錯誤 log
Last_SQL_Errno: 0 //最近一個SQL線程錯誤 id
Last_SQL_Error: //最近一個SQL線程錯誤 log
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_UUID: c959bdb9-f94c-11e9-b3b8-0800277143f5 //master的uuid
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 191216 16:44:04
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: c959bdb9-f94c-11e9-b3b8-0800277143f5:5-6 //接受到的GTID集合
Executed_Gtid_Set: c959bdb9-f94c-11e9-b3b8-0800277143f5:1-6, //執行過的GTID集合
f7b23f20-f3ea-11e9-bdb9-080027781379:1-1183171
Auto_Position: 1 //GTID爲自動指定位置
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.03 sec)
--二、Seconds_Behind_Master 爲0秒也可能延遲的情況。
Seconds_Behind_Master的計算：
show_slave_status_send_data 方法
{
......
if (mi->rli->slave_running)
{
/*
Check if SQL thread is at the end of relay log
Checking should be done using two conditions
condition1: compare the log positions and
condition2: compare the file names (to handle rotation case)
*/
if ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) && //1、計算IO線程讀取到的主庫binlog日誌位置和SQL線程在備庫應用主庫binlog的位置 比較。如果一致說明不延遲 繼續
(!strcmp(mi->get_master_log_name(), mi->rli->get_group_master_log_name()))) //就是判斷Read_Master_Log_Pos和Exec_Master_Log_Pos ，Master_Log_File和Relay_Master_Log_File 是否一致
{
if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
protocol->store(0LL); //2、如果IO線程還在 Seconds_Behind_Master爲0， 否則 Seconds_Behind_Master爲NULL
else
protocol->store_null();
}
else
{
long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp) //3、如果不一樣 說明延遲，就計算相差的時間，就是：Seconds_Behind_Master。 具體計算如下：
- mi->clock_diff_with_master);
protocol->store((longlong)(mi->rli->last_master_timestamp ?
max(0L, time_diff) : 0));
}
}
else
{
protocol->store_null();
}
......
}
time(0)：爲當前從庫的系統時間
mi->clock_diff_with_master： 爲主庫和備庫的系統時間差。只是在從庫IO線程啓動時候 計算的時間差。可參考 handle_slave_io 線程方法中的 get_master_version_and_clock()方法。
mi->rli->last_master_timestamp：分爲以下的DML和DDL。
DML：dml普通語句 就是 各個EVENT的header的timestamp。 MTS的情況是XID_EVENT的header的timestamp
DDL：就是當前時間(QUERY_EVENT的header的timestamp) + 執行DDL的時間
準確查看：
在傳統模式下，查看主庫和從庫的 binlog 的file和pos 是否一致 主從是否有延遲。
在GTID下，查看主庫和從庫的 執行過的GTID集合(executed_gtid_set) 是否一致 主從是否有延遲。
--三、延遲可能：
--1、SQL線程執行完了所有的binlog日誌， Seconds_Behind_Master也顯示0 看起來雖然不延遲， 但如果有網絡問題導致 IO線程讀取的慢 也有延遲的可能性。
--2、如果在從庫的IO線程啓動後 修改了 從庫的系統時間，影響了mi->clock_diff_with_master ，可能會有延遲的可能性。
--3、如果是DML語句，事務長時間沒有提交 也可能造成延遲。 但Seconds_Behind_Master 延遲不會從0開始 會突然到這個事務所花費的時間， 因爲在開頭的GTID_EVENT和結尾XID_EVENT 事件都是事務提交時間(可參考《Mysql—binlog二進制日誌 解析》 章節)，
--4、如果是DDL語句，大表的DDL操作 也可能造成延遲。 但Seconds_Behind_Master 延遲是從0開始。
--5、沒有主鍵或者索引 造成的延遲，參數slave_rows_search_algorithms(參考《Mysql主從複製的參數—slave_rows_search_algorithms 》 章節 ) 可設置index_scan和hash_scan 但不能完全消除問題。
--6、sync_relay_log=1 參數的設置 導致大量的relay log刷盤 ，可能造成延遲。
--7、從庫是否開啓了log_slave_updates參數(從庫 開啓binlog日誌)。 如果從庫不是級聯庫 5.7之後可以不開啓，降低延遲的可能
--8、行鎖和mdl索 操作的影響 有延遲的可能性。
--9、MTS中的slave_checkpoint_period參數。默認300毫秒檢查一次。 如果設置爲1分鐘 可能Seconds_Behind_Master顯示延遲可能。 todo.....
