MySQL多实例安装与systemd开机自启配置完整指南

有时候一个服务器上不得不跑多个 MySQL 实例。比如公司预算有限，几套业务共用一个物理机；比如开发、测试、预发环境想隔离但机器不够；再比如你接手了一台跑了好几年的老机器，上面已经有一个 3306 的实例在用，新业务只能再塞一个 3307 进去。我这些年装过多实例，踩过不少坑，也总结了一套比较顺手的流程。这篇文章就把 MySQL 多实例安装和开机自启这件事，从目录规划到 systemd 配置完整走一遍。适合刚入行两三年、需要自己动手搭环境的运维和开发同学，也适合正在准备容器化改造但暂时还得靠物理多实例过渡的团队。全文基于最常见的二进制安装包方式，不牵扯云厂商 RDS 之类的托管服务。

1. 多实例的设计思路：先想清楚再动手

1.1 多实例到底解决什么问题

多实例，简单说就是在同一台 Linux 服务器上，用独立的配置文件、独立的数据目录、独立的端口和 socket，跑多个 mysqld 进程。每个实例彼此独立，互不干扰。

我遇到最典型的场景有两个。一个是混布模式：一个实例跑核心业务库，另一个实例跑日志库或报表库，数据重要性不同，但物理资源复用。另一个是环境隔离：同一台测试机上开了三套 MySQL，分别对应开发、联调、自动化测试，端口从 3306 往下错开，谁也不会影响谁。

这里有个关键点要提前说清楚：多实例不等于高可用。如果你想要的是主从复制、故障自动切换，那是另一套架构。多实例的核心价值是资源和进程的隔离，不是数据的冗余。

1.2 多实例、多进程、还是容器

在规划方案之前，得先知道有哪几条路可以走。

• 纯多实例：一个 MySQL 安装目录，多个数据目录，多个配置文件，多个 mysqld 进程。资源利用率相对较好，每个实例独立配置 buffer pool、连接数等。
• 多套安装：把 MySQL 二进制复制多份，每份独立安装目录。适合需要不同 MySQL 版本同时运行的场景。
• 容器化：每个容器跑一个实例，隔离更彻底，但要求团队熟悉容器运维，且性能损耗在有状态数据库场景要慎重评估。

我个人的建议是：版本统一时优先用纯多实例，省事、可控、性能损耗小。如果确实需要大版本并存——比如业务 A 只能跑 5.7，业务 B 必须上 8.0——那就把安装目录复制成多份，方法类似，只是路径上多一层区分。

纯多实例的隔离粒度是够的。MySQL 的 InnoDB buffer pool、redo log、undo log、binlog 都是实例级的独立资源，只要配置文件分开，互相就看不到了。唯一共享的只有操作系统资源和二进制安装目录里的共享库文件，这在实践中没有影响。

1.3 端口的整体规划

建议提前把端口规划写进文档，别装的时候随手选。常见的 MySQL 端口是 3306，从 3307 往后分配。我习惯按业务代号分配，比如订单库 3306、用户库 3307、日志库 3308，端口号和数据目录名保持一致，这样看目录就知道是哪个实例。

端口规划的同时，要同步规划三个关键文件路径，它们是多实例最容易出问题的地方：

• 数据目录：/data/mysql/3306、/data/mysql/3307
• socket 文件：/tmp/mysql_3306.sock、/tmp/mysql_3307.sock
• PID 文件：/data/mysql/3306/mysql_3306.pid、/data/mysql/3307/mysql_3307.pid

这三个路径在所有实例间必须唯一。很多新手第一次装多实例，配置文件写得挺好，但 socket 和 PID 文件路径漏改，两个实例抢同一个文件，启动直接失败，或者启动成功了但后面怎么都连不上。

2. 基础环境准备与目录规划

2.1 软硬件要求和版本选择

用二进制安装包方式时，系统要求不复杂，CentOS 7 以上或 Ubuntu 18 以上都行，需要 libaio、libnuma 等基础依赖。安装前先确认：

yum list installed | grep libaio yum list installed | grep numactl

缺什么装什么，CentOS 下直接：

yum install -y libaio libaio-devel numactl

MySQL 版本这块，5.7 和 8.0 的安装目录结构和初始化命令略有差异。8.0 里 mysqld --initialize 是唯一标准初始化方式，5.7 也支持，但 5.7 早期版本可能还要处理 mysql_install_db 脚本。现在新装环境，只要不是业务强依赖旧版本特性，我一般建议直接上 8.0。8.0 的默认认证插件 caching_sha2_password 会导致一些老版本客户端连不上，这个问题稍后专门讲。

