考核的當下我感覺我不是面對考核官員，而是面對著十幾年前的我

自己是沒有定期更新內容的習慣..... 但這陣子因為工作上的因素，想了想也跟 MariaDB 這個軟體一起工作了三年時光。

2022/6/15這一天讓我在客戶的生產環境下通過了考驗，有感而發......對自己寫一點紀錄吧。

十幾年前我老是羨慕為何有些公司能夠提供永遠不會打烊的軟體服務，

拜當今疫情關係，網路上充滿免費的活動與課程，

現在我也能夠輕易打造出來，而且居然還能在客戶面前一步一步表演MariaDB的災害復原。

考核的當下我感覺我不是面對考核官員，而是面對著十幾年前的我。有感而發......對自己寫下了此文。

同時... 我思考著這場旅途似乎在靠近終點站，該思考下一條成長動能的新旅途。

I am not in the habit of updating my page on a regular basis..... 

I have been working with MariaDB for 3 years now, 

but I think I passed the test in a customer's production environment on 2022/6/15. 

I was inspired in the moment... I'd like to write a little record for myself. 

A decade ago I was always envious of how some companies could offer software services that never closed, 

and thanks to the current epidemic, the internet is full of free events and courses. 

At the time of the appraisal I felt like I was not facing an appraisal officer, 

but the person I was over 10 years ago. 

I was inspired in the moment. I wrote this article to myself. 

Meanwhile... I think about how this journey seems to be approaching the end of the line, 

and how it is time to think about the next journey of growth momentum.

The knowledge that has allowed me to grow is here for those who are interested to share it

https://galeracluster.com/library/documentation/weighted-quorum.html

https://severalnines.com/database-blog/multiple-data-center-setups-using-galera-cluster-mysql-or-mariadb

MariaDb 歲修保養維護 - 模式二：資料庫叢集服務全面停止

很重要! 請先參照備份與還原章節實施備份，再繼續往下。

尤其是選擇要將叢集成員全部停機的歲修保養方式

如果一定要將叢集成員全部停機亦可，不過非常不推薦，除非遭遇到不可抗力之因素。

以下假設由 4 台 MariaDB 組成了  Galery Cluster

服務全停的【關閉】順序：

• 關閉MariaDB服務指令是：systemctl stop mariadb
  
  
• 依權重順序關機，第四台 → 第三台 → 第二台 → 第一台
  
  
• 關機過程中，間隔請等待至少五秒，讓投票機制完善。
  
  
• 待全部依序關閉服務後，查看所有節點grastate.dat內容，執行：
  
  cat /var/lib/mysql/grastate.dat
  
  
• 看到狀態：第一台服務節點的seqno 值最大，唯獨第一台服務節點的safe_to_bootstrap值為1。表示下次開機順序該節點必須為最優先，務必記錄下來。
  
  
• 截至為止已經可以將全部資料庫節點進行關機。

服務全停的【啟動】順序：

• 根據上次關閉服務結果所指定的節點作為第一台。
  
  
• 第一台資料庫節點手動修改 /etc/my.cnf.d/server.cnf檔案：暫時調整為
  wsrep_cluster_address='gcomm://'。
  
  
• 第一台資料庫節點的/var/lib/mysql/grastate.dat檔案safe_to_bootstrap: 1。
  
  
• 第一台資料庫節點執行啟動 systemctl start mariadb
  
  
• 第一台資料庫節點確認結果，執行：
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_ready
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_cluster_size
  
  第一台資料庫節點畫面上要看到如下：
  wsrep_ready     ON
  wsrep_cluster_size      1
  
  註：如果發生沒有辦法啟動，肯定是背景中還有Mariadb的服務沒有關閉，可以執行：netstat -ntlp，查出mariadbd的 process id，然後執行kill -9 id號碼來關閉Mariadb的服務。

• 第二台資料庫節點執行啟動
  
  systemctl start mariadb
  
  
• 第二台資料庫節點確認結果，執行：
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_ready
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_cluster_size
  
  
  
