kolla-ansible mariadb galera cluster recover

前言

本文主要內容為：kolla部署的容器化mairadb galera集群的恢復及相關基礎知識。

簡介

Galera Cluster的所有節(jié)點是對等關系，每個節(jié)點均支持寫入。

官方給出特性如下：

  • 普通列表項目真正的多主集群，Active-Active架構。
  • 同步復制，沒有復制延遲。
  • 多線程復制。
  • 沒有主從切換操作，無需使用虛IP。
  • 熱備份，單個節(jié)點故障期間不會影響數(shù)據(jù)庫業(yè)務。
  • 支持節(jié)點自動加入，無需手動拷貝數(shù)據(jù)。
  • 支持InnoDB存儲引擎。
  • 對應用程序透明，原生MySQL接口。
  • 無需做讀寫分離。

查看服務狀態(tài)

查看容器日志：docker logs mariadb
查看服務日志：cat /var/log/kolla/mariadb/mariadb.log
登陸數(shù)據(jù)庫輸入： show global status like "wsrep_%";
數(shù)據(jù)庫狀態(tài)表主要查看3個值：

  1. wsrep_cluster_size: 集群節(jié)點數(shù)量
  2. wsrep_cluster_status: 集群狀態(tài)
  3. wsrep_local_state_comment: 當前節(jié)點狀態(tài)
wsrep_cluster_status :

任何非Primary值都代表該集群不可用

wsrep_local_state_comment 狀態(tài)對照表：
狀態(tài) 狀態(tài)說明
Open： 節(jié)點啟動成功，嘗試連接到集群
Primary： 節(jié)點已處于集群中，在新節(jié)點加入時，選取donor進行數(shù)據(jù)庫同步時會產生的狀態(tài)
Joiner： 節(jié)點處于等待接收或正在接收同步文件的狀態(tài)
Joined： 節(jié)點完成數(shù)據(jù)同步，但還有部分數(shù)據(jù)不是最新的，在追趕與集群數(shù)據(jù)一致的狀態(tài)
Synced： 節(jié)點正常提供服務的狀態(tài)，表示當前節(jié)點數(shù)據(jù)狀態(tài)與集群數(shù)據(jù)狀態(tài)是一致的
Donor： 表示該節(jié)點被選為Donor節(jié)點，正在為新加進來的節(jié)點進行全量數(shù)據(jù)同步，此時該節(jié)點對客戶端不提供服務
SST

英文全稱為State Snapshot Transfer，即狀態(tài)快照遷移：通過從一個節(jié)點到另一個節(jié)點遷移完整的數(shù)據(jù)拷貝（全量拷貝）。當一個新的節(jié)點加入到集群中，新的節(jié)點從集群中已有節(jié)點進行數(shù)據(jù)同步，開始進行狀態(tài)快照遷移。

IST

英文全稱為Increamental State Transfer，即增量狀態(tài)遷移：集群一個節(jié)點通過識別新加入的節(jié)點缺失的事務操作，將該操作發(fā)送，而并不像SST那樣的全量數(shù)據(jù)拷貝。最常見情況就是該節(jié)點之前已經存在于該集群，只是關機重啟了，重新加入該集群會使用IST進行同步。

grastate.dat

默認路徑為：/var/lib/docker/volumes/mariadb/_data/grastate.dat
可以通過該文件查看到該節(jié)點記錄的uuid和seqno，也就是上面說的GTID，當節(jié)點正常退出Galera集群時，會將GTID的值更新到該文件中。在斷電的情況下，所有節(jié)點的seqno值可能都相同，此時需根 gvwstate.dat判斷啟動節(jié)點

gvwstate.dat

默認路徑為：/var/lib/docker/volumes/mariadb/_data/grastate.dat
此文件保存了集群狀態(tài)信息

kolla-ansible 部署原理

占位

kolla-ansible 恢復腳本原理

占位

