解读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语句已经全部执行完毕