安裝好 Docker 之後，執行避免每次執行都要 sudo
盤點 group 是否已經存在:
sudo cat /etc/group | grep docker
如果 group 不存在就執行以下：
sudo groupadd docker
sudo usermod -aG docker ${USER}
sudo chmod a+rw /var/run/docker.sock
= 文件尾 =
2025年4月19日 星期六
2023年9月9日 星期六
2023年9月8日 星期五
2022年6月19日 星期日
考核的當下我感覺我不是面對考核官員，而是面對著十幾年前的我
自己是沒有定期更新內容的習慣..... 但這陣子因為工作上的因素，想了想也跟 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
2022年6月5日 星期日
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可被視為最晚加入，成為叢集成員身份的時間最短。
示意圖內的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服務。現實中有很高的機率在搶時間恢復服務壓力下，直接啟動所有的資料庫節點服務。而這樣的行為，如果不阻擋很容易演變人為介入的資料庫腦裂現象。而這就常演變為服務中斷時間愈來愈久。
訂閱：
文章 (Atom)