MySQL 5.7与8.0共存：服务“消失”的根因与systemd隔离部署实战

前阵子帮人收拾一台测试服务器，机器上同时装了 MySQL 5.7 和 MySQL 8.0，前一天还能正常连的 5.7，第二天再去看，systemctl status mysqld 居然直接提示 Unit not found，服务就像人间蒸发了一样。更诡异的是 8.0 一直好端端的。排查了一下午，最后发现根本不是“莫名其妙”，而是多版本共存时，服务文件、配置文件、数据目录这些资源在底层互相覆盖，导致 5.7 的服务单元被 8.0 的安装包“顶掉”了。

这个场景其实非常典型——很多人在同一台机器上折腾两个版本的 MySQL，不是用 Docker，而是直接装到系统里。一旦遇到服务“消失”、启动失败、服务启动后马上退出的情况，第一反应往往是重装，结果越装越乱。这篇文章就围绕“同时装 MySQL 5.7 和 8.0，5.7 服务消失”这个问题，把根因、排查方法和正确共存方案一次讲清楚，适合对 Linux、systemd 和 MySQL 有一定基础，但还没踩过多版本部署坑的同学参考。

1. 先弄清楚“服务消失”是怎么发生的

1.1 一次经典翻车：8.0 和 5.7 打架的现场还原

先说一个我实际遇到的翻车过程。那台机器原本是 MySQL 5.7，通过官方 rpm 包安装，跑了半年一直很稳。后来因为业务需要测试 8.0 的新特性，直接用 yum 装了 mysql80-community-release 仓库，然后 yum install mysql-community-server。

装完后 8.0 能正常启动，但提示 mysqld 已经在运行。当时没多想，直接 systemctl stop mysqld 停掉旧的，又 systemctl start mysqld 启动新的，结果 8.0 也起来了，连 mysql -uroot -p 看到的版本号也是 8.0。

过了一周，需要检查 5.7 里的数据，执行 systemctl start mysqld，日志直接报错，再看 systemctl status mysqld，服务还在，但怎么都启动不起来。后来折腾半天，发现 /usr/lib/systemd/system/mysqld.service 这个文件已经被 8.0 的包覆盖了，内容里指向的 ExecStart 参数、PIDFile 路径、配置读取顺序，全是 8.0 的版本。5.7 的二进制文件倒是还在 /usr/sbin/mysqld，但已经被替换成了 8.0 的二进制——或者更准确地说，旧的 5.7 可执行文件被 rpm 升级成了 8.0。

这就是“服务消失”的第一层真相：MySQL 5.7 和 8.0 使用完全相同的服务名 mysqld.service、相同的配置路径 /etc/my.cnf、相同的数据目录 /var/lib/mysql，rpm 包按“同路径覆盖”的方式安装时，后装的版本会把先装版本的关键文件替换掉，于是旧版本看起来就像“消失”了。

1.2 服务消失的真正原因：四种典型元凶

我整理了这几次排查经历，发现所谓“5.7 服务莫名消失”，其实不外乎下面四种情况，可以拿来自查。

第一种是 systemd 单元文件被覆盖或删除。5.7 和 8.0 的 rpm 包都自带 /usr/lib/systemd/system/mysqld.service，安装新版本时，rpm 会直接覆盖这个文件。覆盖后即使你执行 systemctl start mysqld，systemd 会加载 8.0 的启动参数，要么启动的是 8.0，要么因为参数不兼容导致 5.7 起不来。如果卸载 8.0 时把原来的单元文件也清掉了，那就直接变成 Unit not found。

第二种是 数据目录冲突。5.7 和 8.0 默认都使用 /var/lib/mysql 作为 datadir。如果你在 5.7 还在跑的时候初始化了 8.0，初始化动作会往同一个目录写入新版本的数据字典格式。5.7 再去读取时，会因为数据字典版本不兼容直接失败——这不是“服务消失”，而是服务还在，但永远启动不了，systemd 会显示 failed，很多人看到 failed 就当“服务坏了”去重装。

第三种是 配置文件串台。/etc/my.cnf 只有一个，5.7 能识别 mysqlx=1 这种参数吗？不能。8.0 安装时写入的配置片段，5.7 的 mysqld 根本不认识，启动时直接报 unknown variable 'mysqlx=1'，然后退出。这种情况的表现也是服务启动失败，而不是消失。

第四种是 端口或 socket 冲突。两个版本都默认监听 3306 端口、默认使用 /var/lib/mysql/mysql.sock 或 /tmp/mysql.sock 作为 socket 文件。后启动的那个会因为端口被占用或 socket 文件被占用而失败。如果 systemd 服务配置了 Restart=on-failure，系统会反复尝试重启，最终触发 StartLimitBurst 限制，systemd 干脆放弃，服务状态变成 failed 或 inactive (dead)，看起来就像“彻底没了”。

还有一个容易被忽略的点：如果用户手工把某个服务执行了 systemctl mask，这个服务会在 list-unit-files 里显示为 masked，相当于被“软禁用”，任何启动命令都会被忽略，表面上也像“消失”。所以排查时不要只看 systemctl status，要配合 systemctl list-unit-files 一起看。

2. 动手之前：把5.7和8.0的资源彻底分开

2.1 为什么直接yum装两个版本行不通

很多人图省事，想用 yum 配置 mysql57-community-repo 和 mysql80-community-repo，然后直接装两个版本。但从底层看，这几乎不可能成功。

rpm 管理的核心原则是：同一个包名（比如 mysql-community-server）只能安装一个版本。MySQL 官方 rpm 包在 5.7 和 8.0 之间使用了大量相同的文件路径，比如 /etc/my.cnf、/usr/lib/systemd/system/mysqld.service、/usr/sbin/mysqld、/var/lib/mysql。如果你同时启用 5.7 和 8.0 两个仓库，yum 解析依赖时会遇到冲突，直接拒绝安装。就算你强行 --replacefiles，也会把之前的配置、服务文件、数据目录搅得一塌糊涂。

有一种稍微可行的变通方案：用 yum 装 5.7，再用官方二进制 tar 包部署 8.0，完全手工管理 8.0 的目录和服务名。或者反过来，用 yum 装 8.0，用 tar 包部署 5.7。关键是：至少一个版本必须走“手工部署”路线，不能两个都交给 rpm 管。

2.2 五类必须隔离的资源清单

为了让两个版本互不干扰，需要把下面五类资源完全隔离开。这五类也是排查“服务消失”时最重要的检查点。

注意配置文件这一行。MySQL 默认会按顺序读取 /etc/my.cnf、/etc/mysql/my.cnf、$basedir/my.cnf、~/.my.cnf。多版本共存时，最稳妥的做法是不碰系统默认配置，给每个实例单独写一份配置文件，然后通过 --defaults-file=/etc/my-57.cnf 强制指定。这样既能避免被 /etc/my.cnf 里的 8.0 参数干扰，也能保证 systemd 启动时读到的就是正确配置。

2.3 我推荐的整体布局

我的习惯是这样的：8.0 走官方 rpm 安装作为主实例，5.7 走官方二进制 tar 包部署作为次实例。 原因有两个：一是 8.0 是当前主流，主库用 rpm 升级维护更省心；二是 tar 包装出来的 5.7 完全隔离在自己目录里，配置、数据、服务单元名字都不一样，系统管理工具升级时不会误伤它。

如果你面临的是反过来的场景——主库是 5.7，需要测试 8.0，那就把 8.0 做成 tar 包部署的实例，5.7 继续用 rpm 管。原理完全一样，只是把“手工管理”的角色换一下。

布局确定后，所有操作都围绕“隔离”这两个字展开：目录隔离、用户隔离、配置隔离、端口隔离。下面第三部分就是完整的实操流程。

3. 从零搭建互不干扰的5.7实例（完整实操）

这一部分我以“机器上已经用 rpm 装好 MySQL 8.0，需要再跑一个 5.7”为前置场景，给出可以直接照抄的完整步骤。

3.1 解压二进制包并创建独立账号

去 MySQL 官方下载页拿 5.7 的 Linux 通用二进制包，注意选 mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz，glibc 版本不对启动会报错。下载后解压到 /usr/local，然后建一个软链接，方便以后升级替换。

bash复制cd /usr/local
tar -zxvf mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz
ln -s mysql-5.7.44-linux-glibc2.12-x86_64 mysql57

接下来创建独立运行账号。我不用默认的 mysql 用户——因为 8.0 已经在用这个用户，再让 5.7 也用同一个用户，虽然权限上可行，但排查问题时 ps aux 里都是 mysql，非常容易混淆。所以单独建一个 mysql57 用户：

bash复制useradd -r -s /sbin/nologin mysql57
mkdir -p /data/mysql57
chown -R mysql57:mysql57 /data/mysql57
chown -R mysql57:mysql57 /usr/local/mysql57

这里有个细节：5.7 的二进制目录建议也交给 mysql57 用户持有，因为初始化数据目录时，mysqld 需要读取 basedir 下的 share、lib 等文件，如果权限不足会启动失败。很多网上教程没提这一点，容易导致第一次 mysqld --initialize 就报权限错误。

3.2 独立配置文件和初始化

写一份 5.7 专用配置文件，路径我放在 /etc/my-57.cnf，内容如下：

ini复制[client]
socket=/tmp/mysql57.sock

[mysqld]
user=mysql57
port=3307
basedir=/usr/local/mysql57
datadir=/data/mysql57
socket=/tmp/mysql57.sock
pid-file=/data/mysql57/mysql57.pid
log-error=/data/mysql57/error.log
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci

[mysqld_safe]
pid-file=/data/mysql57/mysql57.pid

重点说明几个参数的用意。

• user=mysql57：让 mysqld 启动后主动降权，以 mysql57 用户身份运行，避免用 root 运行带来的安全风险。
• port=3307：避开 8.0 的 3306，两者才能同时监听。
• socket=/tmp/mysql57.sock：这是很多人容易漏掉的点。不分开 socket 文件的话，客户端默认会去连 8.0 的 socket，导致你敲 mysql -uroot 连上的可能是另外那个实例。
• pid-file、log-error：日志独立一份，出问题时排查起来才清楚，否则 5.7 和 8.0 的报错混在一个日志里，对定位问题非常不友好。

配置文件准备好后，用 5.7 的 mysqld 二进制初始化数据目录。这一步的坑最多，出错率也最高：

bash复制/usr/local/mysql57/bin/mysqld --defaults-file=/etc/my-57.cnf --initialize-insecure --user=mysql57

为什么要加 --defaults-file？因为你已经写好了配置文件，但 mysqld 默认会先读 /etc/my.cnf，如果不强制指定，8.0 在 /etc/my.cnf 里写的参数（比如 mysqlx=1）会被 5.7 解析，直接报 unknown variable。--defaults-file 的作用就是彻底绕开默认配置文件，只读你指定的那份。

--initialize-insecure 和 --initialize 的区别是：前者把 root 初始化为空密码，适合本地开发环境；后者生成一个临时密码，会写进日志，适合生产场景。如果当前是生产测试环境，建议用正式的 --initialize，然后从 /data/mysql57/error.log 里捞初始密码。

初始化成功后，数据目录里会出现 mysql、performance_schema、sys 等子目录。如果看到 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11，说明这个目录被其他进程占用了——大概率是你 datadir 路径设置不对，又跑到 8.0 的 /var/lib/mysql 去了。改配置文件里的 datadir，重新初始化即可。

3.3 用systemd管理5.7服务

有了独立的用户、配置和数据目录，接下来最关键的一步：注册一个完全独立的 systemd 服务单元。这一步也是避免“服务消失”的核心中的核心。

在 /etc/systemd/system/ 下新建 mysqld57.service：

ini复制[Unit]
Description=MySQL 5.7 Community Server
After=network.target

[Service]
Type=forking
User=mysql57
Group=mysql57
PIDFile=/data/mysql57/mysql57.pid
ExecStart=/usr/local/mysql57/bin/mysqld --defaults-file=/etc/my-57.cnf
ExecReload=/bin/kill -s HUP $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

