以下是場景，必須在 3 節點叢集中對 Mariadb 進行配置變更。我編輯了配置文件，並使用以下命令關閉節點：
# service mysqld stop
在其他 2 個節點上進行變更並執行相同的操作。當我啟動最高階的節點時
# galera_new_cluster
開始正常
在net節點上啟動，啟動ok。最後一個節點是我進行更改的第一個節點。
該節點不啟動。它遇到服務啟動逾時並終止。我在故障節點或主節點上找不到任何錯誤。我確實將超時從預設的 90 秒調整為 2 小時，但還是超時了。
只是尋找一些關於可能發生的事情的線索。
現在 galera 配置失敗：
[galera]
# Mandatory settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=192.168.10.238
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.10.200,192.168.10.201"
## Galera Cluster Configuration
wsrep_cluster_name="Cluster1"
## Galera Synchronization Configuration
wsrep_sst_method=rsync
## Galera Node Configuration
wsrep_node_address="192.168.10.238"
wsrep_node_name="db3"
啟動逾時訊息：
# service mysql start
Starting mysql (via systemctl): Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[FAILED]
在主節點上，我看到最後一個節點成功加入叢集：
2018-03-13 9:08:36 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') connection established to ce802915 tcp://192.168.10.238:4567
2018-03-13 9:08:36 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers:
2018-03-13 9:08:36 140261636175616 [Note] WSREP: declaring 8ee7874f at tcp://192.168.10.201:4567 stable
2018-03-13 9:08:36 140261636175616 [Note] WSREP: declaring ce802915 at tcp://192.168.10.238:4567 stable
2018-03-13 9:08:36 140261636175616 [Note] WSREP: Node 050b87ee state prim
2018-03-13 9:08:36 140261636175616 [Note] WSREP: view(view_id(PRIM,050b87ee,87) memb {
050b87ee,0
8ee7874f,0
ce802915,0
} joined {
} left {
} partitioned {
})
2018-03-13 9:08:36 140261636175616 [Note] WSREP: save pc into disk
2018-03-13 9:08:36 140261627782912 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 3
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE_EXCHANGE: sent state UUID: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: sent state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 0 (b1)
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 1 (db2)
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 2 (db3)
2018-03-13 9:08:36 140261627782912 [Note] WSREP: Quorum results:
version = 4,
component = PRIMARY,
conf_id = 20,
members = 2/3 (joined/total),
act_id = 3166274,
last_appl. = 3166245,
protocols = 0/7/3 (gcs/repl/appl),
group UUID = 4687a061-0310-11e8-a49f-534404044853
2018-03-13 9:08:36 140261627782912 [Note] WSREP: Flow-control interval: [28, 28]
2018-03-13 9:08:36 140261627782912 [Note] WSREP: Trying to continue unpaused monitor
2018-03-13 9:08:36 140261931068160 [Note] WSREP: New cluster view: global state: 4687a061-0310-11e8-a49f-534404044853:3166274, view# 21: Primary, number of nodes: 3, my index: 0, protocol version 3
2018-03-13 9:08:36 140261931068160 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-03-13 9:08:36 140261931068160 [Note] WSREP: REPL Protocols: 7 (3, 2)
2018-03-13 9:08:36 140261931068160 [Note] WSREP: Assign initial position for certification: 3166274, protocol version: 3
2018-03-13 9:08:36 140261686085376 [Note] WSREP: Service thread queue flushed.
2018-03-13 9:08:39 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') turning message relay requesting off
當 Mariadb 嘗試在故障主機上啟動時，我沒有看到任何錯誤：
Mar 13 09:11:43 pn09 systemd: Starting MariaDB 10.1.30 database server...
Mar 13 09:11:49 pn09 sh: WSREP: Recovered position 4687a061-0310-11e8-a49f-534404044853:2564462
Mar 13 09:11:49 pn09 mysqld: 2018-03-13 9:11:49 122545243265280 [Note] /usr/sbin/mysqld (mysqld 10.1.30-MariaDB) starting as process 7558 ...
Mar 13 09:11:50 pn09 rsyncd[7667]: rsyncd version 3.0.9 starting, listening on port 4444
我對此有點不知所措，任何方向都值得讚賞。我不清楚為什麼在這樣的單一節點上停止和啟動服務會出現問題。另外 2 個我可以毫無問題地上下移動。
值得注意的一點是，在深入研究這一點時，我注意到所有 3 個節點在 grastate.dat 檔案中的 SEQNO 設定為 -1。不知道為什麼會發生這種情況，如果這是一個關鍵問題或什麼。
其他有趣的地方 - 一些後台進程在服務啟動失敗後仍然運行：
# ps aux |grep mysql
mysql 7558 0.2 0.3 349912 57920 ? Ssl 09:11 0:00 /usr/sbin/mysqld --wsrep_start_position=4687a061-0310-11e8-a49f-534404044853:2564462
mysql 7567 1.2 0.0 113388 1796 ? S 09:11 0:03 /bin/bash -ue /usr//bin/wsrep_sst_rsync --role joiner --address 192.168.10.238 --datadir /var/lib/mysql/ --parent 7558
mysql 7667 0.0 0.0 114652 1068 ? S 09:11 0:00 rsync --daemon --no-detach --port 4444 --config /var/lib/mysql//rsync_sst.conf