Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/linux/28.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Linux 使用MDEV-17458将galera群集更新为10.3.15_Linux_Mariadb_Cluster Computing_Galera - Fatal编程技术网

Linux 使用MDEV-17458将galera群集更新为10.3.15

Linux 使用MDEV-17458将galera群集更新为10.3.15,linux,mariadb,cluster-computing,galera,Linux,Mariadb,Cluster Computing,Galera,我刚刚将mariadb/galera集群更新为db版本10.3.15。如果没有至少两个节点,它将无法正常工作,但尝试启动任何超过第一个节点时会出现奇怪的错误消息,如: 0 [Warning] WSREP: SST position can't be set in past. Requested: 0, Current: 14422308. 0 [Warning] WSREP: Can't continue. 此错误可能与以下内容有关: 但是,我注意到一个特性:请求的状态是0,很可能是因为它

我刚刚将mariadb/galera集群更新为db版本10.3.15。如果没有至少两个节点,它将无法正常工作,但尝试启动任何超过第一个节点时会出现奇怪的错误消息,如:

0 [Warning] WSREP: SST position can't be set in past. Requested: 0, Current:  14422308.
0 [Warning] WSREP: Can't continue.
此错误可能与以下内容有关:

但是,我注意到一个特性:请求的状态是
0
,很可能是因为它在过程中丢失了,或者是因为我遇到了一个完全不同的问题

我也知道它应该是什么:它认为是“当前”的值。 换句话说,现实与该节点所认为的恰恰相反:“当前”应该是
0
,“请求”应该是
14422308

在相关问题中:

有人直接评论说删除一些文件是为了从一个原始的案例开始,但不清楚具体在哪里做什么

我不介意从一个节点上的数据开始,忽略其他节点上的所有内容并复制所有内容

我尝试从有问题的节点中删除以下文件。(我相信他们提到的数据目录在大多数linux系统上都是
/var/lib/mysql/
):

这没有效果

有人问了这个问题:建议更改节点上的SST编号,这样仍然可以。但这是行不通的:我只能在使用“galera_new_cluster”脚本的情况下启动该节点,该脚本将其SST编号重置为“-1”,无论它是什么。如果我正常启动,会出现如下错误:

[ERROR] WSREP: wsrep::connect(gcomm://<IP1>,<IP2>,<IP3>,...) failed: 7
[ERROR]WSREP:WSREP::connect(gcomm://、、…)失败:7
换句话说,没有足够的其他节点在线加入集群。因此,为了更改主节点上的SST,另一个节点需要联机,但为了启动另一个节点,我需要更改主节点上的SST?第二十二条军规,行不通

他们修复了这个bug,这很好,但是我如何修复我现在坏掉的集群呢


我问自己的另一个问题是:14422308的“SST编号”是来自尝试重新加入集群的节点,还是从集群中检索到的?显然,第二件事是正确的,因为即使从零开始完全重新安装辅助节点并尝试使用它重新加入集群也无法解决问题。完全相同的错误消息仍然存在

不知何故,集群似乎对自己的状态感到困惑。每个同步步骤中的
JOINER
节点认为它们的状态比
施主节点更高级

解决这个问题的办法是欺骗集群;强制它将某个节点识别为“更高级”

假设我们可以识别一个具有完整集群数据的节点。表示这是“第一个节点”。选择一个节点作为第二个节点,选择一个节点作为第三个节点,等等(这些选择可以是随机的)

然后,在所有节点上停止mysql。编辑群集的配置文件,并更改每个节点上“wsrep_cluster_address”的值。它应该是以下内容:

+------+---------------------------+
| Node |   wsrep_cluster_address   |
+------+---------------------------+
|    1 | gcomm://                  |
|    2 | gcomm://<IP1>,<IP2>       |
|    3 | gcomm://<IP1>,<IP2>,<IP3> |
+------+---------------------------+
位于mysql安装的数据目录中。(例如,debian系统上的
/var/lib/mysql/

然后编辑节点#1上的“grastate.dat”文件。在我们的示例中,集群目前看到的最高级状态是
14422308
。因此,将其设置为
14422309
(或:旧状态+1)。另外,在所有节点上将
safe\u设置为\u bootstrap
设置为
0
(这样我们就不会意外地尝试引导并丢失
seqno
,再次遇到相同的错误)

现在在节点1上启动mysql(例如,通过systemd:
systemctl启动mysql
)。 一旦它运行,在节点2上执行同样的操作。等待传输所有数据(这可能需要一段时间,具体取决于节点间连接速度和相关数据库的大小),然后对节点3和任何其他节点重复此操作

然后,将每个配置中的
wsrep_cluster_address
的值恢复为它应该的值(等于最后一个节点的值)

+------+---------------------------+
| Node |   wsrep_cluster_address   |
+------+---------------------------+
|    1 | gcomm://                  |
|    2 | gcomm://<IP1>,<IP2>       |
|    3 | gcomm://<IP1>,<IP2>,<IP3> |
+------+---------------------------+
ib_logfile*
grastate.dat
gvwstate.dat
galera.cache