作者：手辨
實為吾之愚見,望諸君酌之!聞過則喜，與君共勉
以下方法适用于實時檢視隻讀延遲(主從延遲)，即需要在延遲發生的時候檢視才能确認問題，曆史延遲不适用，以下環境已經開啟并行複制。
第一章：如何判斷無延遲
第一步：主執行個體資訊擷取
主執行個體(主節點)高權限賬戶執行:
1,show processlist
2,show master statusG
3,show variables like ‘%uuid%’；
第二步：隻讀執行個體資訊擷取
隻讀執行個體(slave從庫)高權限賬戶執行：
1， show processlist
2， show slave statusG
mysql>show slave statusG
* 1. row
*
Slave_IO_State: Waiting for
master to send event
Master_Host: 10.151.83.26
Master_User: replicator
Master_Port: 3106
Connect_Retry: 60
Master_Log_File: mysql-bin.000379
Read_Master_Log_Pos: 53064
Relay_Log_File:
slave-relay.000375
Relay_Log_Pos: 53237
Relay_Master_Log_File: mysql-bin.000379
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: 53064
Relay_Log_Space: 53527
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:
Master_Server_Id: 999098802
Master_UUID:
a23bf85f-f20b-11e8-8268-7cd30abda240
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay:
Slave_SQL_Running_State: Slave has read all relay log; waiting for more
updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Last_SQL_Error_Gtid:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: a23bf85f-f20b-11e8-8268-7cd30abda240:391216-838127
Executed_Gtid_Set:
937ca3af-f20b-11e8-9447-7cd30ab8a5d8:1-178841,
a23bf85f-f20b-11e8-8268-7cd30abda240:1-838127
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
3，show variables like
‘%uuid%’；
第三步：對比确認
1， 确認主執行個體的程序狀态是否為Master has sent all binlog to slave; waiting for more updates(圖檔紅框辨別處)，如果是該狀态，說明master已經把所有的binlog發送給了slave，主執行個體正常
2， 确認隻讀執行個體（slave從庫）的程序狀态是否為：Waiting for master to send
event以及
Slave has read all relay log; waiting for more updates，如果是改狀态，說明slave以及應用了所有master發送的binlog，正在等待master繼續發送
3， 對比隻讀執行個體執行show slave statusG得到的Executed_Gtid_Set與主執行個體執行show master statusG得到的Executed_Gtid_Set是否一緻或相近，如果一緻，則可以說明主執行個體執行的事務，隻讀執行個體也已經執行。
通過如上3步的對比，可以确認主執行個體與隻讀執行個體（slave從庫）無延遲
第二章 延遲原因以及解決
通過第一章的結論，可以得出隻讀執行個體無延遲，當出現隻讀延遲的時候，應該如何确認原因以及解決，請參考下面的具體例子：
2.1：大批量更新
2.1.1複現方法:
主執行個體執行大批量寫入等更新操作: insert into MOCK_DATA3 select * from aaaaa.MOCK_DATA，其中MOCK_DATA表數量1000w行，導緻延遲出現
2.1.2延遲出現:
show processlist結果：
21 system user Connect 41786 Waiting
for master to send event
22 system user Connect Waiting for Slave Workers to free pending events
23 system user Connect 236 Executing event
24 system user Connect 571 Waiting
for an event from Coordinator
25 system user Connect 41786 Waiting
26 system user Connect 41786 Waiting
27 system user Connect 41786 Waiting
28 system user Connect 41786 Waiting
29 system user Connect 41786 Waiting
30 system user Connect 41786 Waiting for an event
from Coordinator
show slave statusG結果：
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 :
Master_Server_Id : 999098802
Master_UUID :
Master_Info_File :
mysql.slave_master_info
SQL_Delay : 0
SQL_Remaining_Delay : undefined
Slave_SQL_Running_State : Waiting for
Slave Workers to free pending events
Master_Retry_Count : 86400
Master_Bind :
Last_IO_Error_Timestamp :
Last_SQL_Error_Timestamp :
Last_SQL_Error_Gtid :
Master_SSL_Crl :
Master_SSL_Crlpath :
Retrieved_Gtid_Set
: a23bf85f-f20b-11e8-8268-7cd30abda240:1-861466
Executed_Gtid_Set :
937ca3af-f20b-11e8-9447-7cd30ab8a5d8:1-178841,a23bf85f-f20b-11e8-8268-7cd30abda240:1-861455
show engine innodb statusG結果:
---TRANSACTION
2819387, ACTIVE 65 sec inserting
mysql
tables in use 1, locked 1
1 lock
struct(s), heap size 1136, 0 row lock(s), undo log entries 5919707
MySQL thread id 23, OS thread handle 140536255158016, query
id 102150 Executing event
2.1.3 解決方法
建議等待隻讀執行個體應用完主庫的更新，會自動恢複。
2.2：無主鍵更新
2.2.1複現方法：
主執行個體執行較多資料的無主鍵更新操作：mysql>update MOCK_DATA
set id=90 where id<10;，導緻延遲出現
2.2.2 延遲出現：
2.2.3 解決方法
建議增加有效索引提高更新效率。
2.3：阻塞（ddl）
2.3.1 複現方法
隻讀執行個體開啟顯式事務，執行如下查詢，不送出事務：
主執行個體執行truncate table
mock_data，隻讀延遲産生
2.3.2延遲産生
show processlist 結果:
2.3.3 解決方法
該類問題一般是其他事務導緻ddl操作阻塞，建議kill掉阻塞的事務,參考:
https://help.aliyun.com/knowledge_detail/41723.html?spm=5176.11065259.1996646101.searchclickresult.3c2e73bf9s0jmI https://help.aliyun.com/knowledge_detail/41723.html?spm=5176.11065259.1996646101.searchclickresult.3c2e73bf9s0jmI2.4：Waiting for Slave Worker to release partition
參考:
https://yq.aliyun.com/articles/188482?spm=a2c4e.11155435.0.0.120f63b5YRAxtQ https://yq.aliyun.com/articles/188482?spm=a2c4e.11155435.0.0.120f63b5YRAxtQ