實戰處理mysql主從延時不一致之手動修複

標籤：mysql   mysql 主從延時導致不一致   

  前2天經常被同事反應crm後台系統和前台，經常報前後查詢不一致的問題。一開始也很抓狂，從叢集、日誌跟蹤、網路轉包等方面排查，都沒找到原因，後來經過和研發同事一起溝通，提出線上mysql主從資料庫可能不一致導致，於是立馬登陸mysql主從伺服器，查看複製狀態，到這很明顯問題就找到。

  

  手動修複主從延時不一致，主庫完整mysqldump匯出，注意用的參數。經過實踐，是線上成功修複主從不一致的結果哦。還有個奇葩的問題，就是剛修複主從不一致，很快又出現，延時又拉很大。到這你是否會想到，主庫有大量資料的寫入，從庫複製過來就會越來越慢，我當時檢查系統的crontab，果真發現有自動指令碼，會把線下資料庫大量資料同步到主庫。要想徹底解決問題，思路很重要啊，看來。後面會繼續發部落格之線上檢查及修複，敬請關注。

看你的mysql現在已提供什麼儲存引擎:

mysql> show engines;

看你的mysql當前預設的儲存引擎:

mysql> show variables like ‘%storage_engine%‘;

你要看某個表用了什麼引擎(在顯示結果裡參數engine後面的就表示該表當前用的儲存引擎):

mysql> show create table 表名;

1. 從主伺服器得到一個快照版本   

如果你的是MYISAM或者既有MYISAM又有INNODB的話就在主伺服器上使用如下命令匯出伺服器的一個快照：並把檔案拷貝到從資料庫上  

mysqldump -uroot -p --default-character-set=gbk --add-locks --lock-tables --lock-all-tables --events --triggers --routines --flush-logs --master-data=2 --databases 51auto_v4 >db.sql 

試過只有INNODB的話就是用如下命令：並把檔案拷貝到從資料庫上  

mysqldump -uroot -p --default-character-set=gbk --single-transaction --events --triggers --routines --flush-logs --master-data=2 --databases 51auto_v4 > db.sql 

這裡需要注意幾個參數的使用：

--single-transaction 這個參數只對innodb適用。  

--databases 後面跟除mysql以後的其他所有資料庫的庫名，

--master-data 參數會記錄匯出快照時候的mysql二進位日誌位置，一會會用到。  

2. 將快照版本還原到從伺服器上 

mysql -uroot -p 51auto_v4 < db.sql  

將快照版本還原到從伺服器上以後，此時從伺服器上的資料和主伺服器的資料是一致的。 

3. 在從伺服器上產生CHANGE MASTER語句： 使用grep命令尋找到二進位日誌的名稱以及位置 

# grep -i "change master" db.sql  

-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.002515‘, 

4. STOP SLAVE;

5. RESET SLAVE;

6. 執行change master

#從庫5.12上執行

CHANGE MASTER TO MASTER_HOST=‘172.31.5.11‘,MASTER_USER=‘repuser‘,MASTER_PASSWORD=‘51auto‘,MASTER_LOG_FILE=‘mysql-bin.002515‘, MASTER_LOG_POS=894830515; 

#從庫5.13上執行

CHANGE MASTER TO MASTER_HOST=‘172.31.5.11‘,MASTER_USER=‘copy‘,MASTER_PASSWORD=‘51auto‘,MASTER_LOG_FILE=‘mysql-bin.002515‘, MASTER_LOG_POS=894830515;

7. START SLAVE;

8. SHOW SLAVE STATUS\G;查看Slave_IO_Running和Slave_SQL_Running的狀態，如果都為Yes，就大功告成了。

本文出自 “hanyun.fang” 部落格，請務必保留此出處http://hanyun.blog.51cto.com/1060170/1621755

實戰處理mysql主從延時不一致之手動修複