在 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 方式的依赖解析会让你想砸电脑。我直接把两种方式的优缺点列个表大家自己对照。对比项RPM Bundle二进制 tar.gz 包依赖数量多需 perl、libaio、ncurses、jemalloc 等一长串少核心就 libaio离线友好度差缺一个 rpm 就卡死好基本补一个依赖就够目录管理分散在 /usr/bin、/var/lib/mysql、/etc 等多处集中在单一目录如 /usr/local/mysql卸载迁移需 rpm -e 清理且要处理数据保留停服后直接删目录或拷贝目录版本兼容新版本对 el6 的 rpm 支持逐渐减少glibc 2.12 通用包对老系统更友好服务脚本自带 systemd/init 脚本自带 mysql.server需手动放置我最终选的是二进制 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 -n1RHEL 6.4 默认自带的是 glibc 2.12所以你在官方下载页面选择时操作系统那一项要选Linux - GenericOS 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.rpmlibaio 这个包比较干净依赖很少一般不需要额外处理。少数情况下还缺数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.cnfMySQL 5.7 会按顺序读取多个配置文件最终生效的位置是/etc/my.cnf。生产环境我就直接写这一个文件避免多个配置文件混在一起造成参数覆盖时定位困难。以下是我在 RHEL 6.4 老服务器上常用的基础配置[mysqld] usermysql basedir/usr/local/mysql datadir/data/mysql socket/tmp/mysql.sock pid-file/data/mysql/mysqld.pid log-error/var/log/mysql/error.log port3306 character-set-serverutf8mb4 collation-serverutf8mb4_general_ci [client] socket/tmp/mysql.sock default-character-setutf8mb4这里有几个值得解释的地方。usermysql让 mysqld 启动后切换为 mysql 用户运行避免以 root 身份承载数据库进程降低安全风险。socket路径写 /tmp/mysql.sock 是为了兼容大多数客户端默认值如果换成一个不太常见的路径那后面执行 mysql 命令时必须手动加--socketxxx少写一步就连不上。character-set-serverutf8mb4是给数据库默认字符集现在主流应用都要存 emojiutf8mb4 是必须的。注意内存参数先别急着抄网上的大神调优配置。老服务器内存有限什么 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 --usermysql执行后重点观察/var/log/mysql/error.log。初始化成功时日志尾部会有一行形如[Note] A temporary password is generated for rootlocalhost: 某个临时密码这个临时密码必须第一时间记下来因为首次登录 root 只能用这串东西。几个关键点要特别强调第一不要用--initialize-insecure除非你想让 root 初始密码为空。测试环境无所谓生产环境不建议。第二初始化只做一次。数据目录一旦生成重复初始化会报错或把已有目录搞脏。如果确实要重来最稳妥的是清空数据目录再执行。第三如果初始化时报了类似Cant 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 onchkconfig --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把SELINUXenforcing改成disabled注意修改后重启才生效。提示生产环境要不要永久关 SELinux要结合公司安全规范来判断。我这里只给结论自定义安装目录 自定义数据目录在 RHEL 6.4 上关掉 SELinux 确实是最常见做法。但你自己要清楚这个选择的代价并做好后续的安全补偿措施。防火墙方面RHEL 6.4 用的是 iptables不是 firewalld。远程连不上数据库时优先检查它。service iptables status临时放行 3306iptables -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 rootlocalhost IDENTIFIED BY 新的强密码; FLUSH PRIVILEGES;5.2 密码策略与 root 改密MySQL 5.7 默认装了密码校验插件 validate_password对密码强度有硬性要求至少 8 位而且必须包含大写、小写、数字、特殊字符。很多测试环境根本没那么多复杂密码需求临时降级策略可以这样操作SET GLOBAL validate_password_policyLOW; SET GLOBAL validate_password_length6;然后再执行 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 常见报错速查表老系统离线安装报错种类翻来覆去就那么几类我把高频问题整理成表方便直接对照。现场报错可能原因处理办法error while loading shared libraries: libaio.so.1缺少 libaio 动态库用本地 rpm 补装 libaioGLIBC_2.14 not found误下 glibc 2.17 或 el7 版本包换成 glibc 2.12 通用包Cant connect through socket /tmp/mysql.socksocket 路径不一致核对 my.cnf 与客户端连接参数Access denied for user rootlocalhost (using password: YES)临时密码错误或已失效回日志翻临时密码必要时重置ERROR 1819: Your password does not satisfy密码策略太严格降级 validate_password 策略Cant open the mysql.plugin table数据目录残留或初始化不完整清空数据目录后重新初始化Failed to start mysqld数据目录权限/SELinux 拦截chown 恢复属主临时关 SELinux 验证Unknown column password误用旧版重置语法改用 authentication_string 字段6.2 忘记 root 密码重置这事我遇过不止一次尤其是刚接手别人服务器的时候。重置流程本身不难但有几个细节不能弄错。先停掉正在运行的服务service mysqld stop然后在/etc/my.cnf的[mysqld]段加上一行skip-grant-tables启动服务service mysqld start这时不需要密码就能进 MySQLmysql -uroot接着执行更新UPDATE mysql.user SET authentication_stringPASSWORD(新密码) WHERE Userroot AND Hostlocalhost; 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 --usermysql同时检查 /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 这样的方式才说明那份经验真的来自老环境实践。