2.2 创建用户和目录结构

多实例都会用同一个系统用户运行，没必要每个实例建一个用户。统一用 mysql 用户：

groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql mkdir -p /data/mysql/3306 mkdir -p /data/mysql/3307 mkdir -p /data/mysql/3308 chown -R mysql:mysql /data/mysql

目录结构上，我坚持一个实例一个目录，目录下平铺放数据文件、日志、binlog。这样备份和迁移都方便，直接把整个目录打包就行。总磁盘容量要提前算好，数据目录、binlog、redo log、临时文件都要占空间，建议预留至少数据量 1.5 到 2 倍的空余容量，避免磁盘写满导致实例直接挂掉。

2.3 下载解压安装包

下载地址用官网的二进制包就行，选择 linux-glibc2.12-x86_64 或对应平台的版本。解压到 /usr/local 下：

tar -xvf mysql-8.0.36-linux-glibc2.12-x86_64.tar.xz mv mysql-8.0.36-linux-glibc2.12-x86_64 /usr/local/mysql chown -R mysql:mysql /usr/local/mysql

这块有个细节值得提一下：多实例不要求安装目录里包含数据。mysqld 启动时用 --datadir 指定数据目录，所以安装目录是共享的，数据目录是独立的。初始化的动作只针对数据目录，不会动安装目录。

3. 初始化数据目录：最容易踩坑的环节

3.1 初始化命令的完整写法

数据目录初始化是每个实例都要独立执行的。以 3306 实例为例：

/usr/local/mysql/bin/mysqld \ --defaults-file=/etc/my_3306.cnf \ --basedir=/usr/local/mysql \ --datadir=/data/mysql/3306 \ --initialize

先解释一下 --defaults-file 的作用：指定这个实例读哪个配置文件。多实例场景下，每个实例必须有独立配置文件，mysqld 启动时通过 --defaults-file 明确告诉它读哪个，而不是默认读 /etc/my.cnf。

执行完初始化后，注意观察最后几行输出。正常情况会出现类似下面这句：

[Note] A temporary password is generated for root@localhost: 临时密码一串字符

8.0 里这个临时密码一定要记下来，只显示一次，后面找不回来。如果忘了，可以停掉实例后用 --skip-grant-tables 跳过权限系统去重置，但那是绕路，不如初始化时就抄在记事本里。

如果不想记临时密码，也可以用 --initialize-insecure 参数，这样 root 初始密码为空：

/usr/local/mysql/bin/mysqld \ --defaults-file=/etc/my_3306.cnf \ --basedir=/usr/local/mysql \ --datadir=/data/mysql/3306 \ --initialize-insecure

两种方式都可以。我推荐生产环境用 --initialize（带随机密码），这样首次启动前必须手动找到密码并修改，能避免 root 空密码的空窗期。测试环境用 --initialize-insecure 更省事。

3.2 初始化失败的排查方向

初始化阶段最常见的失败原因，我列一下：

• 目录权限不对。datadir 不是 mysql 用户所有，初始化直接报错。chown 一下就解决了。
• 依赖库缺失。报错信息里会提到缺少 libaio.so.1 之类的库，装上就好。
• 配置文件里 datadir 和命令行的 datadir 不一致。mysqld 会检查两个位置，不一致时初始化会拒绝执行。
• 二进制文件没执行权限，或者架构不匹配。这个比较少见，但下载错 tar 包时会出现。

初始化完成后，数据目录下应该能看到一堆文件，包括 ibdata1、ib_logfile0、undo_001、undo_002 等，还有 mysql 库的系统表文件。看到这些就说明成功了。

3.3 多个实例初始化时要注意的细节

如果你要一次初始化 3306、3307 两个实例，可以写个简单的循环，但循环里有一个坑：每条命令必须用不同的 --defaults-file。不然第二个实例初始化时，读的还是第一个实例的配置，datadir 指向同一个目录，直接把第一个实例的数据目录弄乱了，或者报错说目录已被初始化。

我见过有人在这个环节翻车，所以多说一句。初始化完成后不要急着启动，先把配置文件里所有参数校对一遍，再开始启动。

4. 配置文件编写的核心逻辑

4.1 一个实例一个配置文件

多实例的配置文件，我建议放在 /etc 下，用 my_端口号.cnf 命名。比如 /etc/my_3306.cnf、/etc/my_3307.cnf。这样好处是：systemd 模板里用 %i 传参时，可以直接拼接出配置文件名，不用每套都手写服务单元。

