1. 为什么放着 Yum 不用非得下载二进制包接手一台新装的 Rocky Linux 8 服务器时我习惯性地执行dnf install mysql-server结果装出来的是 MySQL 8.0。对于跑了好几年 5.7 的老业务来说8.0 的默认认证插件、sql_mode、大小写敏感规则改动太大直接升级等于给自己埋雷。这就是我选择用二进制包安装 MySQL 5.7 的最直接原因。1.1 系统软件源的现实Rocky Linux 8 没有 MySQL 5.7Rocky Linux 8 的 AppStream 软件源中默认提供的是 MySQL 8.0 和 MariaDB 10.3/10.5完全没有 5.7 的踪迹。虽然可以通过启用mysql57模块或者添加第三方仓库来安装但这里有一个很现实的问题第三方仓库的维护节奏和系统本身的安全补丁并不同步而且如果你拉取的仓库里同时存在多个 MySQL 大版本依赖关系会变得非常不可控。我遇到过一位同行为了省事直接添加了一个号称支持 5.7 的第三方仓库结果装到一半发现它把系统的libmysqlclient相关依赖全部替换掉了连dnf自身都受到了影响最后只能重装系统。这种事情不是个例所以我现在对第三方仓库非常谨慎。1.2 二进制安装、源码编译、RPM 安装的三方对比在 Rocky Linux 8 上获得 MySQL 5.7 主要有三条路源码编译、使用 RPM 包、使用官方通用二进制 tarball。三者各有取舍但二进制 tarball 是综合下来最优解。安装方式耗时可控性依赖复杂度适合场景源码编译30-60 分钟取决于机器配置最高可定制编译参数需要安装 cmake、gcc、boost 等大量构建依赖需要特殊定制功能或目标平台极其特殊RPM 包5-10 分钟中等受 RPM 依赖关系约束依赖较多容易冲突系统软件源恰好提供目标版本且无定制需求通用二进制 tarball3-5 分钟高可自定义目录结构、配置文件仅需 libaio 等少数运行库大多数生产环境尤其是需要指定版本的场景源码编译本身时间成本高而且 5.7 的编译对 boost 库版本有硬性要求稍微搭错就得重新来。RPM 的路子在 Rocky Linux 8 上走不通因为默认源压根没有 5.7 的包。二进制 tarball 是官方预先编译好的产品自带对主流 glibc 的兼容下载后解压就能用是效率和安全之间的最佳平衡。1.3 什么情况下你才需要这个方案如果你的业务跑在 MySQL 5.7 上因为各种原因暂时无法升级到 8.0比如老的 ORM、第三方组件只支持 5.7或者 DBA 团队还没完成兼容性适配那这个方案就是为你准备的。同样如果你只是想在 Rocky Linux 8 上快速搭一个独立的 5.7 环境做测试、做数据迁移验证二进制安装也比折腾源更快。反过来说如果你是新项目完全没有历史包袱我建议直接上 MySQL 8.0没必要逆流而行。5.7 官方已经停止更新维护只在某些商业通道还有延长支持装它更多是为了续命现有业务而不是图新鲜。2. 动手前的清单版本确认、依赖检查与目录规划二进制安装虽然步骤不多但前置准备如果缺了后面排查起来会非常难受。提前把版本、用户、依赖和目录想清楚整个安装过程会很顺畅。2.1 选定具体版本5.7.44 是最后的 5.7 版本MySQL 官方发布的 5.7 系列最后一个版本号是 5.7.44后续不再有 5.7 的功能或安全更新。这意味着你需要从哪里获取这个版本官方下载页面保留了历史归档你也可以使用仍然提供该版本的镜像站。下载时要确认的包名格式是mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz。这里有两个关键点linux-glibc2.12表示这个二进制包是为 glibc 2.12 及以上版本编译的。Rocky Linux 8 自带 glibc 2.28满足要求可以正常运行。x86_64指的是 64 位 x86 架构。如果你的服务器是 ARM 架构比如某些云厂商的 ARM 实例需要找对应的 aarch64 版本不要直接拿 x86_64 的硬装。下载命令大致是这样具体链接以官方页面为准wget https://cdn.mysql.com/archives/mysql-5.7/mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz下载完成后顺手校验一下 SHA256 值避免文件损坏或源站被劫持sha256sum mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz2.2 检查运行依赖libaio、ncurses 不能缺MySQL 在初始化数据目录时需要 libaio 库这在很多精简安装的服务器上并不存在。如果你打算用mysql_secure_installation这类基于 curses 界面的工具还需要 ncurses 兼容库。我在一台只有最小化系统组件的机器上初始化时就遇到过mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file的报错错误信息本身已经明确提示了缺失项但如果你不提前检查等初始化失败再回来装就会浪费不少时间。所以提前用一条命令装好依赖dnf install -y libaio ncurses-compat-libs另外可以用strings /usr/lib64/libstdc.so.6 | grep GLIBC快速确认系统 libstdc 版本MySQL 5.7 的二进制包对 C 标准库没有特别新的要求但确认一下总归安心。2.3 规划目录软件、数据、日志三者分离业界推荐的目录设计是软件目录和数据目录分开日志目录独立。这样做的原因是升级时只需要替换软件目录数据目录保持不动排查问题时也能直接在固定位置找到日志不用满盘翻找。我习惯的规划如下# 软件目录 /usr/local/mysql # 数据目录 /data/mysql # 日志目录 /var/log/mysql你可以把这个当作参考但重点在于分离这个思想而不是具体路径。如果你把数据和软件放在同一目录哪天顺手rm -rf了软件目录数据也就跟着没了这种事故在圈内不是没发生过。3. 解压、权限与配置文件这些细节决定了你能不能一次跑起来解压 tarball 本身没有技术含量但后面几步处理不好MySQL 启动时会给你制造各种莫名其妙的麻烦。3.1 解压并建立软件目录软链下载完成后解压到/usr/local下cd /usr/local tar -zxvf /root/mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz解压出来的目录名会带完整版本号比如mysql-5.7.44-linux-glibc2.12-x86_64。我建议建立一个不带版本号的软链方便以后升级ln -s mysql-5.7.44-linux-glibc2.12-x86_64 mysql这样basedir始终保持/usr/local/mysql将来更新版本时只需要解压新版目录并把软链指过去不用改配置文件。3.2 创建 mysql 系统用户并调整目录归属MySQL 出于安全考虑要求以非 root 身份运行。安装过程中需要创建一个专用的系统用户useradd -r -s /bin/false mysql-r表示创建系统用户-s /bin/false表示禁止该用户登录 shell。绝大多数情况下你不需要用 mysql 用户登录系统只需要它在后台运行 mysqld 进程。然后设置目录归属chown -R mysql:mysql /usr/local/mysql chown -R mysql:mysql /data/mysql chown -R mysql:mysql /var/log/mysql注意/usr/local/mysql在后续初始化完成后其实可以把属主改回 root只保留数据目录由 mysql 拥有。但为了图省事很多人全程保持 mysql:mysql 也没问题唯一要权衡的是安全性——如果软件目录可被 mysql 用户写理论上该用户被入侵后可以替换二进制文件。我个人的做法是软件目录属主 root数据目录和日志目录属主 mysql。3.3 配置 /etc/my.cnf每一行都要知道为什么MySQL 启动时默认读取/etc/my.cnf然后依次搜索~/ .my.cnf等文件。为了保证配置文件行为可预期我通常直接编辑/etc/my.cnf并且把基于目录和 socket 的关键参数写清楚。下面是一份我在类似环境下使用的配置你可以直接抄[mysqld] # 基础路径 basedir/usr/local/mysql datadir/data/mysql socket/tmp/mysql.sock pid-file/var/run/mysqld/mysqld.pid # 端口与其他 port3306 server-id1 usermysql # 字符集与排序规则 character-set-serverutf8mb4 collation-serverutf8mb4_general_ci # 存储引擎与事务 default-storage-engineInnoDB innodb_buffer_pool_size1G # 连接数 max_connections500 # 日志 log-error/var/log/mysql/error.log slow_query_log1 slow_query_log_file/var/log/mysql/slow.log long_query_time2 # binlog 相关按需开启 # log-bin/data/mysql/binlog # expire_logs_days7 [client] socket/tmp/mysql.sock default-character-setutf8mb4几个参数的补充说明innodb_buffer_pool_size这是 MySQL 内存占用的核心参数。经验值是物理内存的 50%-70%。如果你机器只有 2G 内存给它 1G 可能就把系统拖垮了需要根据实际情况调整。character-set-server5.7 的默认字符集是latin1如果你建表时没显式指定字符集会出现中文乱码。网上大量的中文乱码问题根源就在这里。统一设置utf8mb4是最稳妥的做法。sql_mode5.7 默认开启了ONLY_FULL_GROUP_BY如果你是从 5.6 或者更早版本迁过来的应用可能会遇到 GROUP BY 相关报错。如果需要平滑过渡可以在[mysqld]下显式设置sql_modeSTRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTIONpid-file所在目录如果不存在启动时会报错。提前创建mkdir -p /var/run/mysqld chown mysql:mysql /var/run/mysqld4. 初始化数据目录与首次启动5.7 和 5.6 的一个分水岭如果你是从 MySQL 5.6 时代走过来的人可能会习惯性地执行mysql_install_db。但是到了 5.7这个脚本已经被废弃了转而推荐直接使用mysqld --initialize来初始化数据目录。4.1--initialize与--initialize-insecure怎么选初始化命令的官方形式是/usr/local/mysql/bin/mysqld --initialize-insecure --usermysql --basedir/usr/local/mysql --datadir/data/mysql--initialize会生成一个随机的临时 root 密码并把密码记录在错误日志中适合对安全要求比较严格的场景。--initialize-insecure则生成一个空密码的 root 账号方便首次登录后再自行修改。我个人的偏好如下如果是生产环境使用--initialize从日志中读取临时密码登录后立即修改。即使你打算用mysql_secure_installation快速设置它也会强制要求先输入临时密码。如果是测试环境使用--initialize-insecure直接mysql -uroot就能进去节省一道工夫。如果你第一次执行后发现报错不要反复重试同一条命令。常见问题是/data/mysql目录里已经残留了部分文件初始化会拒绝覆盖已有的data目录。解决办法是把该目录彻底清空再重新初始化。因为整个数据目录是全新的不用担心清空会破坏什么东西。初始化过程中如果一切正常你会在屏幕上看到 MySQL 打印的一些提示信息然后进程退出没有任何持续的后台服务。很多人以为初始化失败其实只是因为它成功了。4.2 首次启动先别急着开机自启初步启动可以用下面这条命令/usr/local/mysql/bin/mysqld --daemonize --usermysql--daemonize参数会以守护进程方式在后台运行启动后立刻返回 shell 提示符。这种方式的优点是简单直接适合第一次验证安装是否成功。启动完成后留意/var/log/mysql/error.log。如果mysqld正常启动日志末尾会看到ready for connections字样。如果出现Permission denied、Cant create directory、[ERROR]开头的错误大概率是目录权限、SELinux 或配置问题需要回到上一步排查。我用一个通用技巧启动前先看错误日志是否被创建如果日志文件都没有生成说明启动过程在最早期就失败了多半是basedir或datadir配置不对或者二进制文件根本没有执行权限。4.3 配置 systemd 服务让它成为一个正当的系统服务为了后续运维方便建议把 mysqld 交给 systemd 管理。官方 tarball 里其实带了一个support-files/mysql.server脚本你也可以直接写一个 unit 文件来管理我推荐后者因为它更贴合 systemd 的体系日志查看也方便。在/etc/systemd/system/mysqld.service中写入如下内容[Unit] DescriptionMySQL Community Server Afternetwork.target [Service] Typesimple Usermysql Groupmysql ExecStart/usr/local/mysql/bin/mysqld Restarton-failure LimitNOFILE65535 [Install] WantedBymulti-user.target这里有个细节Typesimple表示ExecStart启动的是前台进程mysqld 默认本来就是在前台运行的所以不用额外加--daemonize参数。如果你写了Typeforking反而会因为 mysqld 没有调用 fork 语义而误判启动失败。写好之后systemctl daemon-reload systemctl start mysqld systemctl status mysqld5. 启动后的必做检查临时密码、登录验证与安全加固进程起来之后安装流程只算完成了 70%。接下来的检查直接关系到这个数据库能不能正常投入业务以及后续几天会不会被各种报错淹没。5.1 从错误日志中提取临时密码如果你初始化时用的是--initialize现在去翻错误日志grep temporary password /var/log/mysql/error.log输出里会有一行类似[Note] A temporary password is generated for rootlocalhost: 某串随机字符这里要提醒一点临时密码中可能包含特殊符号在 shell 里直接复制粘贴容易把一些字符吞掉。稳妥的姿势是把密码粘贴到一个临时文件中再在mysql -u root -p提示后粘贴输入。如果这一步失败常用招数是直接编辑/etc/my.cnf添加一行skip-grant-tables重启 mysqld然后无密码登录后手动重置密码重置完再删掉该行。这是近乎万能钥匙的手段但生产环境要慎用——拿掉权限验证意味着任何人只要登进系统就能任意操作数据库。登录后第一件事是修改 root 密码ALTER USER rootlocalhost IDENTIFIED BY 你的新密码; FLUSH PRIVILEGES;注意 MySQL 5.7 默认启用validate_password插件密码强度不够比如少于 8 位、只有纯数字会被直接拒绝。如果你打算用简单密码做测试得先调整策略SET GLOBAL validate_password_policy LOW;5.2mysql_secure_installation该跑还是得跑官方提供的mysql_secure_installation工具能快速收拾几个安全死角设置 root 密码、删除匿名用户、禁止 root 远程登录、删除 test 库。它在 5.7 下是随二进制包一起发布的路径为/usr/local/mysql/bin/mysql_secure_installation。我见过一些人因为嫌交互式提问烦而跳过这一步结果留下了一个没设密码的匿名用户用mysql -u root就能进去这在公网环境下非常危险。所以我的建议是跑一遍整个过程两分钟不到。跑完之后用如下命令验证状态/usr/local/mysql/bin/mysql -u root -p -e SELECT user, host, authentication_string FROM mysql.user;正常输出应只保留rootlocalhost和后续你新建的业务账号。5.3 端口监听与自启动验证检查 MySQL 是否在监听预期端口ss -tlnp | grep 3306如果输出为空多半是 mysqld 没起来或者被 firewalld 拦在外面。Rocky Linux 8 默认启用 firewalld需要在防火墙中放行端口firewall-cmd --permanent --add-port3306/tcp firewall-cmd --reload最后启用开机自启systemctl enable mysqld systemctl enable mysqld.service这里多说一句很多人在云服务器上遇到外部连不上 MySQL的问题排查时只盯着安全组和防火墙的 TCP 3306 端口最后却发现 mysqld 实际监听的地址是127.0.0.1。如果确实需要远程连接请在my.cnf中显式设置bind-address0.0.0.0而不是默认的本地回环。6. 实测中踩过的坑与排查思路即使前面每一步都按标准来实际运行时依然可能遇到各种问题。这一节我把几个高频坑位列出来并给出排查思路而不是直接给你一条救火命令因为只有理解了原因你才能举一反三。6.1 SELinux 拦截导致无法创建文件或绑定端口Rocky Linux 8 默认开启 SELinux模式为 enforcing。MySQL 的数据目录如果不在系统预设的安全上下文范围内比如你自定义了/data/mysql启动时可能会出现mysqld: Cant create/write to file /data/mysql/... (Errcode: 13 - Permission denied)。这个报错非常容易让人误判为权限问题然后去chmod -R 777结果除了让数据目录变成全网裸奔之外毫无作用。真正的解法是修改目录的 SELinux 上下文semanage fcontext -a -t mysqld_db_t /data/mysql(/.*)? restorecon -Rv /data/mysql如果没有semanage先安装工具包dnf install -y policycoreutils-python-utils另一种临时验证方案setenforce 0临时关闭 SELinux再启动 mysqld。如果能正常启动基本可以确定是 SELinux 的拦截。但记得排查结束后马上恢复setenforce 1不要为了省事长期关闭。6.2 初始化失败内存不足比你想的更常见在只有 1G 内存的小机器上执行mysqld --initialize有时会直接卡住或者报内存分配失败。这是因为初始化过程也会按照配置加载 InnoDB buffer pool如果你的innodb_buffer_pool_size设置得过大比如 512M再叠加其他进程的内存占用就直接把机器内存吃满了。排查方法初始化时先临时用一个极简配置或者在命令行中覆盖参数/usr/local/mysql/bin/mysqld --initialize-insecure --usermysql --basedir/usr/local/mysql --datadir/data/mysql --innodb-buffer-pool-size256M初始化成功之后再按正常配置启动服务。这条经验来自一位朋友他在云厂商最低配机器上折腾了好几天都没装上 MySQL最后发现是 buffer pool 配置的问题。6.3 老应用连接报Authentication plugin caching_sha2_password错误这个问题严格来说不是二进制安装特有的而是从 8.0 降级到 5.7 时常见的反面坑如果你之前用的是 8.0应用连接端可能绑定了新认证插件而 5.7 默认的认证插件是mysql_native_password。如果你反向操作——在 5.7 上想让某些老客户端兼容需要确认用户的plugin字段。SELECT user, host, plugin FROM mysql.user WHERE user业务账号;如果需要显式指定兼容插件ALTER USER 业务账号% IDENTIFIED WITH mysql_native_password BY 密码;很多时候从 5.7 迁移到 8.0 遇到的问题都可以通过把用户插件改回mysql_native_password解决。这类兼容性问题在新旧版本交替时几乎必然会遇到提前了解处理方式能省下不少查日志的时间。6.4 socket 文件权限与客户端连接时的玄学问题5.7 默认的 socket 文件位于/tmp/mysql.sock。在 systemd 的PrivateTmp开启时mysqld 进程可能把 socket 文件写到了私有的临时目录而客户端工具却去/tmp查找导致明明mysql -uroot -p就是连不上报Cant connect to local MySQL server through socket /tmp/mysql.sock。解法有两个方向在my.cnf中显式把socket指定到固定路径比如/var/run/mysqld/mysqld.sock客户端连接时使用--socket/var/run/mysqld/mysqld.sock。这个坑在 CentOS 6 时代比较少见因为那时 mysqld 通常跑在直接控制台上而普及 systemd 之后socket 路径问题开始高频出现。建议一概在my.cnf中把socket路径固定到一个全局可读的目录并确保该目录的权限为 mysql 用户可写。最后再分享一个小习惯安装完成后把bin目录下的常用工具软链到/usr/local/bin这样你就能直接使用mysql、mysqldump这类命令而不用每次都输入全路径ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql ln -s /usr/local/mysql/bin/mysqldump /usr/local/bin/mysqldump ln -s /usr/local/mysql/bin/mysqladmin /usr/local/bin/mysqladmin我个人坚持在文档里记录下整个安装过程包括版本号、下载链接、所有自定义目录和参数说明。将来不管是换人接手还是自己半年后再维护都能快速恢复上下文比临时翻聊天记录可靠得多。