如何在 Linux 中查看所有活动的网络连接？
2026/5/12 1:38:49
1. 报错现象与原因分析
最近在CentOS 8上安装MySQL 5.7时，遇到了一个典型的依赖问题。执行rpm -ivh mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm命令后，系统提示缺少libssl.so.10和libcrypto.so.10这两个关键库文件。这个报错看似简单，但背后其实隐藏着Linux系统版本兼容性的深层问题。
我刚开始也一头雾水，明明系统里已经安装了OpenSSL，为什么还会报错？后来发现，CentOS 8默认安装的是OpenSSL 1.1.1版本，而MySQL 5.7编译时依赖的是OpenSSL 1.0.2版本。这两个大版本之间存在ABI不兼容的问题，就像你拿着Windows的DLL文件想在Mac上运行一样，系统自然无法识别。
具体来说，libssl.so.10和libcrypto.so.10这两个库文件是OpenSSL 1.0.2系列的产物。在CentOS 8中，它们已经被libssl.so.1.1和libcrypto.so.1.1取代。虽然功能相似，但二进制接口已经改变，导致MySQL安装程序无法识别新版本的库文件。
2. 快速解决方案对比
遇到这个问题，通常有两种主流解决方案：强制安装和安装兼容库。我在实际工作中两种方法都尝试过，各有优缺点。
2.1 强制安装方案
最简单的办法是在rpm命令后加上--nodeps --force参数：
rpm -ivh --nodeps --force mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm这个方案的优势是简单快捷，不需要额外安装任何依赖。但缺点也很明显：它完全跳过了依赖检查，就像开车时无视所有红灯一样危险。我曾在测试环境用过这个方法，MySQL确实能跑起来，但后续遇到了不少奇怪的问题，比如某些加密功能异常，SSL连接不稳定等。
2.2 兼容库方案
更稳妥的做法是安装compat-openssl10兼容包：
rpm -ivh compat-openssl10-1.0.2o-3.el8.x86_64.rpm这个方案会在系统中同时保留新旧两个版本的OpenSSL库，MySQL使用1.0.2版本，其他程序继续使用1.1.1版本。我在生产环境采用的就是这个方法，运行一年多来非常稳定。
两种方案对比：
| 方案 | 操作复杂度 | 系统影响 | 稳定性 | 推荐场景 |
|---|---|---|---|---|
| 强制安装 | 简单 | 可能影响其他依赖 | 较低 | 临时测试环境 |
| 兼容库 | 中等 | 最小影响 | 高 | 生产环境 |
3. 详细解决步骤
3.1 准备工作
在开始之前，建议先检查系统当前的OpenSSL版本：
openssl version在CentOS 8上，通常会显示"OpenSSL 1.1.1g"。然后检查/usr/lib64/目录下的库文件：
ls -l /usr/lib64/libssl.so* /usr/lib64/libcrypto.so*你应该能看到类似这样的输出：
lrwxrwxrwx. 1 root root 19 Apr 7 2020 /usr/lib64/libcrypto.so -> libcrypto.so.1.1 lrwxrwxrwx. 1 root root 19 Apr 7 2020 /usr/lib64/libssl.so -> libssl.so.1.13.2 安装兼容库
首先需要获取compat-openssl10的rpm包。在CentOS 8中，可以直接从官方仓库安装：
dnf install compat-openssl10如果网络环境特殊，也可以手动下载rpm包后安装：
wget http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/compat-openssl10-1.0.2o-3.el8.x86_64.rpm rpm -ivh compat-openssl10-1.0.2o-3.el8.x86_64.rpm安装完成后，再次检查/usr/lib64/目录，应该能看到新增的1.0.2版本库文件：
ls -l /usr/lib64/libssl.so* /usr/lib64/libcrypto.so*现在输出中应该包含：
lrwxrwxrwx. 1 root root 19 Apr 7 2020 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.2o lrwxrwxrwx. 1 root root 19 Apr 7 2020 /usr/lib64/libssl.so.10 -> libssl.so.1.0.2o3.3 安装MySQL
现在可以正常安装MySQL了：
rpm -ivh mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm如果还有其他依赖问题，建议配置MySQL官方yum源后使用yum/dnf安装，这样能自动解决大部分依赖关系。
4. 验证与排错
安装完成后，建议进行以下验证步骤：
- 检查MySQL服务状态：
systemctl status mysqld- 测试SSL连接功能：
mysql -u root -p --ssl-mode=REQUIRED如果连接成功，说明SSL功能正常。
- 查看MySQL使用的SSL库版本：
SHOW STATUS LIKE 'Ssl_version';应该显示"OpenSSL 1.0.2o"之类的信息。
如果遇到问题，可以检查以下日志：
- MySQL错误日志：
/var/log/mysqld.log - 系统日志：
journalctl -xe
5. 深入理解与最佳实践
5.1 为什么会出现这个问题
这个问题本质上是Linux发行版更新策略与软件兼容性的矛盾。CentOS 8为了安全考虑升级了OpenSSL，而MySQL 5.7作为长期支持版本需要保持稳定性，导致两者出现版本断层。
5.2 长期维护建议
对于生产环境，我有几个建议：
- 考虑升级到MySQL 8.0，它原生支持OpenSSL 1.1.1
- 如果必须使用MySQL 5.7，建议使用官方编译的针对CentOS 8的版本
- 定期检查
compat-openssl10的安全更新
5.3 其他可能遇到的问题
有时候即使安装了兼容库，MySQL仍然报错。这可能是因为：
- 库文件路径不在默认搜索路径中
- SELinux策略限制
- 多版本冲突
解决方法：
# 检查库文件路径 ldconfig -p | grep libssl.so.10 # 临时添加库路径 export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH # 检查SELinux getenforce6. 替代方案探讨
除了上述方法，还有几个备选方案值得考虑：
6.1 使用Docker容器
如果环境允许，使用Docker运行MySQL可以彻底避免依赖问题：
docker run --name mysql57 -e MYSQL_ROOT_PASSWORD=yourpassword -d mysql:5.7这个方案的优点是隔离性好，缺点是管理方式与传统安装不同。
6.2 从源码编译
对于高级用户，可以从源码编译MySQL并链接到系统自带的OpenSSL 1.1.1：
wget https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.37.tar.gz tar zxvf mysql-5.7.37.tar.gz cd mysql-5.7.37 cmake . -DWITH_SSL=system make make install这个方法可以获得最佳性能，但编译过程复杂且耗时。
6.3 使用其他MySQL分支
Percona Server或MariaDB等MySQL分支可能提供了对OpenSSL 1.1.1的更好支持，值得考虑作为替代方案。
在实际项目中，我通常会根据具体需求选择最合适的方案。对于大多数场景，安装兼容库是最平衡的选择。