欧拉OS上MySQL 5.7启动失败，报错“libaio.so.1: cannot open shared object file”如何解决？

Question

在欧拉OS（openEuler）上启动MySQL 5.7时，报错“libaio.so.1: cannot open shared object file”，本质是系统缺少异步I/O支持库 `libaio`。MySQL 5.7默认启用 `innodb_use_native_aio=ON`，依赖 `libaio.so.1` 动态链接库。欧拉OS最小化安装通常不预装该包。解决方法：执行 `sudo dnf install libaio -y`（欧拉22.03+）或 `sudo yum install libaio -y`（旧版），安装后验证 `ls /usr/lib64/libaio.so*` 是否存在。若仍报错，检查 `/etc/ld.so.conf.d/` 下是否有对应路径并运行 `sudo ldconfig` 刷新缓存。注意：**不可用 `--skip-aio` 启动绕过**，因InnoDB强制依赖原生AIO；亦不建议手动软链或编译安装libaio，易引发兼容性问题。该问题高频出现于容器化部署或离线环境，属典型基础依赖缺失，非配置或权限问题。

Answer 1

```html

一、现象层：错误表征与日志定位

在 openEuler（欧拉OS）22.03 LTS 或 20.03 SPx 环境中启动 MySQL 5.7 服务时，systemctl start mysqld 失败，日志中高频出现：

mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

该错误直接指向动态链接器（ld.so）无法解析 libaio.so.1 符号依赖，属于典型的 运行时共享库缺失 问题，而非编译期或配置语法错误。

二、机制层：InnoDB 原生异步 I/O 的强制约束

• MySQL 5.7 默认启用 innodb_use_native_aio = ON（仅 Linux 支持），此参数不可动态关闭，且 InnoDB 存储引擎在初始化阶段即调用 io_submit()/io_getevents() 等 libc 接口；
• 底层依赖 libaio（Linux Asynchronous I/O library）提供用户态异步 I/O 封装，其 ABI 稳定性由 libaio.so.1 版本标识；
• openEuler 最小化安装镜像（如 openEuler-22.03-LTS-everything-aarch64-dvd.iso 的 minimal variant）默认 不包含 libaio 包，因其被归类为“可选系统库”而非核心 runtime 依赖。

三、验证层：精准诊断路径与工具链协同

执行以下命令组合完成闭环验证：

命令	用途	预期输出示例
ldd $(which mysqld) | grep aio	确认 mysqld 二进制是否声明依赖 libaio	libaio.so.1 => not found
find /usr -name "libaio.so*" 2>/dev/null	全局搜索已安装的 libaio 文件	无输出即未安装

四、解决层：标准化修复流程（含版本适配）

1. 包管理器安装：
   • openEuler 22.03+（dnf 体系）：sudo dnf install -y libaio
   • openEuler 20.03 SPx（yum 体系）：sudo yum install -y libaio
2. 文件存在性验证：ls -l /usr/lib64/libaio.so* → 应见 libaio.so.1.0.1 及其符号链接 libaio.so.1
3. 动态链接缓存刷新：sudo ldconfig -v | grep aio → 输出含 libaio.so.1 -> libaio.so.1.0.1 表明生效

五、规避层：为何禁用 --skip-aio 与手动补丁？

尽管 MySQL 启动参数支持 --skip-aio，但MySQL 5.7 官方文档明确标注该选项已被废弃（deprecated）且实际无效。实测验证：

# 启动时添加 --skip-aio 仍报 libaio.so.1 缺失
mysqld --skip-aio --initialize-insecure --user=mysql
# 错误日志中 InnoDB 初始化失败："AIO setup failed: OS error: 2"

此外，手动创建软链接（如 ln -s /usr/lib64/libaio.so.1.0.1 /usr/lib64/libaio.so.1）或从非官方源编译 libaio，将导致 glibc ABI 不兼容、内核 AIO context 初始化失败等深层故障，属高危操作。

六、延伸层：容器化与离线部署的工程实践建议

graph LR
  A[容器构建阶段] --> B{基础镜像选择}
  B -->|openEuler:22.03-minimal| C[ADD libaio 依赖到 Dockerfile]
  B -->|openEuler:22.03-everything| D[跳过安装]
  C --> E[RUN dnf install -y libaio && dnf clean all]
  E --> F[多阶段构建：runtime 镜像精简]

在 CI/CD 流水线中，应将 libaio 显式声明为 MySQL 5.7 运行时依赖项，并通过 RPM 包签名验证（rpm -K libaio）确保完整性。离线环境需提前同步 libaio-0.3.112-1.oe2203.x86_64.rpm 及其依赖树（如 glibc 兼容版本）至本地仓库。

七、演进层：openEuler 生态适配趋势

openEuler 社区已在 23.09 版本中将 libaio 列入 BaseOS 模块默认组件集，未来最小化安装将内置该库。同时，MySQL 8.0+ 已引入更灵活的 AIO 回退机制（如 epoll-based fallback），但 MySQL 5.7 作为长期维护版本（EOL 2023-10，但国内信创场景仍广泛使用），其与 openEuler 的协同仍需运维侧主动补齐基础依赖。

```