Galera Cluster 2 节点 - 无法在节点 1 上重新启动 MySQL 服务器

Question

我遇到了这个问题，类似于这个： Unable to restart MySQL server 但我不确定如何继续，所以我向社区询问，尤其是在 Galera Cluster 上比我更有经验的人。 我试着总结一下：

配置：

Galera Cluster 2 节点 - 每个节点都是 Ubuntu 16.04 并具有 Mariadb 10.2.17 版本。

问题：

其中一个节点 (node1) 出现故障，遗憾的是没有配置错误日志或通用日志，但在 journalctl 上我可以看到错误类似于“文件中的 mariadb innodb 断言失败”，建议尝试 innodb_force_recovery（1 到 6），但我不知道 Galera 同步是如何工作的，或者它是否是活动\活动配置，所以我没有信心最终启动一个不同步的节点，因为这几天冒着脑裂的风险。另外，我在 datadir 上看到一个名为“sst_in_progress”的文件存在。

考虑：

最终删除故障节点上的datadir并重启mysql服务就可以了吗？是否足以使其开始与复制数据的节点 2 同步，而无需接触当前正在向客户端提供服务的节点 2 上的数据？ 此外，据我了解 Galera 集群不会复制系统表，所以我应该从 node2 导出 mysql.user 表并在 node1 上导入以恢复所有用户和权限。 谢谢，希望我能成功解释这个问题，如果不清楚，请告诉我。

Answer 1

文件sst_in_progress 表示损坏的节点请求了SST（状态快照传输），这基本上是从集群中的其他节点传输的完整数据。您可以使用几种不同的 SST 方法，您可以通过检查 wsrep_sst_method 变量来查看您启用了哪一种。需要注意的重要一点是，捐助者和加入者节点必须使用相同的 SST 方法。有关不同 SST 方法和一般 SST 的更多信息，我推荐mariadb documentation

SST 应该能够将损坏的节点重新加入集群。您可以在 mysql 错误日志中看到 SST 的进度。但是，由于您没有配置，您可以改为检查节点上的 wsrep 状态（例如show global status like '%wsrep%;'）。您可以通过检查wsrep_local_state_comment 查看节点状态。如果健康节点正在向损坏节点传输 SST，您将看到 wsrep_local_state_comment 的值为 Donor/Desynced。有关各种 wsrep 变量的更多详细信息，请参阅in the Galera documentation

如果自动 SST 出现问题，您可以改为执行手动 SST。对于 Mariadb 10.1 或更高版本，建议为此使用 Mariabackup。您可以找到有关使用 Mariabackup in the Mariadb documentation 进行手动 SST 的信息。

回答您有关删除损坏节点上的 datadir 并重新启动 MySQL 服务的问题：这将强制损坏的节点从另一个节点请求 SST。请注意，启动 MySQL 服务可能会超时，因为根据数据目录的大小，此过程可能需要很长时间。

SST 还会将系统表转移到损坏的节点，所以在 SST 完成后，mysql.user 表应该是完整的用户和权限，您不需要重新创建它们。

作为一个侧面观察，我看到您使用的是 2 节点 Galera 集群。一般来说，建议至少使用 3 个节点。如果您正在操作 2 节点 Galera 集群，您可能需要使用 Galera 仲裁器。有关更多信息，请参阅Galera documentation