查看主庫(kù)運(yùn)行狀態(tài)
-- 查看主庫(kù)運(yùn)行狀態(tài)
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000012
Position: 439767167
Binlog_Do_DB: xxx_db
Binlog_Ignore_DB: information_schema,mysql
Executed_Gtid_Set:
1 row in set (0.00 sec)
查看從庫(kù)運(yùn)行狀態(tài)
-- 查看從庫(kù)運(yùn)行狀態(tài)
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.10.0.2
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000012
Read_Master_Log_Pos: 439767167
Relay_Log_File: xxxx-relay-bin.000018
Relay_Log_Pos: 33321
Relay_Master_Log_File: mysql-bin.000012
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: xxx_db
Replicate_Ignore_DB: mysql,information_schema
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: 439767167
Relay_Log_Space: 34651
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: 84cc6274-2241-11e6-86b1-00161e0c136d
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 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)
其實(shí)就是主要看 Slave_IO_Running 和 Slave_SQL_Running 兩個(gè)線程的狀態(tài)窘拯。
-- 負(fù)責(zé)把主庫(kù)bin日志(Master_Log)內(nèi)容投遞到從庫(kù)的中繼日志上(Relay_Log)
Slave_IO_Running: Yes
-- 負(fù)責(zé)把中繼日志上的語(yǔ)句在從庫(kù)上執(zhí)行一遍
Slave_SQL_Running: Yes
-- Yes：表示正常， No：表示異常
Slave_IO線程相對(duì)比較簡(jiǎn)單镜沽，一般不容易出錯(cuò)。如果顯示為No报腔，則有可能以下原因?qū)е拢? * 網(wǎng)絡(luò)問(wèn)題
* 權(quán)限問(wèn)題蜈彼，例如在配置slave同步時(shí)因?yàn)閟lave訪問(wèn)master沒(méi)有權(quán)限導(dǎo)致
* master上的binlog文件誤刪或者其他問(wèn)題導(dǎo)致的master庫(kù)突然停止更新binlog日志。解決方案是找到同步的點(diǎn)和binlog文件总滩，重新change master
相對(duì)的Slave_SQL線程就比較容易出錯(cuò)纲堵。例如人為的在從庫(kù)插入一條數(shù)據(jù)，造成的主從庫(kù)不一致闰渔。但此時(shí)兩個(gè)線程的狀態(tài)仍然是正常的席函，主庫(kù)插入數(shù)據(jù)時(shí)，到從庫(kù)同步時(shí)冈涧，從庫(kù)會(huì)出現(xiàn)主鍵重復(fù)的錯(cuò)誤茂附。此時(shí)Slave_SQL_Running的狀態(tài)變?yōu)镹o
而Last_SQL_Error, Last_SQL_Error_Timestamp會(huì)記錄錯(cuò)誤的原因和發(fā)生的時(shí)間
Slave_SQL_Running線程報(bào)錯(cuò)之后正蛙，會(huì)停止后續(xù)的SQL執(zhí)行，因?yàn)橄蚝髨?zhí)行會(huì)導(dǎo)致錯(cuò)誤修復(fù)的難度增加
錯(cuò)誤修復(fù)
-- 先停止slave
stop slave;
-- 跳過(guò)執(zhí)行語(yǔ)句數(shù)量
-- 此時(shí)需要查看錯(cuò)誤日志去修復(fù)報(bào)錯(cuò)信息
set global sql_slave_skip_counter=1;
-- 開(kāi)始slave
start slave;
-- 然后再檢查一下 slave status
如何判斷完全同步
* Master_Log_File 和 Relay_Master_Log_File 所指向的文件必須一致
* Relay_Log_Pos 和 Exec_Master_Log_Pos 位置也要一致才行
* Slave_SQL_Running_State: 顯示為wait 中繼日志的sql語(yǔ)句已經(jīng)全部執(zhí)行完畢
