使用 MDEV-17458 将 galera-cluster 更新到 10.3.15
Updating a galera-cluster to 10.3.15 with MDEV-17458
我刚刚将 mariadb/galera-cluster 更新到数据库版本 10.3.15。如果没有至少 2 个节点，它将无法正常工作，但是尝试启动第一个节点之后的任何节点都会遇到奇怪的错误消息，例如：。
0 [Warning] WSREP: SST position can't be set in past. Requested: 0, Current: 14422308.
0 [Warning] WSREP: Can't continue.
这个错误可能是相关的：
https://jira.mariadb.org/browse/MDEV-17458?attachmentViewMode=list
但是，我注意到一个特点：请求的状态是 0，很可能是因为它在途中某处丢失了，或者因为我遇到了一个完全不同的问题。
我也知道它应该是什么：它认为的值是'current'。
换句话说，现实与这个节点认为的完全相反：'current'应该是0，'requested'应该是14422308。
在相关问题中：
https://jira.mariadb.org/browse/MDEV-19193
有人对删除一些文件以便从原始案例开始进行临时评论，但并不完全清楚到底要做什么。
我不介意从一个节点上的数据开始，忽略其他节点上的所有内容并将所有内容复制过来。
我尝试从有问题的节点中删除以下文件。 （我相信他们提到的数据目录在大多数 linux 系统上是 /var/lib/mysql/）：
galera.cache
ib_logfile0
ib_logfile1
这没有效果。
有人回答这个问题：Unable to complete SST transfer due to "WSREP: SST position can't be set in past." error 建议更改仍然可以的节点上的 SST 编号。但这行不通：如果我使用 'galera_new_cluster' 脚本，我只能启动该节点，无论它是什么，该脚本都会将其 SST 编号重置为“-1”。如果我正常启动它，我会得到这样的错误：
[ERROR] WSREP: wsrep::connect(gcomm://<IP1>,<IP2>,<IP3>,...) failed: 7
换句话说，没有足够的在线节点加入集群。那么为了改变主节点上的SST，另一个节点需要在线，但是为了启动另一个节点，我需要改变主节点上的SST？第 22 条军规，行不通。
很高兴他们修复了这个错误，但我该如何修复我现在损坏的集群？
我问自己的另一个问题是：这个 'SST number' of 14422308 是来自试图重新加入集群的节点，还是从集群中检索到的？显然，第二件事是正确的，因为即使从头开始完全重新安装辅助节点并尝试用它重新加入集群也不能解决问题。保留完全相同的错误消息。
不知何故，集群似乎对自己的状态感到困惑。每个同步步骤中的 JOINER 个节点认为它们比 DONOR 个节点具有更高级的状态。
这个问题的解决办法就是欺骗集群；强制它将某个节点识别为 'more advanced'。
假设我们可以识别出一个拥有完整集群数据的节点。将其表示为“第一个节点”。选择一个节点作为第二个节点，一个节点作为第三个节点，依此类推（这些选择可以是随机的）。
然后，在所有节点上停止 mysql。编辑集群的配置文件并更改每个节点上 '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
位于 mysql 安装的数据目录中。 （示例；/var/lib/mysql/ 在 debian 系统上）。
然后编辑节点 #1 上的 "grastate.dat" 文件。在我们的示例中，集群尚未看到的最高级状态是 14422308。因此将其设置为 14422309（或：旧状态 + 1）。同时在所有节点上将 safe_to_bootstrap 设置为 0（这样我们就不会不小心尝试 bootstrap 并再次将我们的 seqno、运行 丢失到同一个错误中） .
现在在节点 #1 上启动 mysql（例如，通过 systemd：systemctl start mysql）。
一旦它是 运行，在节点 #2 上执行相同的操作。等待所有数据传输完毕（这可能需要一段时间，具体取决于节点间连接速度和相关数据库的大小），然后对节点 3 和任何其他节点重复此过程。
之后，将每个配置中 wsrep_cluster_address 的值恢复到应有的值（等于最后一个节点的值）。
我刚刚将 mariadb/galera-cluster 更新到数据库版本 10.3.15。如果没有至少 2 个节点，它将无法正常工作，但是尝试启动第一个节点之后的任何节点都会遇到奇怪的错误消息，例如：。
0 [Warning] WSREP: SST position can't be set in past. Requested: 0, Current: 14422308.
0 [Warning] WSREP: Can't continue.
这个错误可能是相关的：
https://jira.mariadb.org/browse/MDEV-17458?attachmentViewMode=list
但是，我注意到一个特点：请求的状态是 0，很可能是因为它在途中某处丢失了，或者因为我遇到了一个完全不同的问题。
我也知道它应该是什么：它认为的值是'current'。
换句话说，现实与这个节点认为的完全相反：'current'应该是0，'requested'应该是14422308。
在相关问题中：
https://jira.mariadb.org/browse/MDEV-19193
有人对删除一些文件以便从原始案例开始进行临时评论，但并不完全清楚到底要做什么。
我不介意从一个节点上的数据开始，忽略其他节点上的所有内容并将所有内容复制过来。
我尝试从有问题的节点中删除以下文件。 （我相信他们提到的数据目录在大多数 linux 系统上是 /var/lib/mysql/）：
galera.cache
ib_logfile0
ib_logfile1
这没有效果。
有人回答这个问题：Unable to complete SST transfer due to "WSREP: SST position can't be set in past." error 建议更改仍然可以的节点上的 SST 编号。但这行不通：如果我使用 'galera_new_cluster' 脚本，我只能启动该节点，无论它是什么，该脚本都会将其 SST 编号重置为“-1”。如果我正常启动它，我会得到这样的错误：
[ERROR] WSREP: wsrep::connect(gcomm://<IP1>,<IP2>,<IP3>,...) failed: 7
换句话说，没有足够的在线节点加入集群。那么为了改变主节点上的SST，另一个节点需要在线，但是为了启动另一个节点，我需要改变主节点上的SST？第 22 条军规，行不通。
很高兴他们修复了这个错误，但我该如何修复我现在损坏的集群？
我问自己的另一个问题是：这个 'SST number' of 14422308 是来自试图重新加入集群的节点，还是从集群中检索到的？显然，第二件事是正确的，因为即使从头开始完全重新安装辅助节点并尝试用它重新加入集群也不能解决问题。保留完全相同的错误消息。
不知何故，集群似乎对自己的状态感到困惑。每个同步步骤中的 JOINER 个节点认为它们比 DONOR 个节点具有更高级的状态。
这个问题的解决办法就是欺骗集群；强制它将某个节点识别为 'more advanced'。
假设我们可以识别出一个拥有完整集群数据的节点。将其表示为“第一个节点”。选择一个节点作为第二个节点，一个节点作为第三个节点，依此类推（这些选择可以是随机的）。
然后，在所有节点上停止 mysql。编辑集群的配置文件并更改每个节点上 '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
位于 mysql 安装的数据目录中。 （示例；/var/lib/mysql/ 在 debian 系统上）。
然后编辑节点 #1 上的 "grastate.dat" 文件。在我们的示例中，集群尚未看到的最高级状态是 14422308。因此将其设置为 14422309（或：旧状态 + 1）。同时在所有节点上将 safe_to_bootstrap 设置为 0（这样我们就不会不小心尝试 bootstrap 并再次将我们的 seqno、运行 丢失到同一个错误中） .
现在在节点 #1 上启动 mysql（例如，通过 systemd：systemctl start mysql）。
一旦它是 运行，在节点 #2 上执行相同的操作。等待所有数据传输完毕（这可能需要一段时间，具体取决于节点间连接速度和相关数据库的大小），然后对节点 3 和任何其他节点重复此过程。
之后，将每个配置中 wsrep_cluster_address 的值恢复到应有的值（等于最后一个节点的值）。