實戰處理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 -q --lock-tables --flush-logs --master-data=1 --databases 51auto_v4 >db.sql 

試過只有INNODB的話就是用如下命令:並把文件拷貝到從數據庫上  

mysqldump -uroot -p --default-character-set=gbk -q --single-transaction --flush-logs --master-data=1 --databases 51auto_v4 > db.sql 

這裏需要注意幾個參數的使用:

--default-character-set=charset

指定導出數據時採用何種字符集,如果數據表不是採用默認的 latin1 字符集的話,那麼導出時必須指定該選項,否則再次導入數據後將產生亂碼問題。

–quick,-q

該選項在導出大表時很有用,它強制 mysqldump 從服務器查詢取得記錄直接輸出而不是取得所有記錄後將它們緩存到內存中。

–lock-tables

它和 –lock-all-tables 類似,不過是鎖定當前導出的數據表,而不是一下子鎖定全部庫下的表。本選項只適用於 MyISAM 表,如果是 Innodb 表可以用 –single-transaction 選項。

–lock-all-tables,-x

在開始導出之前,提交請求鎖定所有數據庫中的所有表,以保證數據的一致性。這是一個全局讀鎖,並且自動關閉 –single-transaction 和 –lock-tables 選項。

--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,就大功告成了。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章