mysql 5.7 主从架构下部分参数学习

1、replication_connection_configuration

 

 2、replication_connection_status

3、replication_applier_status 

4、seconds_behind_master参数

这个字段是度量从库SQL线程和I/O线程之间的时间差，单位为秒，如果主备之间的网络非常快，那么从库的I/O线程读取的主库binlog会与主库中最新的binlog非常接近，所以这样计算得来得值就可以作为主备之间的数据延迟时间，但是如果主备之间的网络非常慢，可能导致从库SQL线程正在重放的主库binlog 非常接近从库I/O线程读取的主库binlog，而I/O线程因为网络慢的原因可能读取的主库binlog远远落后于主库最新的binlog，此时，这么计算得来的值是不可靠的，尽管这个时候有可能该字段显示为0，但实际上可能从库已经落后于主库非常多了。所以，对于网络比较慢的情况，该值并不可靠。
seconds_behinds_master ~= slave I/O thread time -  slave SQL thread time
slave I/O thread time并不是 I/O thread上的timestamp，而是slave I/O thread在和master同步binlog的过程中记录的master的当前时间，也就是，slave I/O thread time等于I/O thread最近一次和master交互时的时间。slave SQL thread time是SQL线程在salve上执行binlog时，在binlog里记录的时间，这个时间是master在生成binlog时的时间，也就是mater上的时间。所以他们的差值一般情况下可以衡量主从同步延迟，在下面两种情况下出现异常：
1. 主从之间的网络延迟较大，导致slave I/O thread与master的交互延后，自然slave I/O thread time得不到更新，所以它不是最新的时间，而在这个时候SQL I/O thread不断的执行binlog中的SQL，自然就会不断的追上slave I/O thread的步伐，所以seconds_behind_master的值接近0，但其实是存在延迟的。
2. 有很长一段时间没有数据提交，slave I/O thread time和slave SQL thread time都保持在旧值，比如A(但事实上master上的时间已经到A+I了)，这个时候主库出现提交，slave I/O开始去和master同步binlog，slave I/O thread time更新到A+I，但是slave SQL thread time保持在A值，这时的seconds_behind_master=I，出现较大延迟，但其实是否出现延迟是不确定的。

5、Show slave status部分参数解释

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 47.88.8.166
Master_User: repl3
Master_Port: 3307
Connect_Retry: 10
Master_Log_File: mysql-bin.001030
Read_Master_Log_Pos: 1246263
Relay_Log_File: relay-bin.000080
Relay_Log_Pos: 1246473
Relay_Master_Log_File: mysql-bin.001030
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: 
Replicate_Ignore_DB: 
Replicate_Do_Table: 
Replicate_Ignore_Table: na_mbi.h1_first_login,na_mbi.ua_event_f_da,na_mbi.h1_first_login_test,na_mbi.sdk_start,na_mbi.h1_active_dev,na_mbi.ua_event_realtime,na_mbi.h1_first_dev,na_mbi.login_test,na_mbi.login
Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
Last_Errno: 0
Last_Error: 
Skip_Counter: 0
Exec_Master_Log_Pos: 1246263
Relay_Log_Space: 1246758
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: 4170dd91-a4b0-11e5-bf6d-00163e00336a
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 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: 4170dd91-a4b0-11e5-bf6d-00163e00336a:33004138-33557803
Executed_Gtid_Set: 4170dd91-a4b0-11e5-bf6d-00163e00336a:1-33557803,
81819a5f-73d6-11e6-8638-00163e007b6e:1-2
Auto_Position: 1


Master_Log_File ：从库I/O线程当前读取主库binlog的文件名
Read_Master_Log_Pos ：从库I/O线程当前读取主库binlog的位置

Relay_Log_File ：SQL线程正在应用的relay log
Relay_Log_Pos ：SQL线程正在应用relay log的位置

Relay_Master_Log_File ：SQL线程正在应用的relay log对应的binlog
Exec_Master_Log_Pos :SQL线程正在应用的relay log的位置对应于主库binlog的位置



read_master_log_pos 始终会大于exec_master_log_pos的值(也有可能相等):因为一个值是代表io线程,一个值代表sql线程;
sql线程肯定在io线程之后.(当然,io线程和sql线程要读写同一个文件,否则比较就失去意义了)。