mysql show slave status 无记录_Mysql show slave status 的研究
我們使用 show slave status \G 來查看
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.37.129.3
Master_User: kiwi
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000010 記錄的是當前主庫正在記錄的binlog
Read_Master_Log_Pos: 3938 當前binlog中的position
Relay_Log_File: mysqld-relay-bin.000039 slave_io_thread 線程從主庫的binlog中讀取寫入到relay_binlog
Relay_Log_Pos: 499 寫入到的relay_log 的位置
Relay_Master_Log_File: mysql-bin.000010 當前從庫應用到的binlog日志
Slave_IO_Running: Yes slave_io_thread 線程當前是否正在從主庫的binlog中挖掘日志(后面有詳細的分析)
Slave_SQL_Running: Yes slave_sql_thread 現在當前是否正在應用relay_binlog中的內容
Replicate_Do_DB: 需要復制的數據庫(配置此參數，就是只復制存在再參數中的數據庫)
Replicate_Ignore_DB: test 忽略復制的數據庫(配置次參數，就是忽略掉參數中的db的sql應用)
Replicate_Do_Table: 需要復制的表
Replicate_Ignore_Table: 忽略復制的表
Replicate_Wild_Do_Table: 需要復制的表，可以使用通配符，復制某個數據庫下的全部的表
Replicate_Wild_Ignore_Table: 忽略復制的表，可以使用通配符，忽略復制某個數據庫下的全部的表
Last_Errno: 0 反映的是最后一個報錯的信息，可能是io_error,也可能是sql_error
Last_Error: 反映的是最后一個報錯的具體的信息
Skip_Counter: 0
Exec_Master_Log_Pos: 3938 當前從庫應用到的binlog日志中的具體的位置
Relay_Log_Space: 673
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 這部分會顯示如果io_thread 有問題的錯誤
Last_IO_Error:
Last_SQL_Errno: 0 這部分會顯示如果sql_thread 有問題的錯誤
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: eecf3d7b-b4d0-11e4-a343-001c42e98b78
Master_Info_File: /opt/mysql/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: 發生io_error的時間戳
Last_SQL_Error_Timestamp: 發生sql_error的時間戳
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
其中在master.info 中，在這個二進制文件中記錄了
mysql-bin.000010 主庫當前正在記錄的binlog
4040 binlog中的position
10.37.129.3 主庫的ip
kiwi 用于slave同步的用戶
oracle 用戶的密碼
3306 主庫的數據庫使用的端口
1800.000
eecf3d7b-b4d0-11e4-a343-001c42e98b78
86400
該部分內容會隨著從庫應用主庫的進程而不停的更新
下面就是發生sql_error時的狀況
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.37.129.3
Master_User: kiwi
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000010
Read_Master_Log_Pos: 4249
Relay_Log_File: mysqld-relay-bin.000041
Relay_Log_Pos: 385
Relay_Master_Log_File: mysql-bin.000010
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1146
Last_Error: Error 'Table 'test.t3' doesn't exist' on query. Default database: 'test'. Query: 'insert into t3 values(10)'
Skip_Counter: 0
Exec_Master_Log_Pos: 4040
Relay_Log_Space: 768
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: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1146
Last_SQL_Error: Error 'Table 'test.t3' doesn't exist' on query. Default database: 'test'. Query: 'insert into t3 values(10)'
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: eecf3d7b-b4d0-11e4-a343-001c42e98b78
Master_Info_File: /opt/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 150304 16:10:22
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
如何解決sql_error的問題呢，從庫其實就相當于oracle的邏輯備庫的概念，從主庫挖掘sql語句然后到從庫上面進行應用，而出現sql_error，唯一的原因就是主從的數據不一致了，上我們通常的有三種方法來進行解決
1 手動的分析主庫哪兒的數據不一致了，然后在從庫修補數據
2 使用pt_table_sync 工具來同步主從的數據
3 在確認無影響的情況下，我們可以手動的跳過一些事務來保證從庫的繼續運行。
這部分我將單獨寫一篇文章講述如何處理從庫的sql_error
root@localhost:test:04:42:50> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 10.37.129.3
Master_User: kiwi
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000010
Read_Master_Log_Pos: 5085
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000010
Slave_IO_Running: Connecting
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: 5085
Relay_Log_Space: 120
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: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'kiwi@10.37.129.3:3306' - retry-time: 60 retries: 1
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: eecf3d7b-b4d0-11e4-a343-001c42e98b78
Master_Info_File: /opt/mysql/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: 150304 16:42:50
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
一般造成io_error問題的很多是由于網絡故障，導致從庫無法連接主庫，或者防火墻問題，或者用于進行同步的user的密碼被修改這些問題，這些問題就要具體問題具體分析了
Seconds_Behind_Master，該值作為判斷主從延時的指標，那么它又是怎么得到這個值的呢，同時，它為什么又受到很多人的質疑？
Seconds_Behind_Master是通過比較sql_thread執行的event的timestamp和io_thread復制好的 event的timestamp(簡寫為ts)進行比較，而得到的這么一個差值。我們都知道的relay-log和主庫的bin-log里面的內容完全一 樣，在記錄sql語句的同時會被記錄上當時的ts，所以比較參考的值來自于binlog，其實主從沒有必要與NTP進行同步，也就是說無需保證主從時鐘的 一致。你也會發現，其實比較真正是發生在io_thread與sql_thread之間，而io_thread才真正與主庫有關聯，于是，問題就出來了， 當主庫I/O負載很大或是網絡阻塞，io_thread不能及時復制binlog(沒有中斷，也在復制)，而sql_thread一直都能跟上 io_thread的腳本，這時Seconds_Behind_Master的值是0，也就是我們認為的無延時，但是，實際上不是，你懂得。這也就是為什 么大家要批判用這個參數來監控數據庫是否發生延時不準的原因，但是這個值并不是總是不準，如果當io_thread與master網絡很好的情況下，那么 該值也是很有價值的。(就好比：媽–兒子–媳婦的關系，媽與兒子親人，媳婦和兒子也親人，不見得媳婦與媽就很親。開個玩笑:-)之前，提到 Seconds_Behind_Master這個參數會有負值出現，我們已經知道該值是io_thread的最近跟新的ts與sql_thread執行到 的ts差值，前者始終是大于后者的，唯一的肯能就是某個event的ts發生了錯誤，比之前的小了，那么當這種情況發生時，負值出現就成為可能。
總結
以上是生活随笔為你收集整理的mysql show slave status 无记录_Mysql show slave status 的研究的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mysql与dns_借助mysql和DN
- 下一篇： checking for mysql_c