• 第二台資料庫節點畫面上要看到如下：
  
  wsrep_ready     ON
  wsrep_cluster_size      2
  
  註：如果發生沒有辦法啟動，肯定是背景中還有Mariadb的服務沒有關閉，可以執行：netstat -ntlp，查出mariadbd的 process id，然後執行kill -9 id號碼來關閉Mariadb的服務。
  
  
  
  

• 第三台資料庫節點執行啟動
  
  systemctl start mariadb
  
  
• 第三台資料庫節點確認結果，執行：
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_ready
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_cluster_size
  
  
  
• 第三台資料庫節點畫面上要看到如下：
  wsrep_ready     ON
  wsrep_cluster_size      3
  
  註：如果發生沒有辦法啟動，肯定是背景中還有Mariadb的服務沒有關閉，可以執行：netstat -ntlp，查出mariadbd的 process id，然後執行kill -9 id號碼來關閉Mariadb的服務。

• 第四台資料庫節點執行啟動
  
  systemctl start mariadb

• 第四台資料庫節點確認結果，執行：
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_ready
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_cluster_size
  
  

• 第四台資料庫節點畫面上要看到如下：
  wsrep_ready     ON
  wsrep_cluster_size      4
  
  註：如果發生沒有辦法啟動，肯定是背景中還有Mariadb的服務沒有關閉，可以執行：netstat -ntlp，查出mariadbd的 process id，然後執行kill -9 id號碼來關閉Mariadb的服務。

• 回到第一台資料庫節點，修改 /etc/my.cnf.d/server.cnf檔案：
  調整為 wsrep_cluster_address='gcomm://所有其他節點的IP以逗號隔開'
  調整好之後，已不需要再重啟服務。

- 完成  -

MariaDB 歲修保養維護 - 模式一：資料庫叢集服務不停止

很重要! 請先參照備份與還原章節實施備份，再繼續往下。
尤其是選擇要將叢集成員全部停機的歲修保養方式

如果一定要將叢集成員全部停機亦可，不過非常不推薦，除非遭遇到不可抗力之因素。

以下假設由 4 台 MariaDB 組成了  Galery Cluster

相對而言，服務不停止情況下的作業方式為最簡單，

原則：最晚加入群集的節點為最優先關機進行歲修保養。

方法：分辨出最早(領頭羊)與最晚的群集內節點，那要如何找出來呢?

查找資料庫叢集各台成員的 /var/log/mariadb/mariadb.log 檔案內容尾部(注意:是內容的尾部)，

參考以下示意圖：

… (略) …

View:

  id: 1c06ce49-bcd3-11ec-b14e-8b8dee207a31:1172

  status: primary

  protocol_version: 4

  capabilities: MULTI-MASTER, CERTIFICATION, PARALLEL_APPLYING, REPLAY, ISOLATION, PAUSE, CAUSAL_READ, INCREMENTAL_WS, UNORDERED, PREORDERED, STREAMING, NBO

  final: no

  own_index: 1

  members(3):

        0: 07b735c5-c5f1-11ec-960f-dfe621728932, node3

        1: ce7be80b-c5f0-11ec-97f3-633bd2a0f1e8, node2

        2: f3284315-c633-11ec-8919-96b52b18760a, node1

        3: 01b775c5-c5f1-12ec-ab0f-dfe621246932c, node4

… (略) …

從 LOG 內容得知：


示意圖內的Node3 可被視為領頭羊，領頭羊節點是機器之間投票是推選出來的，不是開機愈久就是領頭羊。示意圖內的Node4可被視為最晚加入，成為叢集成員身份的時間最短。

以下敘述先以Node4做為歲修保養對象：

• 至Node4資料庫節點上，正式關閉MariaDB服務指令是：
  
  systemctl stop mariadb

• 將Node4資料庫節點關機進行歲修或保養等其他。

• 完成後將Node4資料庫節點開機

• 確認Node4資料庫節點有是否成功加入MariaDB Galera叢集內，執行：
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_ready
  
  
  
