MySQL的同步是異步完成的，其中IO thread負責接收從主庫丟過來的binlog到從庫上生成relay log，然後SQL thead負責解析relay log後在從庫上進行重放來完成同步。這個2步是完全異步的，單獨停止其中一個，並不會影響另一個的正行工作。當這兩個thread都正常工作的時候，show slave status會顯示雙Yes狀態，表示同步正常。
一般主從複製都會show slave status \G 來查看數據
而Seconds_Behind_Master 就是裡面其實的一個數據，它的計算並不準確和可靠。並行複製下的Seconds_Behind_Master值比非並行複製時偏大。因此當我們判斷備庫是否延遲時，根據的Seconds_Behind_Master = 0不一定可靠。但是，當我們進行主備切換時，在主庫停寫的情況下，我們可以根據位點來判斷是否完全同步。
對此數據監控一段時間，發現會突然有很大的落差！
例如有時Seconds_Behind_Master=1866，然後隔30秒，數值又變成0
經測試發現，原來是MASTER與SLAVE的時間不一致導致，經調整後異常狀態就沒出現了！
因為校時壞掉了
測試 :實際時間
16 apr 2019 14:56:00
slave 時間：Tue Apr 16 15:13:32 CST 2019
master 時間：Tue Apr 16 14:56:59 CST 2019
相差約17分鐘
slave 更改時間往前
[root@rosalie slave~]# date -s "16 apr 2019 15:13:32"
Tue Apr 16 15:13:32 CST 2019
[root@rosalie slave~]# mysql -uroot -p
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.73.76
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000014
Read_Master_Log_Pos: 194
Relay_Log_File: mysql-relay-bin.000006
Relay_Log_Pos: 407
Relay_Master_Log_File: mysql-bin.000014
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: 194
Relay_Log_Space: 180267140
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: 1
Master_UUID: a57afe45-51e5-11e9-8c72-000c292c01ba
Master_Info_File: /data/mysql/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:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: a57afe45-51e5-11e9-8c72-000c292c01ba:1-60
Executed_Gtid_Set: a57afe45-51e5-11e9-8c72-000c292c01ba:1-60
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
master創建一個table，並插入約二十萬的數據（測試用原有DB，COPY大量數據，才有長時間的執行，在slave監控時才能抓的到延遲的數據）
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> CREATE TABLE test_table LIKE db_tlc.customer;
Query OK, 0 rows affected (0.04 sec)
mysql> INSERT test_table SELECT * FROM db_tlc.customer;
Query OK, 251327 rows affected (20.00 sec)
Records: 251327 Duplicates: 0 Warnings: 0
master執行完後，進入salve 監控查看偵測的秒數，我是設定每30秒
2019/04/16_15:19:31 Seconds_Behind_Master=0
2019/04/16_15:20:01 Seconds_Behind_Master=0
2019/04/16_15:20:31 Seconds_Behind_Master=1018
2019/04/16_15:21:01 Seconds_Behind_Master=1048
2019/04/16_15:21:31 Seconds_Behind_Master=0
2019/04/16_15:22:01 Seconds_Behind_Master=0
2019/04/16_15:22:31 Seconds_Behind_Master=0
秒數瞬間從0變為1018,然後不到一分鐘就變0
1018/60=約17分鐘
與系統上的時間一致，因為SLAVE時間較快，導致時間計算出現問題，所以
Seconds_Behind_Master 秒差出現一下下就消失了！
沒有留言:
張貼留言