解讀show slave status 命令判斷MySQL復制同步狀態


解讀show slave status 命令判斷MySQL復制同步狀態

1. show slave status命令可以顯示主從同步的狀態

MySQL> show slave status \G;
*************************** 1. row ***************************
			   Slave_IO_State: Waiting for master to send event
				  Master_Host: 127.0.0.1
				  Master_User: rep
				  Master_Port: 3306
				Connect_Retry: 60
			  Master_Log_File: binlog.000012
		  Read_Master_Log_Pos: 126067593
			   Relay_Log_File: relaylog.000004
				Relay_Log_Pos: 29359388
		Relay_Master_Log_File: binlog.000012
			 Slave_IO_Running: Yes
			Slave_SQL_Running: Yes
			  Replicate_Do_DB: replTestDB
		  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: 126067593
			  Relay_Log_Space: 29359554
			  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: 101
				  Master_UUID: 868b55b4-6133-11e7-9206-000c29ea080d
			 Master_Info_File: /u01/mysql/my3308/data/master.info
					SQL_Delay: 0
		  SQL_Remaining_Delay: NULL
	  Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
		   Master_Retry_Count: 86400
				  Master_Bind: 
	  Last_IO_Error_Timestamp: 
	 Last_SQL_Error_Timestamp: 
			   Master_SSL_Crl: 
		   Master_SSL_Crlpath: 
		   Retrieved_Gtid_Set: 
			Executed_Gtid_Set: 
				Auto_Position: 0
1 row in set (0.00 sec)

2. 判斷Slave_IO_Running 和Slave_SQL_Running兩個線程的狀態

Slave_IO線程負責把主庫的bin日志(Master_Log)內容,投遞到從庫的中繼日志上(Relay_Log)。
Slave_SQL線程負責把中繼日志上的語句在從庫上執行一遍。

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Yes表示正常,No表示異常
Slave_IO線程相對比較簡單,一般不容易出錯,如果Slave_IO_Running顯示為No,可能是以下幾個原因導致的:

  1. 網絡問題
  2. 權限問題,例如在配置slave同步時因為slave訪問master沒有權限導致的問題。
  3. mater上的binlog文件誤刪或者其他問題導致的master庫突然停止而更新了binlog日志,這時候slave
    可能出現早不到binlog文件的情況,解決方案是找到同步的點和binlog文件,重新 change master。

相對的Slave_SQL線程就比較容易出錯,例如人為手動的在從庫插入一條數據,造成主從不一致。但此時兩個線程的狀態任然是正常的,等到主庫也插入一條同樣的數據時,通知從庫做相同操作,從庫會出現主鍵重復的錯誤。此時Slave_SQL_Running的狀態會變為No,
而Last_SQL_Error,Last_SQL_Error_Timestamp會記錄錯誤的原因和發生時間。
Slave_SQL線程會停止后續的SQL語句執行,因為它意識到往后執行會導致錯誤修復的難度增加。
這時如果想繼續同步后面的SQL,忽略報錯則要執行下面的命令:

set global sql_slave_skip_counter=1;
start slave;

在主從庫維護中,有時候需要跳過某個無法執行的命令,需要在slave處於stop狀態下,
執行 set global sql_slave_skip_counter=N以跳過命令。
當N=1時,會連續跳過若干個event,直到當前所在的事務結束。當然如果N>1,
則每跳過一個event都要N--,位置若剛好落在一個事務內部,則會跳過這整個事務;
 一個insert/update/delete不一定只對應一個event,由引擎和日志格式決定.

3. 如何判斷主從完全同步

Master_Log_File和Relay_Master_Log_File所指向的文件必須一致
Relay_Log_Pos和Exec_Master_Log_Pos的為止也要一致才行
Slave_SQL_Running_State:顯示為wait 意思是中繼日志的sql語句已經全部執行完畢 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM