企业官网建设流程全解析

在 RHEL 6.4 上离线安装 MySQL 5.7，这事儿听着就是“下载、解压、启动”三步，真做起来才知道老系统有多磨人。缺依赖、GLIBC 版本对不上、没有 systemd、初始化方式也变了，网上教程一半是照着 CentOS 7 写的，在 6.4 上直接套十有八九要翻车。这篇就把我实际踩过、排过的一整条路径完整记录下来，给需要在 RHEL/CentOS 6.x 这类老系统上离线部署数据库的朋友一份能照着抄的作业。运维、实施、还有想深入理解 MySQL 部署原理的学习者，都可以放心参考。

1. 方案选型：离线安装前先想清楚三条岔路

1.1 为什么是 MySQL 5.7，而不是 8.0

既然标题写的是 MySQL 5.7，抛开版本偏好不谈，单从技术角度看，在老系统上选 5.7 也确实是更稳妥的选择。MySQL 8.0 对系统的要求更高，默认认证插件是 caching_sha2_password，很多旧客户端和中间件不一定兼容，加上 8.0 的二进制包对 glibc 版本的要求也更激进，放在 RHEL 6.4 上硬装，很容易在启动阶段就遇到一堆底层库不匹配的问题。

MySQL 5.7 生命周期长，周边生态成熟，InnoDB、查询优化器、半同步复制这些核心能力已经足够稳定。更关键的是，官方针对旧系统还保留了 glibc 2.12 的通用二进制包，这才是离线安装 RHEL 6.4 时最省心的选择。一句话总结：在老旧生产环境里，功能够用、兼容性好、资料多，就是最大的优势。

1.2 RPM Bundle 与二进制 tar.gz 到底怎么选

离线安装 MySQL 5.7 的主流方案有两种，一是官方 RPM Bundle，二是 Linux 通用二进制 tar.gz 包。很多教程推荐 RPM，因为管理统一、自带服务脚本、开机启动简单。但真正到了离线环境，RPM 方式的依赖解析会让你想砸电脑。

我直接把两种方式的优缺点列个表，大家自己对照。

我最终选的是二进制 tar.gz 包。理由有三条：

第一，离线环境最怕的就是依赖链。RPM 安装时少一个包，你就得在没网的情况下四处找，而 tar.gz 包几乎只需要 libaio，这个依赖特别好搞定。

第二，目录集中。整个 MySQL 就在一个目录里，后面要升级、备份、迁移，把目录打包拷走就行，不需要跟系统的包管理器纠缠。

第三，版本匹配更精准。官方对 RHEL 6 的 RPM 包支持早就收缩了，但 glibc 2.12 的通用包还在持续提供，选它才能避免“RPM 包装好了但跑不起来”的尴尬。

1.3 下载安装包前的版本与 glibc 检查

下载前先确认一下系统底子，命令很简单。

uname -m cat /etc/redhat-release ldd --version | head -n1

RHEL 6.4 默认自带的是 glibc 2.12，所以你在官方下载页面选择时，操作系统那一项要选Linux - Generic，OS Version 选glibc2.12 (x86, 64-bit)，别选成glibc2.17或者el7的包。

文件名类似mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz，体积六百多兆。下载这个包可以在任意一台能上网的机器上完成，Windows 或 Linux 都行，但上传到服务器时务必用二进制方式传输，比如 rz、WinSCP 或 scp，不要用文本模式传，也不要本地解压后再传文件，否则容易出现权限错乱和文件损坏。

2. 环境清理与依赖补齐：三分安装，七分排雷

2.1 识别并清理系统残留数据库

RHEL 6.4 安装时如果勾选了数据库相关组件，系统里可能带着老版本的 MySQL 或者残留 libs 库。直接安装新版本会跟这些旧文件起冲突，最常见的就是/usr/bin/mysql被旧版本占用，或者 RPM 校验时提示文件冲突。

先查一遍。

rpm -qa | grep -iE 'mysql|mariadb'

如果没有任何输出，说明系统是干净的，跳过这一步。如果有，那要考虑是卸载还是共存。普通场景下推荐卸载旧版，因为 MySQL 5.7 的二进制包是自包含的，不需要系统里有旧版客户端来配合。

卸载时不要犹豫，但也不要暴力乱删。理想顺序是：

rpm -e --nodeps mysql mysql-server mysql-libs mysql-devel

注意：--nodeps会跳过依赖检查，属于破坏性操作。如果这台机器上还有业务在用旧数据库，务必先备份数据、确认业务窗口再执行。测试环境无所谓，生产环境必须谨慎。

卸载完成后，顺手清理一下历史残留目录：

rm -rf /var/lib/mysql /etc/my.cnf /etc/my.cnf.d

这些目录可能装着旧数据或旧配置，留着容易导致新实例读取到莫名其妙的参数。

2.2 libaio 依赖和离线 RPM 补装

MySQL 5.7 的二进制包启动时强依赖libaio库，如果系统里没有，会在启动阶段直接报错：

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

检查方式很简单：

ldconfig -p | grep libaio

没有输出就说明缺了。离线环境下补这个依赖的办法，是从 RHEL 6.4 的安装光盘或镜像里的 Packages 目录中找到libaio-0.3.107-10.el6.x86_64.rpm，上传后本地安装。

rpm -ivh libaio-0.3.107-10.el6.x86_64.rpm

libaio 这个包比较干净，依赖很少，一般不需要额外处理。少数情况下还缺数ncurses-libs，同样从光盘找ncurses-libs的 rpm 装上即可。

2.3 提前创建用户和目录

MySQL 从安全角度出发，明确要求不能用 root 身份直接初始化数据目录和运行 mysqld 进程。官方推荐的做法是创建一个专用用户，名字一般叫 mysql，甚至不允许该用户登录 shell。

id mysql || useradd -r -s /sbin/nologin mysql

接下来规划目录。我的习惯是把安装目录、数据目录、日志目录三者分开，这一点非常重要。

mkdir -p /usr/local/mysql mkdir -p /data/mysql mkdir -p /var/log/mysql chown -R mysql:mysql /usr/local/mysql /data/mysql /var/log/mysql

为什么强调分开？因为安装目录是程序文件，升级时要整个替换；数据目录是数据库的“心脏”，必须独立存放；日志目录放错误日志和慢查询日志。如果把数据目录放在安装目录里，升级时一个不小心就把数据一起删了，那种事故一次就够了。

3. 解压、配置与初始化数据目录

3.1 解压放置并统一属主

把上传好的mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz放到 /tmp 下，然后解压到 /usr/local。

cd /tmp tar -zxvf mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz -C /usr/local/ mv /usr/local/mysql-5.7.44-linux-glibc2.12-x86_64 /usr/local/mysql chown -R mysql:mysql /usr/local/mysql

两个细节：解压完目录名很长，改名为 /usr/local/mysql 是为了精简路径，后续写配置和服务脚本都省事；紧接着执行 chown 是避免后面初始化时报权限错误，这个权限问题几乎每个新手都会遇到，直接在解压后做掉能省很多事。

3.2 写一个不过度堆参数的 my.cnf

MySQL 5.7 会按顺序读取多个配置文件，最终生效的位置是/etc/my.cnf。生产环境我就直接写这一个文件，避免多个配置文件混在一起造成参数覆盖时定位困难。

以下是我在 RHEL 6.4 老服务器上常用的基础配置：

[mysqld] user=mysql basedir=/usr/local/mysql datadir=/data/mysql socket=/tmp/mysql.sock pid-file=/data/mysql/mysqld.pid log-error=/var/log/mysql/error.log port=3306 character-set-server=utf8mb4 collation-server=utf8mb4_general_ci [client] socket=/tmp/mysql.sock default-character-set=utf8mb4

这里有几个值得解释的地方。

user=mysql让 mysqld 启动后切换为 mysql 用户运行，避免以 root 身份承载数据库进程，降低安全风险。socket路径写 /tmp/mysql.sock 是为了兼容大多数客户端默认值，如果换成一个不太常见的路径，那后面执行 mysql 命令时必须手动加--socket=xxx，少写一步就连不上。character-set-server=utf8mb4是给数据库默认字符集，现在主流应用都要存 emoji，utf8mb4 是必须的。

注意：内存参数先别急着抄网上的大神调优配置。老服务器内存有限，什么 innodb_buffer_pool_size、innodb_log_file_size 改得过大，最直接的下场就是内存不足被 OOM Killer 干掉。先跑默认值，稳定运行后再根据监控数据慢慢调，这才是正确的节奏。

3.3 mysqld --initialize 初始化

MySQL 5.7 的一个重大变化是废除了老旧的mysql_install_db脚本，改用mysqld --initialize来完成数据目录初始化。

/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --initialize --user=mysql

执行后，重点观察/var/log/mysql/error.log。初始化成功时，日志尾部会有一行形如：

[Note] A temporary password is generated for root@localhost: 某个临时密码

这个临时密码必须第一时间记下来，因为首次登录 root 只能用这串东西。

几个关键点要特别强调：

第一，不要用--initialize-insecure，除非你想让 root 初始密码为空。测试环境无所谓，生产环境不建议。

第二，初始化只做一次。数据目录一旦生成，重复初始化会报错或把已有目录搞脏。如果确实要重来，最稳妥的是清空数据目录再执行。

第三，如果初始化时报了类似Can't create/write to file '/data/mysql/...'的错，基本就是目录属主不对，或者 SELinux 拦住了写权限，回到 2.3 节重新检查 chown，并临时关闭 SELinux 验证。

4. 老系统启动服务与开机自启

4.1 用 mysql.server 建立 SysV 服务

RHEL 6.4 使用的是 SysV init，没有 systemctl 命令，这是很多网上教程在 6.x 上跑不通的根本原因。好在 MySQL 解压目录里自带了一个服务脚本support-files/mysql.server，可以直接拿来当 init 脚本用。

cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld chmod +x /etc/init.d/mysqld chkconfig --add mysqld chkconfig mysqld on

chkconfig --add mysqld是把服务纳入系统服务管理，chkconfig mysqld on则是设置开机自启。这一步做完，就可以通过 service 命令管理了。

service mysqld start

启动过程会打印一行Starting MySQL.Logging to /var/log/mysql/error.log，正常情况下几秒后出现SUCCESS!。如果长时间卡住或者直接失败，立刻去 error.log 看具体原因，基本逃不出路径写错、权限不对、依赖缺失这几类。

验证端口监听：

netstat -tlnp | grep 3306

有输出就说明服务已经起来了，随后用mysql客户端验证登录。

4.2 SELinux 和 iptables 的坑

RHEL 6.4 默认开着 SELinux，处于 enforcing 模式。MySQL 安装在自定义路径、数据目录也在非标准位置时，SELinux 策略很可能会拦截 mysqld 的读写权限，表现就是启动失败或初始化失败，但单看日志又很难直接联想到 SELinux。

最省事的验证方法是临时关闭：

setenforce 0

如果确认是这个原因，再决定是否永久关闭。永久关闭要改 /etc/selinux/config，把SELINUX=enforcing改成disabled，注意修改后重启才生效。

提示：生产环境要不要永久关 SELinux，要结合公司安全规范来判断。我这里只给结论：自定义安装目录 + 自定义数据目录，在 RHEL 6.4 上关掉 SELinux 确实是最常见做法。但你自己要清楚这个选择的代价，并做好后续的安全补偿措施。

防火墙方面，RHEL 6.4 用的是 iptables，不是 firewalld。远程连不上数据库时，优先检查它。

service iptables status

临时放行 3306：

iptables -I INPUT -p tcp --dport 3306 -j ACCEPT service iptables save

如果要临时全部关闭防火墙且开机不自启：

service iptables stop chkconfig iptables off

关于防火墙，我建议只放行需要的端口，不要动不动就iptables stop，毕竟还有 ssh 等其他服务一起跑在机器上。

4.3 启动验证与日志定位

服务启动后，我习惯按这个顺序验证：先看日志尾部有没有错误，再用 netstat 看端口，最后用 mysql 客户端做一次真实登录。日志是定位问题的第一手资料，不要只盯着启动脚本的输出。

tail -n 100 /var/log/mysql/error.log

如果日志尾部出现：

[Note] /usr/local/mysql/bin/mysqld: ready for connections.

说明已经正常待命了。接下来就能进入登录和改密阶段。

5. 首登改密、远程访问与基本安全

5.1 临时密码登录

初始化时生成的临时密码，现在派上用场了。登录命令：

mysql -uroot -p'临时密码'

如果提示密码错误，回日志里再翻一次临时密码，确认没有记错。还有一个小概率情况：临时密码里包含特殊字符，比如括号、@、#这些，单引号包裹时要注意转义，不然 shell 会先截断字符串。

进入 MySQL 后的第一件事，修改 root 密码。5.7 推荐写法是ALTER USER，不再是老版本的SET PASSWORD。

ALTER USER 'root'@'localhost' IDENTIFIED BY '新的强密码'; FLUSH PRIVILEGES;

5.2 密码策略与 root 改密

MySQL 5.7 默认装了密码校验插件 validate_password，对密码强度有硬性要求：至少 8 位，而且必须包含大写、小写、数字、特殊字符。很多测试环境根本没那么多复杂密码需求，临时降级策略可以这样操作：

SET GLOBAL validate_password_policy=LOW; SET GLOBAL validate_password_length=6;

然后再执行 ALTER USER。需要提醒的是，降低密码策略只适用于测试环境或临时场景，生产数据库该强还是得强。

改密完成后建议退出来重新登录一次，确认新密码生效，避免出现“改完但没刷新连接”的错觉。

5.3 远程登录授权和连接检查

如果这个库要被其他机器上的程序访问，光改 root 密码还不够。默认情况下 root 只允许 localhost 登录，远程连接需要先创建专用账号或给 root 开远程权限。

CREATE USER 'work'@'%' IDENTIFIED BY '远程密码'; GRANT ALL PRIVILEGES ON *.* TO 'work'@'%'; FLUSH PRIVILEGES;

这里要注意，MySQL 5.7 的GRANT ... IDENTIFIED BY写法已经不受欢迎，也不再推荐，正确姿势就是先CREATE USER再GRANT，两步分开。

然后检查监听地址，确保 my.cnf 里没有把 bind-address 写成 127.0.0.1。如果写了，那远程怎么都连不上。要么注释掉 bind-address 行，要么显式写成 0.0.0.0，然后重启服务。

远程客户端检查：

mysql -h 服务器IP -P 3306 -u work -p

连不上时，老规矩排查顺序：服务是否存活、端口是否监听、防火墙是否放行、用户是否 @'%'、bind-address 是否为 0.0.0.0。按这个顺序查，基本都能定位到问题。

6. 高频报错与解决方案速查

6.1 常见报错速查表

老系统离线安装，报错种类翻来覆去就那么几类，我把高频问题整理成表，方便直接对照。

6.2 忘记 root 密码重置

这事我遇过不止一次，尤其是刚接手别人服务器的时候。重置流程本身不难，但有几个细节不能弄错。

先停掉正在运行的服务：

service mysqld stop

然后在/etc/my.cnf的[mysqld]段加上一行：

skip-grant-tables

启动服务：

service mysqld start

这时不需要密码就能进 MySQL：

mysql -uroot

接着执行更新：

UPDATE mysql.user SET authentication_string=PASSWORD('新密码') WHERE User='root' AND Host='localhost'; FLUSH PRIVILEGES;

这里最大的坑是：MySQL 5.7 的 user 表密码字段叫authentication_string，不叫password。很多老教程写的是SET PASSWORD FOR ... = PASSWORD(...)或者直接改 password 字段，到 5.7 上就会报Unknown column 'password'。

更新完成后，把 my.cnf 里加的skip-grant-tables删掉或注释掉，再重启服务。如果忘了删，下一次还能无密码登录，而且权限校验全部被绕过，这在生产环境就是安全事故。

6.3 初始化失败的处理

mysqld --initialize初始化失败时，先别急着重跑，因为反复初始化会把数据目录越搞越乱。正确做法是清空数据目录后重新来。

rm -rf /data/mysql/*

清空后再执行：

/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --initialize --user=mysql

同时检查 /var/log/mysql/error.log 新生成的报错内容。注意日志会追加，多次初始化后日志文件会很长，先tail -n 50看最后一段，大多数情况下根因都在最后几行。

我遇到过的初始化失败原因里，出现频率最高的是三种：数据目录权限不对、SELinux 拦截写入、libaio 缺失。其中权限问题占了一半以上，所以目录属主做完后，用ls -ld /data/mysql确认一下所有者是 mysql 再往下走。

7. 部署完成后的基础验证

安装完并不代表一切结束，我习惯做一组最小化验证来确认服务真的可用。

mysql -uroot -p -e "SELECT VERSION(); SELECT @@port; SELECT @@character_set_server;"

输出里版本号是 5.7.44，端口是 3306，字符集是 utf8mb4，说明基础状态正常。再顺手检查一下开机自启：

chkconfig --list mysqld

服务在 3、4、5 级别上是 on，就说明重启后不会丢服务。

如果这台机器上还要部署其他应用，建议在业务接入前先把我可以想到的监控项配好：3306 端口存活、mysqld 进程存在、数据目录磁盘空间剩余量。磁盘满导致 MySQL 挂掉是运维事故里最冤枉的一种，提前配一条磁盘监控比什么都值钱。

老系统上做离线安装，真正花时间的不是安装动作本身，而是环境细节。libaio 有没有、目录属主对不对、socket 路径一致不一致、二进制包和 glibc 版本匹配不匹配，这些前置问题清理干净，后面基本一路顺风。我个人这几年在 6.x 系列系统上装 MySQL 的体会就一句话：先把系统看明白，再动手，比盲目执行安装命令重要得多。最后再补充一点，网上大量教程默认按 CentOS 7 的 systemctl 操作，你在 RHEL 6.4 上看到 chkconfig、service 这样的方式，才说明那份经验真的来自老环境实践。