☰

mysql（Perconadb）Galera/Xtrabackup 集群加入失败，显示“参数无效”

tag-icon • tag-icon mysql galera percona-xtradb-cluster xtrabackup
mysql（Perconadb）Galera/Xtrabackup 集群加入失败，显示“参数无效”

我有一个 MySQL Galera 集群，使用 Perconadb 和 Xtrabackup。节点可以独立启动，或者如果只需要 IST，则可以加入集群。但是，如果需要 SST，则运行完成然后失败。

日志显示，xtrabackup SST 完成后，它会以统计信息 22（无效参数）退出，导致 SST 回滚并且节点无法启动。

2018-08-09 00:43:25 860 [Note] WSREP: 0.0 (xmdadb01): State transfer to 1.0 (xmdadb02) complete.
2018-08-09 00:43:25 860 [Note] WSREP: Member 0.0 (xmdadb01) synced with group.
2018-08-09 00:43:25 860 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup-v2 --role 'joiner' --address '10.93.40.122' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' --parent '860'  '' : 22 (Invalid argument)
2018-08-09 00:43:25 860 [ERROR] WSREP: Failed to read uuid:seqno from joiner script.
2018-08-09 00:43:25 860 [ERROR] WSREP: SST script aborted with error 22 (Invalid argument)
2018-08-09 00:43:25 860 [ERROR] WSREP: SST failed: 22 (Invalid argument)
2018-08-09 00:43:25 860 [ERROR] Aborting

my.cnf的相关部分：

[mysqld]
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_provider_options="gcache.size=256M;gcs.fc_factor=1.0;gcs.fc_limit=512;gcs.fc_master_slave=YES;pc.checksum=true;"
wsrep_cluster_name="galera01-xmd"
wsrep_cluster_address="gcomm://10.93.40.121:4567,10.93.40.122:4567"
wsrep_node_name=xmdadb02
wsrep_node_address="10.93.40.122"
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sst_user:password-goes-in-here

当 SST 运行时，我可以看到文件进入/var/lib/mysql/.sst，所以我知道这是有效的。我已验证用户和密码正确。但是，为什么 xtrabackup-v2 返回 22，我如何阻止它这样做以便 SST 完成？

令人恼火的是，首次安装此设置时，SST 运行正常。我不知道在此期间发生了什么变化，以阻止 SST，同时仍允许 IST 运行。

答案1

我发现 SST 失败的原因通常归结为以下之一：SElinux/AppArmor 正在强制执行、未在捐赠节点上创建 SST 用户（并且权限未在 .cnf 文件中正确更新）、IPTables/防火墙限制超过 4444。在大多数情况下，纠正这些问题可使 SST 正常工作。

答案2

因为 galera 对于什么构成有意义的错误消息有一个创造性的看法，所以不要指望 EINVAL 22 对应于系统调用返回代码。

看看代码在他们的代码中围绕这个 EINVAL 文本。

定影不是优先事项。

答案3

SST 和 IST 失败的原因有很多，其他发帖者也给出了一些原因；然而在我们的案例中，问题似乎在于 xtrabackup SST 脚本对 mysql.cnf 比对 MySQL 本身更挑剔，并且当解析器出现问题时会因此错误而失败。

在这种情况下，问题在于某些配置指令在文件中出现多次（尽管具有相同的值）。MySQL 顺利通过了此检查，但 xtrabackup 解析器将其转换为多值数组，这是一种无效的数据类型，因此它无法通过。

删除额外的重复配置行可以解决问题。

请注意，这只影响 xtrabackup SST - IST 一直运行良好，并且 MySQL 本身（加上 mysqldump 等）也非常正常。

答案4

尝试打开innobackupex日志，例如在 Debian 上它位于/var/lib/mysql/innobackup.backup.log

我发现我对捐赠者的问题是InnoDB: Error number 24 means 'Too many open files'.，所以ulimit -n会有所帮助:-)

编辑：发现还有另一行日志：xtrabackup: open files limit requested 200000, set to 1024 事实上，我已经使用过：

[xtrabackup]
open-files-limit = 200000

但是 MySQL 将其降低到 1024（或 5000），因此需要进行另一项调整：

[mysqld]
open-files-limit = 100000

（并删除其中[xtrabackup]无用的）

相关内容