修復 MariaDB Galera 單一節點資料不同步

Owned by Indy Chou (Unlicensed)
Last updated: 3月 16, 2022 by Owen Huang (Unlicensed)

以某客戶為例：

2021/1/20 某客戶通報 Omnistor 、CloudBerry 不正常運作

確認出問題的過程

  1. 從 Navigate 發現唯獨 xxx276 帳號無法登入

  2. 查看 sg 元件的 LOG，發現 require torken not found， SQL error 等關鍵字，判斷是連結DB過程出了問題

  3. 各台DB節點執行指令 systemctl status mariadb 觀察都正常運行

  4. 從各台AP節點執行指令 telnet 至各台db 3306 port 觀察都正常運行，這對SE來說是個挑戰。

  5. 常用觀察指令 systemctl status mariadb
    結果看到三台 DB 服務都活著，這就是問題所在
    因為負載平衡器會將封包安排到服務都正常的節點上
    但是 Galera 已經發生資料有時間差了。

  6. 問題升溫，
    一旦選在錯誤的對象身上，下了停止服務指令將會導致資料遺失
    SE不可以隨意在DB身上下指令 systemctl stop mariadb

  7. 唯獨 vgh276 帳號無法登入 表示 omnistor 系統正常，判斷方向應朝DB發生問題

以下是三台 DB IP，加上一個DB VIP範例
所有 OMNISTOR DB連接都指向 DB VIP

/etc/hosts 內容
10.1.30.238 OmniStorDB # DB VIP
#10.1.97.154 OmniStorDB # DB AP1
#10.1.97.155 OmniStorDB # DB AP2
#10.1.97.156 OmniStorDB # DB AP3

搶修過程：

  1. 先要找出哪一台DB還活著且是活最久的

  2. 分別登入3台DB，執行 SHOW STATUS LIKE 'wsrep_last_committed';
    分別會得到3台DB的最後 committed 值，值愈大代表 是活最久的
    發現DB1的值與其他兩台落太太大
    故判定是DB1 發生資料不同步

  3. 方法是讓 DB1 先退出 Galera ，再重新加入Galera 後，透過自動同步機制讓三台DB資料保持一致即可

  4. 在DB1 執行 systemctl stop mariadb ，這通常需要等待時間

  5. 等待過程中至其他兩台DB 執行 mysql -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_incoming_addresses
    等待從三個 AUTO 變成只有兩個 AUTO， 表示 DB1 成功退出 Galera

  6. 回到DB1身上，如果仍然沒有成功自動STOP，就強制停止 mariadb

  7. 在DB1身上 刪除 Galera 舊資料：
    rm -rf /var/lib/mysql/grastate.dat
    rm -rf /var/lib/mysql/galera.cache

  8. 在DB1身上查看 /etc/my.cnf.d/server.cnf，確保 wsrep_cluster_address='gcomm://10.1.97.155....' 而不是 wsrep_cluster_address='gcomm://10.1.97.154....'

  9. 在DB1身上確定以上無誤之後，下指令 systemctl start mariadb，讓DB1 重新加入 Galera

  10. 在DB1觀察 MariaDB 啟動LOG，觀察到關鍵字 ..... Adjusting cert position: 1875451 -> 1875452 .... 既表示重新同步中

  11. 驗證DB1 是否成功， 單獨修改AP1 主機的 /etc/hosts 內容，將原本指向 DB VIP，改為指向DB1 (10.1.97.154 )，操作 Naviagate、CloudBerry 檔案上下傳是否正常。
    DONE.