然后执行：

bash复制systemctl daemon-reload
systemctl enable mysqld57
systemctl start mysqld57
systemctl status mysqld57

为什么 Type=forking？因为 5.7 的 mysqld 启动时会 fork 出守护进程，父进程退出，systemd 需要靠 PIDFile 追踪真正的后台进程，所以必须显式指定 PIDFile。如果你的配置里没写 pid-file，或者 PIDFile 路径和配置不一致，systemd 会报 Start request repeated too quickly 或直接判定启动失败。

启动完毕后，用 systemctl status mysqld57 应该能看到 active (running)。这一步如果报错，99% 是配置文件的参数名或者路径不对，直接看 /data/mysql57/error.log，里面会有最直接的报错原因。

3.4 登录验证与8.0共存确认

实例起来后，验证两个版本同时存活：

bash复制# 查看两个实例的监听端口
ss -lntp | grep 330
# 3306 -> 8.0，3307 -> 5.7

# 通过 socket 登录 5.7
/usr/local/mysql57/bin/mysql -uroot -S /tmp/mysql57.sock

# 通过本地端口登录 5.7
/usr/local/mysql57/bin/mysql -uroot -h127.0.0.1 -P3307

注意登录 5.7 时，必须使用 5.7 目录下的 mysql 客户端。因为系统 PATH 里的 mysql 很可能指向 8.0 的客户端，而 8.0 的客户端默认会使用 3306 或本地 socket 连接，不一定能直接连上 3307。或者你也可以在 /etc/my-57.cnf 的 [client] 段里写死 socket=/tmp/mysql57.sock、port=3307，这样调用 mysql 客户端时会自动带这两个参数，方便日常操作。

到这里，5.7 和 8.0 就已经完全隔离地跑在同一台机器上了。以后启动 5.7 用 systemctl start mysqld57，启动 8.0 用 systemctl start mysqld，互不干扰，升级系统包也不会波及 5.7 实例。

4. 如果5.7已经消失，急救排查全流程

如果你不是从零开始，而是已经遇到了 5.7 服务消失的情况，别急着卸载重装，按下面三步排查，大概率能救回来。

4.1 第一步：从systemd状态判断问题方向

先执行 systemctl status mysqld57 或 systemctl status mysqld，看系统怎么回应。不同的回应对应的问题方向完全不同。

• Unit mysqld57.service could not be found：说明 systemd 已经不认识这个服务单元了。要么单元文件被删，要么服务名被改动。执行 systemctl list-unit-files | grep mysql 看看有哪些 mysql 相关的单元。
• Active: failed (Result: exit-code)：服务单元还在，但启动失败。大概率是配置、权限或数据目录的问题。
• Active: inactive (dead) 且 loaded 显示 masked：服务被 mask 了，执行 systemctl unmask mysqld57 解开即可。
• 服务状态 active (running)，但 3306 端口连上去显示 8.0：说明 systemd 里加载的其实是 8.0 的服务，5.7 的单元文件已经被覆盖了。这种情况要重点检查 /usr/lib/systemd/system/mysqld.service 和 /usr/sbin/mysqld 是否被 8.0 替换。

systemctl cat mysqld 是排查“服务被覆盖”最快的命令。它会直接显示 systemd 加载的单元文件内容和它来自哪个路径。如果你发现内容里写的是 /usr/local/mysql80 或者 mysqld --datadir=/var/lib/mysql 这类和 8.0 相关的参数，基本就确认是被覆盖了。

4.2 第二步：翻日志看真实报错

系统服务状态只能告诉你“发生了什么级别的问题”，真正的原因要看日志。如果是 5.7 实例，看 /data/mysql57/error.log；如果是 rpm 装的 5.7，看 /var/log/mysqld.log。

几个高频报错和对应原因：

日志很重要一点：不要只看最后几行，要从下往上翻到最开始的 [ERROR] 行。 mysql 的 error.log 里，真正决定失败原因的第一条报错往往出现在前面，后面跟的一堆都是连锁反应。

另外，systemd 的 journal 也值得看：