• Node 4資料庫節點畫面上要看到如下：
  
  wsrep_ready     ON
  
  如果無法得到以上資訊，表示沒有啟動成功。

• 嘗試Node4資料庫節點，執行：
  
  mysql -uroot -p1qaz2wsx -e "SHOW STATUS LIKE 'wsrep%';" | grep wsrep_cluster_size
  
  Node 4資料庫節點畫面上要看到如下：
  
  wsrep_cluster_size      4
  
  如果無法得到以上資訊，表示沒有啟動成功，檢查Node4資料庫節點
  查看/etc/my.cnf.d/server.cnf檔案內容的 wsrep_cluster_address='gcomm://….'。
  
  其IP順序不能指向自己，必須要指向正在運行的其他資料庫節點。

• 在Node4資料庫節點成功重新加入叢集之後，依此類推：Node1 → Node2 → Node 3，逐步完成資料庫節點歲修保養。

MariaDB 資料庫叢集的保護機制

 (原文：https://galeracluster.com/2016/11/introducing-the-safe-to-bootstrap-feature-in-galera-cluster )

資料庫叢集MariaDB Galera Cluster 的設計是朝服務啟動之後就永不停止，在平時的運作上不需要關閉整座叢集。然而實際運維過程上有可能遭遇到意外，例如被無預警斷網、停電等等。因此為了因應各種無預警狀況，導入了一項被稱為【Safe-To-Bootstrap】的管制機制。

其原理是當一個健康叢集所有成員(資料庫節點)均處於服務運作狀態時，每一台節點的【Safe-To-Bootstrap】值被設置為0，而健康叢集運行過程會推選出領頭羊(Primary) 節點，只有按順序將領頭羊節點留在最後一台關機者，該領頭羊的【Safe-To-Bootstrap】才會被設置為1。而被設置為1者，並且在所有節點重新復原啟動過程中，【還必須】是第一台開機啟動者，這樣叢集才能夠自動的恢復起來。

在此引用名詞【柵欄】形容用來阻擋資料庫成員脫離了MariaDB Galera Cluster後獨自對外提供服務，導致發生比災難更大的災難。也就是資料庫發生腦裂現象（split-brain）。資料被打散個別儲存於MariaDB Galera Cluster之內與外，嚴重程度到無法重新復原。為阻止此現象，透過【柵欄】設計，阻擋資料庫服務節點於不正常關閉停止後服務又被自動啟動，如此降低發生腦裂現象風險。

而這樣的刻意設計安排，目的是希望經由人員介入判斷後再排除障礙使其恢復MariaDB Galera Cluster服務。現實中有很高的機率在搶時間恢復服務壓力下，直接啟動所有的資料庫節點服務。而這樣的行為，如果不阻擋很容易演變人為介入的資料庫腦裂現象。而這就常演變為服務中斷時間愈來愈久。

MariaDB 資料庫備份與還原

一、MariaDB資料庫資料備份

由於資料會依據使用量逐漸擴增，目錄空間是需要額外考量的課題。
請事先安排好備份資料的目錄，不要占用到CENTOS作業系統的空間而導致系統不穩定。資料備份命令如下：

mysqldump --single-transaction  --quick  -u$u -p$pwd  omnistore  > $target  &&  gzip $target

註(1)：$u 與 $pwd 分別代入 root、1qaz2wsx，請依需求自行變更。
註(2)：$target 代入路徑與檔名，例如 /tmp/backup.sql，請依需求自行變更。
註(3)：上述命令會將備份資料ZIP壓縮起來，請依需求自行變更。
註(4)：盡可能安排於離峰時間進行資料庫備份作業

二、 MariaDB資料庫資料還原

建議要還原資料之前，MariaDB Galera Cluster 均已經建立好。在第一台節點上
執行資料還原命令如下：

mysql -u$u -p$pwd  omnistore  < $target

註(1)：$u 與 $pwd 分別代入 root、1qaz2wsx，請依需求自行變更。
註(2)：$target 代入路徑與檔名，例如 /tmp/backup.sql，請依需求自行變更。

三、 透過第三方軟體進行備份

可參考官網推薦的 mydump 工具
https://mariadb.com/kb/en/mariadb-backups-overview-for-sql-server-users/

安裝 MariaDB

嗯.... 因工作因素，經常要安裝 MariaDB，整理以下常用資訊

MariaDB 版本 10.x.x

安裝：

可以先到這裡決定好要下載自己喜歡的平台版本

我個人習慣都是在 CentOS上，因為企業客戶大都受限於資安法規因素，選擇上偏向於合規居多。

https://mariadb.org/download/?t=repo-config

不知道攻城獅是否注意到 台灣有新增一個 MIRROR SITE 了，速度很快

tw1.mirror.blendbyte.net

大部分SE工程師不太在意，但是如果要常常製作 OFF-LINE TAR 安裝包去客戶端安裝的人

沒遇過客戶端不能連接INTERNET 的 SE 攻城獅 算是很幸福的!

我個人的安裝習慣是

yum install -y MariaDB-server MariaDB-common MariaDB-backup MariaDB-client

啟動參數：

以下也是我個人的習慣

先從第一台資料庫節點開始設定，執行以下命令：

cp /etc/my.cnf.d/server.cnf  /etc/my.cnf.d/server.cnf.bak

編輯vi /etc/my.cnf.d/server.cnf

找到 [mysqld] 以後，加入以下：

#datadir=/var/lib/mysql            #保留日後使用

#socket=/var/lib/mysql/mysql.sock   #保留日後使用

#pid-file=/run/mariadb/mariadb.pid  #保留日後使用

# query_cache_type=0/1/DEMAND   #保留日後使用

query_cache_type=DEMAND

query_cache_size=8864000

log-error=/var/log/mariadb/mariadb.log

slow_query_log_file=/var/log/mariadb/slow-mariadb.log

long_query_time=2

bind-address=0.0.0.0

lower_case_table_names=1

collation-server=utf8mb4_unicode_ci

init-connect='SET NAMES utf8mb4'

character-set-server=utf8mb4

skip-name-resolve

max_connections=819200        # 開最大讓系統會動態自行調節

max_connect_errors=1000

max_allowed_packet=4096M

connect_timeout=15

innodb_buffer_pool_size=8G

innodb_buffer_pool_instances=16

innodb_buffer_pool_chunk_size=128M

innodb_fast_shutdown=0

存檔後、執行以下命令啟動MariaDB資料庫：

mkdir -p /var/log/mariadb/

touch /var/log/mariadb/mariadb.log

touch /var/log/mysqld.log

touch /var/run/mysqld.pid

chmod 666 /var/log/mysqld.log

chmod 666 /var/run/mysqld.pid

chown -R mysql:mysql /var/log/mariadb

systemctl disable firewalld; systemctl stop firewalld

systemctl enable mariadb

systemctl restart mariadb

systemctl status -l mariadb

確認Mariadb LOG 檔案紀錄狀態結果：

cat /var/log/mariadb/mariadb.log

設定資料庫 root 帳號的登入密碼，假設密碼為 1qaz2wsx

mysql -h localhost -u root

FLUSH PRIVILEGES;

ALTER USER 'root'@'%' IDENTIFIED BY '1qaz2wsx';

ALTER USER 'root'@'localhost' IDENTIFIED BY '1qaz2wsx';

FLUSH PRIVILEGES;

SHOW GRANTS;

exit

將資料庫設定開放 root 連線，執行以下命令：

mysql -h localhost -u root

FLUSH PRIVILEGES;

GRANT ALL ON *.* TO 'root'@'%' IDENTIFIED BY '1qaz2wsx' WITH GRANT OPTION;

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '1qaz2wsx' WITH GRANT OPTION;

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost.localdomain' IDENTIFIED BY '1qaz2wsx' WITH GRANT OPTION;

FLUSH PRIVILEGES;

exit

確定第一台資料庫服務正確啟動之後，其他資料庫節點仿照上述步驟逐一完成相關設定與啟動。