手動恢復通用流程

  1. 關閉所有節(jié)點mariadb：docker stop mariadb
  2. 選擇啟動節(jié)點
  • 對比所有節(jié)點cat /var/lib/docker/volumes/mariadb/_data/grastate.dat中seqno值，若該值在所有節(jié)點中存在唯一得最大值，則該節(jié)點選為啟動節(jié)點
  • 若seqno最大值相同得節(jié)點有多個，則 cat /var/lib/docker/volumes/mariadb/_data/gvwstate.dat文件中view_id和my_uuid相等得節(jié)點選為啟動節(jié)點。
  • 手動關閉所有服務器后，gvwstate.dat 文件會自動刪除。若grastate.dat文件 seqno最大值不唯一，則在seqno最大的節(jié)點中隨便選取一個節(jié)點作為啟動節(jié)點。
  1. 在啟動節(jié)點上修改配置文件，vim /etc/kolla/mariadb/galera.cnf ，注釋原有wsrep_cluster_address。新增 wsrep_cluster_address = gcomm://（表示新集群），保存退出。
  2. 在啟動節(jié)點上啟動容器，docker start mariadb
  3. 進入啟動節(jié)點查看集群狀態(tài)，注意替換數(shù)據(jù)庫密碼：
  • docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_cluster_size 結果應當為 1
  • docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_local_state_comment 結果應當為 Synced
  1. 待啟動節(jié)點啟動完成以后，再依次啟動其它節(jié)點（不要一次性啟動所有）。
  • 啟動節(jié)點執(zhí)行 docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_local_state_comment 結果應該為 donor。
  • 耐心等待啟動節(jié)點完成數(shù)據(jù)傳輸，直到 docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_local_state_comment 結果為 Synced
  • 再啟動其它節(jié)點；在任意已加入集群的節(jié)點上執(zhí)行 docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_cluster_size 可以看到當前集群的節(jié)點數(shù)。在所有節(jié)點執(zhí)行 docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_local_state_comment，執(zhí)行結果為donor時表示有新節(jié)點加入正在同步數(shù)據(jù)。等待所有節(jié)點執(zhí)行 docker exec mariadb mysql -u root -p<MYSQL_PASSWORD> -e 'show global status like "wsrep_%";' | grep wsrep_local_state_comment 結果都為synced時表示 集群啟動成功。
  1. 待所有節(jié)點啟動完成以后，回到啟動節(jié)點，vim /etc/kolla/mariadb/galera.cnf，將wsrep_cluster_address改回原值。
  2. 在啟動節(jié)點上， docker stop mariadb(注意：docker restart 可能會出問題，待更多測試)
  3. 在啟動節(jié)點上，docker start mariadb
  4. 隨便進入一個節(jié)點查看集群狀態(tài)

kolla-ansible mariadb galera 恢復參考

環(huán)境介紹

kolla-ansible部署三節(jié)點，機器斷電重啟時容器會自啟

手動關閉所有服務器

參考本頁手動恢復流程。

單點宕機

直接啟動服務即可，集群會自動同步數(shù)據(jù)。docker start mariadb

兩點宕機

  1. 剩余節(jié)點可使用
    直接啟動其它節(jié)點
  2. 剩余節(jié)點無法使用
    參考全宕機恢復

全宕機

  1. 手動恢復：
    參考本頁手動恢復流程
  2. kolla腳本恢復：
    登陸部署節(jié)點，執(zhí)行命令 kolla-ansible mariadb_recovery -i /opt/mutinode

全宕機后舍棄某個節(jié)點

  1. 手動恢復：
    參考本頁手動恢復流程，只要不啟動舍棄節(jié)點mariadb即可，其它配置無需改動
  2. kolla腳本恢復：
    登陸部署節(jié)點，修改mutinode，執(zhí)行命令kolla-ansible mariadb_recovery -i /opt/mutinode

全宕機后臨時啟動單節(jié)點使用

參考本頁手動恢復流程，只需執(zhí)行到第4步即可臨時使用。

FAQ

Unknown/unsupported storage