配置文件里必写的几组参数，我把它们分成几类。

第一类是实例身份类，包括 port、server_id、socket、pid-file。server-id 在单机多实例下虽然不直接参与复制，但建议还是手动指定且全局唯一，稍微有复制需求时不至于重新改配置。

[mysqld] user=mysql port=3306 server_id=1 socket=/tmp/mysql_3306.sock pid-file=/data/mysql/3306/mysql_3306.pid

第二类是路径类，包括 basedir、datadir、log-error、slow_query_log_file、binlog 相关路径。

basedir=/usr/local/mysql datadir=/data/mysql/3306 log-error=/data/mysql/3306/error.log slow_query_log_file=/data/mysql/3306/slow.log log-bin=/data/mysql/3306/mysql-bin binlog_format=row

第三类是资源类，主要是 innodb_buffer_pool_size。多实例场景下这是最关键的参数。8.0 默认 buffer pool 是 128M，如果你有 64G 内存，跑三个实例但忘了调 buffer pool，三个实例共享剩余内存，性能发挥不出来。反过来，三套业务的 buffer pool 加起来超过物理内存，操作系统就会开始 swap，数据库响应直接卡死。

我有个粗略算法：buffer pool 总量控制在物理内存的 50%-60%，剩下的留给操作系统缓存、连接线程、排序缓冲等。比如 64G 内存，三个实例，每个给 10G 到 12G 比较稳。

4.2 容易被忽略的配置项

多实例下有一些配置容易漏，漏了倒不至于启动失败，但会在后续使用中给你添乱。

• explicit_defaults_for_timestamp：8.0 默认开启，5.7 里要看配置。建议明确写上，避免 timestamp 字段的默认值行为在不同实例间不一致。
• sql_mode：多实例要在配置里统一。我遇到过一个项目，一个实例的 sql_mode 有 ONLY_FULL_GROUP_BY，另一个没有，同一个 SQL 在两边结果不一样，排查了半天才发现是 sql_mode 的差异。
• max_connections：每个实例单独设。默认 151 太小，多实例环境一般建议至少 500，具体看业务连接数。
• character-set-server 和 collation-server：建议统一 UTF8MB4，这个不用多说。
• skip-name-resolve：这个要看情况。如果业务通过 IP 访问数据库，建议开启，省去反解析 DNS 的耗时。但如果业务通过域名访问且依赖 host 授权，就不要开。

4.3 参数校验方法

配置写完后，启动前用一个命令快速校验：

/usr/local/mysql/bin/mysqld \ --defaults-file=/etc/my_3306.cnf \ --validate-config

输出没有报错就说明配置语法和基本依赖没问题。这个命令不会启动实例，只做校验，多实例配置调整后我都习惯先跑一遍再重启。

5. 启动实例与连接验证

5.1 手工启动第一个实例

初始化完成后手工启动一次，确认实例没问题再做 systemd 配置，这样排障链路干净。手工启动推荐用 mysqld_safe：

/usr/local/mysql/bin/mysqld_safe \ --defaults-file=/etc/my_3306.cnf &

mysqld_safe 是一个守护包装器，它会监控 mysqld 进程，异常退出时会自动拉起。但这也带来一个问题：后面配置 systemd 时，如果 ExecStart 还走 mysqld_safe，会有双重守护的混乱。所以生产上我建议 systemd 直接 ExecStart 指向 mysqld 二进制，不用 mysqld_safe。

手工启动后，先看进程和端口：

ps -ef | grep mysqld netstat -tlnp | grep 3306

看到 mysqld 进程存在、3306 端口监听，再去看错误日志 /data/mysql/3306/error.log，正常情况下日志末尾会出现 “ready for connections” 的字样，表示启动完成。如果日志里有 ERROR 级别的信息，先别急着继续，把报错处理完再说。

5.2 用 socket 和 TCP 分别验证连接

$socket 验证：

mysql -uroot -p -S /tmp/mysql_3306.sock

TCP 验证：

mysql -uroot -p -h 127.0.0.1 -P 3306

第一次连接用初始化时生成的临时密码，登录后立刻修改密码。8.0 里修改密码的命令：

ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'NewStrongPass123';

注意这里有个坑：8.0 默认认证插件是 caching_sha2_password，如果业务侧用的是老版本客户端（5.x 的驱动或工具），连 3306 没问题，连 3307 就会报 Authentication plugin 'caching_sha2_password' cannot be loaded 之类的错误。处理办法有两个：一是升级客户端驱动，二是在创建业务账号时指定 mysql_native_password。为了兼容性，测试环境我一般选择二：