bash复制journalctl -u mysqld57.service -n 50 --no-pager

如果 systemd 侧显示 Start request repeated too quickly，说明服务启动后几秒内就退出，系统触发防抖机制。这时不要盲目反复 start，先清状态：

bash复制systemctl reset-failed mysqld57.service

把失败计数清掉，再重新启动，否则你看到的现象一直是“服务起不来”，容易误判成服务消失。

4.3 第三步：三种快速恢复手段

根据诊断结果，选择对应的恢复手段。

情况一：单元文件不存在或已被覆盖。 直接按第三部分的代码，重新写一份 /etc/systemd/system/mysqld57.service，注意 ExecStart 里加 --defaults-file=/etc/my-57.cnf，然后 daemon-reload，enable 加 start。这样等于给 5.7 重新“立户口”，彻底摆脱对 mysqld.service 的依赖。

情况二：服务被 mask。 如果 systemctl list-unit-files | grep mysqld57 显示 masked，执行 systemctl unmask mysqld57，然后重新 enable、start。mask 状态常常是 rpm 安装另一个版本时自动执行的防护动作，但也会造成“服务消失”的错觉。

情况三：配置串台导致启动失败。 如果服务单元还在、数据目录也没问题，只是启动报错，那就给 5.7 写独立配置，把 datadir、socket、pid-file 全部指到独立路径，同时修改 service 文件的 ExecStart。这样 8.0 无论怎么改 /etc/my.cnf，都不会再影响 5.7。

急救的基本思路就是：不要让两个版本共享任何动态资源，服务单元、配置、数据、端口，全部独立。只要做到这一点，5.7 就不可能“莫名消失”。

5. 常见问题速查与个人避坑经验

5.1 高频问题排查速查表

把我在多版本共存实操中遇到的典型问题整理成表，建议收藏，碰到问题直接对号入座。

5.2 关于多版本共存的几条个人习惯

说几条踩过坑之后养成的习惯，不一定写在哪本手册里，但实战价值很高。

第一，任何多版本实例都要有独立用户。 我见过太多直接用 mysql 用户管理两个实例的做法，虽然能跑，但一旦要清理进程、排查权限，根本分不清哪个进程属于哪个实例。独立用户 mysql57、mysql80 一眼就能识别。

第二，所有实例统一用 systemd 管理，不要混用 mysqld_safe。 我以前图省事，用 mysqld_safe 起 5.7，systemd 管 8.0，结果两个实例抢同一个 pid 文件，互相 kill。统一用 systemd 之后，systemctl start mysqld57 和 systemctl start mysqld 谁是谁清清楚楚。

第三，版本升级前先看服务文件。 如果你用 yum 升级 8.0，rpm 可能会自动覆盖系统目录里的 mysqld 服务。升级完记得 systemctl daemon-reload，并确认 5.7 的自定义服务单元没有被改动。由于自定义服务在 /etc/systemd/system/ 下，优先级高于 rpm 写入的 /usr/lib/systemd/system/，只要服务名不冲突，一般不会被影响。

第四，默认端口尽量分开。 5.7 用 3307，8.0 用 3306，或者反过来，总之不要两个都占一个端口。这样开发环境里切换实例也方便，mysql -P3307 和 mysql -P3306 不会混淆。

多说一句，很多人喜欢在一个实例里通过 mysqld_multi 来管理多个 MySQL 进程，这个思路也可以用，但对 systemd 的依赖程度更低，灵活性更差。如果你需要长期维护两个独立版本，独立 systemd 服务单元是我个人更推荐的方式。

最后再分享一个判断“服务是否真的消失”的小技巧：不要只看 systemctl status，要看 systemctl list-unit-files | grep mysql 的输出。 前者告诉你服务的实时运行状态，后者告诉你 systemd 是否还“认识”这个服务。只要 list-unit-files 里还能看到 mysqld57.service，说明服务只是没跑起来，问题是配置、数据或端口层面的；如果连这里都看不到了，那才是真正的“服务凭空消失”，需要重建服务单元。这个区分能帮你省掉大量盲目排查的时间。