pxc 三個節點全部異常和正常關閉的啟動順序

賀子_DBA時代發表於2020-03-23

mysql 5.7.27 pxc 三個節點全部異常和正常關閉的啟動順序:

1、正常關閉所有節點的時候因為不能生成gvwstate.dat,所以一定要保證第一個啟動的是包含最新資料的節點!

mysqld_safe --defaults-file=/etc/my.cnf --wsrep-recover來檢視最新的節點!

2、Server version: 5.7.27-30-57-log 這個版本中,如下修改後!剩餘一個節點也是可以提供服務的!

#wsrep_cluster_address = gcomm://10.9.21.179:4567,10.9.21.178:4567

wsrep_cluster_address = gcomm://

3.關於wsrep_cluster_address :

你啟動資料庫的時候,需要保證該引數中的一半以上的節點能連通,才能啟動,否則會報錯,所以如果有鑑證節點的話,最好把鑑證也加上!

wsrep_cluster_address = gcomm://10.9.21.179:4567,10.9.21.178:4567

報錯如下所示:

2020-03-23T04:55:26.861788Z 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1514: Failed to open channel 'LIUWENHE_CLUSTER' at 'gcomm://10.9.21.179:4567,10.9.21.178:4567': -110 (Connection timed out)

如果兩個資料節點+一個鑑證節點,如果正常關閉了這兩個資料節點,那麼再啟動的時候一定要去看看到底哪個節點是資料最新的,因為都是正常關閉的,所有沒有生成gvwstate.dat檔案,自然不能自動恢復(5.7.27-30-57)

1確定最新的節點:否則將會有資料丟失!

(如果你不是選擇的最新的啟動了,那麼當你嘗試啟動另一個資料節點(資料多的節點)的時候

會報錯說這個節點應用了更多的事務,而啟動失敗,具體如下:

2020-03-23T03:44:19.126386Z 0 [ERROR] WSREP: gcs/src/gcs_group.cpp:group_post_state_exchange():353: Reversing history: 12202 -> 12200, this member has applied 2 more events than the primary component.Data loss is possible. Aborting.

2020-03-23T03:44:19.126413Z 0 [Note] WSREP: /usr/sbin/mysqld: Terminated.)

[root@beijing-fuli-hadoop-01 ~]# mysqld_safe --defaults-file=/etc/my.cnf --wsrep-recover

2020-03-23T03:27:52.074550Z mysqld_safe Logging to '/data/logs/mysql/mysql_error.log'.

2020-03-23T03:27:52.078135Z mysqld_safe Logging to '/data/logs/mysql/mysql_error.log'.

2020-03-23T03:27:52.120280Z mysqld_safe Starting mysqld daemon with databases from /data/mysqldata

2020-03-23T03:27:52.134598Z mysqld_safe Skipping wsrep-recover for efca7e03-f55c-11e9-a230-5645b597da6b:12202 pair

2020-03-23T03:27:52.137112Z mysqld_safe Assigning efca7e03-f55c-11e9-a230-5645b597da6b:12202 to wsrep_start_position

2020-03-23T03:27:55.022957Z mysqld_safe mysqld from pid file /data/mysqldata/mysql.pid ended

2 修改/data/mysqldata/grastate.dat中的safe_to_bootstrap: 0改為1

# GALERA saved state

version: 2.1

uuid: efca7e03-f55c-11e9-a230-5645b597da6b

seqno: 12202

safe_to_bootstrap: 1

如果不改錯誤日誌中會有提示:

2020-03-22T06:28:43.728598Z 0 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

3 如果不能保證一半以上的節點是可連通的,那麼需要修改引數檔案配置,改為空的,具體如下,這樣修改之後一個節點也是可以提供服務的,記住只需要修改第一個啟動的節點的即可!

vi /etc/my.cnf

#wsrep_cluster_address = gcomm://10.9.21.179:4567,10.9.21.178:4567

wsrep_cluster_address = gcomm://

否則會報錯,無法open channel 10.9.21.178:4567,因為他是關閉的,但是如果你的引數設定的是

wsrep_cluster_address = gcomm://10.9.21.179:4567,10.9.21.178:4567,10.9.21.114:4567,這樣把鑑證節點也加上的話,如果鑑證節點服務是開啟的網路也沒問題,那就可以啟動了,就不需要修改了

具體報錯:

2020-03-23T04:55:26.861711Z 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view (pc.wait_prim_timeout): 110 (Connection timed out)

at gcomm/src/pc.cpp:connect():159

2020-03-23T04:55:26.861730Z 0 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():209: Failed to open backend connection: -110 (Connection timed out)

2020-03-23T04:55:26.861788Z 0 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1514: Failed to open channel 'LIUWENHE_CLUSTER' at 'gcomm://10.9.21.179:4567,10.9.21.178:4567': -110 (Connection timed out)

4 啟動即可!

/etc/init.d/mysql start

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29654823/viewspace-2682141/,如需轉載,請註明出處,否則將追究法律責任。

相關文章