CREATE USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'AppPass123'; GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'%';

生产环境建议用 mysql_native_password 还是升级驱动，要根据实际业务栈决定，这里不展开说。

5.3 第二个实例如法炮制

依次把 3307 初始化、启动、连接验证走一遍。不会有什么新问题，但要注意 server-id、端口、socket、pid-file 不要和 3306 冲突。建议手工启动两个实例成功后，再做开机自启。

我提一点：手工验证阶段宁可多花十分钟，也别急着把 systemd 配好然后重启机器验证。很多人在多实例上栽跟头，都是因为系统重启后只有部分实例自动拉起，另一个启不来，手忙脚乱地排查，最后发现在 systemd 里写死了错误路径。

6. 开机自启的 systemd 配置

6.1 用模板单元管理多实例

开机自启这块，我强烈推荐用 systemd 的模板服务。模板服务的文件名格式是 name@.service，启动时通过 systemctl start name@实例名 来传参，%i 就代表实例名。

为 MySQL 多实例创建 /etc/systemd/system/mysqld@.service：

[Unit] Description=MySQL Server %i After=network.target [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my_%i.cnf ExecReload=/bin/kill -HUP $MAINPID TimeoutSec=300 Restart=on-failure LimitNOFILE=65535 [Install] WantedBy=multi-user.target

这个模板的关键点在于 ExecStart 里 --defaults-file=/etc/my_%i.cnf。当执行 systemctl start mysqld@3306 时，%i 被替换为 3306，命令变成：

/usr/local/mysql/bin/mysqld --defaults-file=/etc/my_3306.cnf

这样一套模板就能管所有实例，新增实例时只需要建配置文件和目录，不用再写新的 service 文件。

6.2 Type=simple 与 Type=forking 的选择

很多老教程里 MySQL 的 systemd 配的是 Type=forking，还需指定 PIDFile。这是针对 mysqld_safe 的写法，因为 mysqld_safe 会 fork 出 mysqld 子进程，父进程退出。但如果 ExecStart 直接跑 mysqld（这是模板里的做法），mysqld 是前台进程，应该用 Type=simple。

Type=simple 的话，systemd 认为 ExecStart 启动的进程就是主进程，它退出就代表服务结束。mysqld 恰好是这种守护进程模式，不 fork 到后台，直接占用终端。

以前我抄过网上一个模板，直接用 Type=forking 但 ExecStart 跑的是 mysqld，结果 systemctl start 一直等到 TimeoutSec 超时，服务状态卡在 activating。后来把 Type 改成 simple，问题马上解决。

6.3 启动和设置开机自启

配置写好后，依次执行：

systemctl daemon-reload systemctl start mysqld@3306 systemctl start mysqld@3307 systemctl enable mysqld@3306 systemctl enable mysqld@3307

执行 enable 后，systemd 会在 /etc/systemd/system/multi-user.target.wants/ 下创建符号链接，指向 mysqld@.service，这就实现了开机自启。

验证状态：

systemctl status mysqld@3306 systemctl status mysqld@3307

这里有几个细节要注意：

• 用 systemctl start 后，看到状态是 active (running)，再去看端口确认一遍有没有真的监听。systemctl 状态和实际进程偶有不同步，以端口和进程为准。
• enable 操作只创建自启链接，不会启动服务。很多人以为 enable 后服务马上就在运行了，其实不是，要先 start 再 enable。
• systemctl 默认会设置一些资源限制，比如文件描述符限制。MySQL 8.0 需要较多文件描述符，模板里我用 LimitNOFILE=65535 显式放开，避免运行中报 "Too many open files" 错误。

6.4 重启验证自启效果

配置完成后，一定要做一次完整的重启验证。这一步不能省略。

reboot

机器起来后，静默几秒，执行：

systemctl status mysqld@3306 systemctl status mysqld@3307 ss -tlnp | grep 3306 ss -tlnp | grep 3307

两个实例都应该 active (running)。如果某一个没起来，看一下对应的 error.log，大概率是配置路径或权限问题。

7. 常见问题与排查实录

7.1 端口和 socket 被占

这是多实例最常见的问题。第一个实例起来了，第二个实例报 Address already in use，或者 MySQL 自己报 Can't start server: Bind on TCP/IP port. Got error: 98.

排查方法：

ss -tlnp | grep 3307

如果端口被占，看是哪个进程占用的。如果是别的业务程序占用了端口，需要协调换端口；如果是上一个没退干净的 mysqld 进程占着，就 kill 掉它再启动。

socket 文件冲突的排查比较隐蔽。如果两个实例配置了相同的 socket 路径，第一个实例创建了 socket 文件，第二个实例启动时尝试使用同一个文件，会报 bind 失败或文件已存在。

处理方法：让 socket 路径在实例间唯一，用 /tmp/mysql_端口号.sock 的格式。启动前如果之前异常退出留下了残留 socket 文件，先删掉再启动。

7.2 数据目录权限引起的启动失败

现象：systemctl start mysqld@3307 报错，日志里提示 Permission denied 或 mysqld: Can't read dir of '/data/mysql/3307'。

原因基本是数据目录的属主不是 mysql。多实例目录是分开创建的，有时候忘了 chown 新目录。

处理：

chown -R mysql:mysql /data/mysql/3307

这个操作治标治本。顺便检查一下 /usr/local/mysql 的属主，之前遇到过安装包解压后用 root 启动过一次，之后 mysql 用户权限不够，启动也报错。

7.3 systemd 单元未找到

执行 systemctl start mysqld@3306 时，如果提示 Unit mysqld@3306.service not found，常见原因有两个：

一是服务文件没放到 /etc/systemd/system/ 下，或者文件名写错了，必须是 mysqld@.service 这个格式，注意有个 @ 符号。二是在编辑完服务文件后没有 daemon-reload。改过 systemd 配置后一定要 reload，第一次创建服务更是如此。

7.4 内存溢出和 OOM

多实例环境里，三个实例的 buffer pool 之和接近物理内存，一旦业务并发上来，操作系统可能触发 OOM Killer，随机杀掉一个 mysqld 进程。

排查：

dmesg | grep -i oom journalctl -k | grep -i oom

日志里能看到哪个进程被杀。处理方向有两个。一是把不重要的实例 buffer pool 调小，给核心实例让内存。二是对 mysqld 进程设置 oom_score_adj，让 OOM Killer 优先杀进程时避开关键实例：

echo -200 > /proc/$(pidof mysqld)/oom_score_adj

但通过 systemd 管理时，更优雅的方式是在 service 模板里配置 OOMScoreAdjust，核心实例的模板单独加，或者写在一个带后缀的实例专属 service 覆盖文件里。

说实话，调低 buffer pool 让它别 OOM 才是正道，OOMScoreAdjust 只是最后一道防线，靠它保命不太可靠。

7.5 老版本客户端认证插件不兼容

这个在前面提过。8.0 默认认证插件是 caching_sha2_password，如果应用服务器上的 mysql-client 或者 JDBC 驱动版本太老，连接时会直接失败。

报错信息常见的是：

Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.

处理办法是业务账号创建时指定 mysql_native_password，前提是数据库配置文件里没有显式禁用这个插件。如果业务驱动没法升级，又对安全性要求没那么高，这个方案最省事。

7.6 常见问题速查表

实际上多实例的排障逻辑比其他环境简单，万变不离其宗：先看 error.log，再确认端口、socket、PID 文件三件套唯一性，最后检查属主和权限。80% 的问题都出在这三个环节里。

8. 最后分享一点个人经验

多实例安装这件事，单看每个步骤都不难，难的是每个实例都要做到一模一样，不能厚此薄彼。一个实例手工启动成功了，另一个实例也要走完整的启动、验证、systemd 配置流程，不能图省事只把前面几个实例配了 systemd，后面的口头说"重启时再手动拉一下"。一旦机器重启，这样的口头约定就变成事故。

我现在的固定做法是：目录、配置、systemd 全部在装实例时一次做到位，然后所有实例一起 reboot 验证。新增实例时就复制一套对应的目录结构和配置文件，把端口和路径改一遍，test 环境跑一个冒烟连接就能交付。

再补一个小技巧：如果服务器上实例很多，建议在 /etc/profile.d/ 下写一个环境变量文件，把不同实例的 socket 路径预设成 MYSQL_3306_SOCK 之类的变量。平时连接不同实例就不用每次敲一长串路径：

export MYSQL_3306_SOCK=/tmp/mysql_3306.sock export MYSQL_3307_SOCK=/tmp/mysql_3307.sock

登录后可以直接：

mysql -uroot -p -S $MYSQL_3307_SOCK

这个细节在实例多、切换频繁的时候能省不少事。多实例本身不难，难在规范。目录规范、配置规范、systemd 规范，这套规范立住了，后面扩容多少个实例都只是填表工作。