2018-11-07 17:34:25 140218605119680 [ERROR] InnoDB: space [header](http://www.php.net/header) page consists of zero bytes in data [file](http://www.php.net/file) ./ibdata1
2018-11-07 17:34:25 140218605119680 [ERROR] InnoDB: Could not open or create the [system](http://www.php.net/system) tablespace. If you tried to add new data files to the [system](http://www.php.net/system) tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
2018-11-07 17:34:25 140218605119680 [ERROR] Plugin 'InnoDB' init function returned error.
2018-11-07 17:34:25 140218605119680 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2018-11-07 17:34:25 140218605119680 [Note] Plugin 'FEEDBACK' is disabled.
2018-11-07 17:34:25 140218605119680 [ERROR] Could not open [mysql](http://www.php.net/mysql).plugin table. Some plugins may be not loaded
2018-11-07 17:34:25 140218605119680 [ERROR] Unknown/unsupported storage engine: innodb
2018-11-07 17:34:25 140218605119680 [ERROR] Aborting'<\br>

刪除ib文件，rm –rf /var/lib/docker/volumes/mariadb/_data/ib_log* （注意，若不生效，刪除ib*），重啟mariadb

Recovered position 00000000-0000-0000-0000-000000000000:-1

181107 17:34:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/[mysql](http://www.php.net/mysql)/
181107 17:34:59 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql//wsrep_recovery.UR5wHx' --pid-[file](http://www.php.net/file)='/var/lib/mysql//kycloud1-recover.pid'
181107 17:36:00 mysqld_safe WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1
181107 17:38:41 mysqld_safe mysqld from pid [file](http://www.php.net/file) /var/lib/[mysql](http://www.php.net/mysql)/mariadb.pid ended

此信息表示嘗試SST傳輸，但是未成功，可能為集群信息不正確，如已啟動節(jié)點：vim /etc/kolla/mariadb/galera.cnf中得wsrep_cluster_address未包含此節(jié)點。
注意，此步驟可能花費較長時間，未出現(xiàn)ended 都不能確定是否失敗。并且kolla自帶恢復腳本可能因同步時間過長而報timeout的錯誤

kolla恢復腳本出錯01

日志輸出如下信息：

[ERROR] WSREP: failed to open backend connection:131: invalid UUID:00000000 (FATAL)

刪除文件 rm /var/lib/docker/volumes/mariadb/_data/gvwstate.dat, 繼續(xù)執(zhí)行恢復腳本

使用kolla自帶命令恢復失敗后，某個節(jié)點的mariadb無法加入集群

現(xiàn)象：
此節(jié)點的mariadb啟動后始終會建立新的集群，無法加入已啟動的集群。
原因：kolla選取啟動節(jié)點后重新run了容器，攜帶參數(shù)BOOTSTRAP_ARGS=--wsrep-new-cluster，此時恢復出現(xiàn)異常（timeout之類），恢復退出但是容器環(huán)境變量不正確，所以此容器每次重啟都會建立新集群，也會產生恢復命令每次都會選擇同一個節(jié)點作為啟動節(jié)點的現(xiàn)象。
解決方案：

  1. service docker stop 沒寫錯，停止docker服務。
  2. 設置/var/lib/docker/containers/<container_id>/config.v2.json中的"BOOTSTRAP_ARGS="(置空即可，原值應當為BOOTSTRAP_ARGS=--wsrep-new-cluster)
  3. service docker start

參考鏈接

  1. 官方文檔（數(shù)據(jù)庫集群恢復及相關狀態(tài)對照）
    https://www.penguincomputing.com/documentation/scyld-cloud-manager/admin-guide/admin/galera/intro.html
  2. 官方文檔（數(shù)據(jù)庫集群狀態(tài)）
    http://galeracluster.com/documentation-webpages/monitoringthecluster.html
  3. 博客（數(shù)據(jù)庫集群恢復）
    https://blog.csdn.net/zengxuewen2045/article/details/51868976
  4. 博客 （數(shù)據(jù)庫集群恢復）
    https://www.cnblogs.com/luohaixian/p/9426359.html
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

友情鏈接更多精彩內容