基于ldd2.34的系统环境部署GreatSQL Shell 异常

请先参考这个旧帖子 https://greatsql.cn/thread-815-1-1.html 。

yejr 发表于 2026-6-17 15:32
请先参考这个旧帖子 https://greatsql.cn/thread-815-1-1.html 。

docker方式有点繁琐，自己编辑ldd2.34的是否可以解决这个问题？另外，如果不用仲裁节点功能，直接采用mysql原生的shell是否对稳定性有影响，因为我用原生shell搭建集群后，在集群异常情况做集群恢复，会出现很多被拒绝的信息，比如删除元数据，这个命令在mysql-innodb原生集群中，不会出现这种情况。

无法删除元数据

请问：采用 mysql原生的shell 接管3节点的MGR集群，是否存在兼容性问题，比如某些命令失效的现象

yejr 发表于 2026-6-17 15:32
请先参考这个旧帖子 https://greatsql.cn/thread-815-1-1.html 。

docker方式有点繁琐，自己编辑ldd2.34的是否可以解决这个问题？另外，如果不用仲裁节点功能，直接采用mysql原生的shell是否对稳定性有影响，因为我用原生shell搭建集群后，在集群异常情况做集群恢复，会出现很多被拒绝的信息，比如删除元数据，这个命令在mysql-innodb原生集群中，不会出现这种情况

土豆 发表于 2026-6-17 16:13
docker方式有点繁琐，自己编辑ldd2.34的是否可以解决这个问题？另外，如果不用仲裁节点功能，直接采用mys ...

如果不用仲裁节点，则可以用原生mysql shell工具。
自己编译过程比较费劲，不太建议，如果有耐心可以试试看。

Segmentation fault (core dumped)（段错误）表明程序访问了非法的内存地址，从而被操作系统强制终止。
在 glibc 2.34 和 Python 环境下，glibc 版本兼容性和 Python 版本均不是导致此问题的原因（2.34 完全满足 2.28 的要求，且 Python 是 Shell 内置或动态加载，不会在启动瞬间引发崩溃）。
既然你之前用同样的环境部署成功过，说明问题很可能出在系统环境发生了局部变更或安装包解压传输过程中出现了损坏。
既然你之前能跑通，建议你优先重新下载该压缩包并重新解压，大概率是文件损坏或传输问题；如果依然报错，请使用 strace 命令贴出崩溃前的最后 10 行输出，即可迅速定位根因。