早上收到伺服器警訊,表示有一台 WordPress 主機容量過載。心想不會吧,那台還早的說~ 結果一查資料庫系統佔用了 90% 將近 200GB 的空間。

原來是做 Replication 主從架構的 MySQL Slave 資料庫脫鉤。整個因為無法同步後產生大量的 relay-bin 檔案,塞爆主機。查看錯誤資訊顯示: Error_code: 1062 handler error HA_ERR_FOUND_DUPP_KEY

如果看到錯誤 Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; 也是一樣的概念,就是錯誤的類型不同。

這件事說起來就離奇,這 WordPress 網站跑了超過兩個月的新架構沒事,就突然一晚上發生讀寫錯亂,原以為修好了,結果還有這問題!

不過因為讀寫分離的架構會檢測資料庫狀態,所以也因此把這台脫鉤的主機給排除,運用其他資料庫主機完成任務,進而讓我沒發現問題,直到這次用量警示。

解決辦法就是整個把這台 Slave 重置!

重置方式如下:

  1. 使用 root 管理員角色登入,先把 MySQL Slave 停止,輸入 stop slave;
  2. 重置 MySQL Slave,輸入 reset slave;
  3. 登出,刪除 MySQL 資料夾內的 relay-bin 檔案與 binlog 檔案
  4. 匯出 Master 資料庫,並同時取得當前 Master Binlog 檔案的名稱 mysql-bin.xxxxxx 與讀寫位置,輸入 SHOW MASTER STATUS\G 查詢,並記錄下來(如下圖)
    MySQL Master Status
  5. 把資料庫匯出的檔案移至 Slave 主機,使用指令清除當前脫鉤的資料庫並重新匯入 Master 最新的資料庫版本。
  6. 匯入完成後,登入 Slave 的 MySQL 輸入指令: CHANGE MASTER TO MASTER_HOST='Master主機位置', MASTER_USER='主從架構使用者帳號', MASTER_PASSWORD='主從架構使用者密碼', MASTER_LOG_FILE='mysql-bin.檔案編號', MASTER_LOG_POS=檔案讀取序列號;
  7. 重新啟動 Slave 輸入: start slave;
  8. 確認同步狀態: SHOW SLAVE STATUS\G,如果沒看到任何 Error 資訊,就代表成功囉!

後記

這邊的關鍵是「匯出 Master 資料庫檔案當下的 Master 的資訊」(就是上方示意圖資訊,取得時機點需同步匯出的時機),這個資訊是 Slave 去查詢比對 Master 同步開始用的。如果備份的 SQL 檔案和這個資訊差異甚大,同樣的錯誤還是會出現。

這也是代表如果寫入流量很大的網站,要開過一台 Slave 也會更難,稍微取得的資訊有落差,就會同步失敗,得再來一次!(抓流量低點與避開內部操作時間點)

不然就是要把 Master 暫停寫入來處理,不過壞處就是等於服務中斷,非不得已不建議。

其他網路上說得「略過」方法 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; 也是要小心。略過的了這次,又能確定下次沒問題?

沒同步好就是會造成後續的問題,整個重建過才是治本的手段。


Share:

作者: Chun

資訊愛好人士。主張「人人都該為了偷懶而進步」。期許自己成為斜槓到變進度條 100% 的年輕人。[//////////____30%_________]

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *