mysql通过RPM包升级与手动编译升级的比较

RPM升级常致mysqld启动失败，因覆盖文件却不迁移配置：废弃参数（如query_cache_type）、插件路径斜杠敏感、systemd未重载；编译升级需显式指定安装与数据目录；8.0+弃用mysql_upgrade，改用--upgrade=FORCE；备份须兼顾逻辑与物理，且注意SELinux上下文。

RPM 升级为什么常导致 mysqld 启动失败

RPM 包升级（如 rpm -Uvh mysql-community-server-8.0.33-1.el7.x86_64.rpm）会覆盖 /usr/bin/mysqld、/etc/my.cnf 模板和 systemd unit 文件，但不会自动迁移或校验你的自定义配置。常见失败点包括：

• my.cnf 中残留已废弃参数（如 query_cache_type

  

  在 8.0+ 被移除），导致 mysqld --validate-config 报错
• 插件路径变更（plugin_dir 从 /usr/lib64/mysql/plugin 变为 /usr/lib64/mysql/plugin/ 末尾斜杠敏感），INSTALL PLUGIN 失败
• systemd 服务文件未重载（systemctl daemon-reload 忘记执行），systemctl start mysqld 找不到新二进制路径

手动编译升级时 make install 的关键控制点

源码编译（如 MySQL 8.0.x）不是“替换二进制”那么简单，make install 默认行为极易引发权限与路径混乱：

• 务必用 -DCMAKE_INSTALL_PREFIX=/usr/local/mysql8 显式指定独立安装路径，避免覆盖旧实例
• 必须同步设置 -DMYSQL_DATADIR=/var/lib/mysql8，否则 mysqld --initialize 仍写入旧 datadir，引发元数据不一致
• mysql-systemd-start 脚本不会自动生成，需手动复制或重写 systemd service 文件，其中 EnvironmentFile 和 ExecStart 路径必须与编译参数严格匹配

cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql8 \
      -DMYSQL_DATADIR=/var/lib/mysql8 \
      -DDEFAULT_CHARSET=utf8mb4 \
      -DDEFAULT_COLLATION=utf8mb4_0900_ai_ci \
      -DWITH_BOOST=../boost

升级后 mysql_upgrade 已被弃用，该用什么

MySQL 5.7 之前靠 mysql_upgrade 修复系统表结构，但 8.0.16+ 彻底移除该命令。实际升级后必须做的是：

• 启动新 mysqld 时加 --upgrade=FORCE 参数（默认是 AUTO，可能跳过必要更新）
• 确认错误日志中出现 Upgrading system tables. 和 Finished upgrading system tables. 两行才代表完成
• 若中途失败，不能反复重启——必须先用 mysqld --no-defaults --bootstrap 手动执行 mysql_system_tables.sql 等脚本恢复基础表

备份策略在两种升级方式下的实质差异

RPM 升级看似“一键”，但它的原子性仅限于包管理层面；手动编译则完全无回滚机制。二者都绕不开同一底线：

• RPM 升级前必须停机并执行 mysqldump --all-databases --single-transaction > backup.sql，因为 yum update 不保证数据目录兼容性
• 编译升级前除逻辑备份外，还必须做物理备份：rsync -aHAX --delete /var/lib/mysql/ /backup/mysql-8.0.33/，因 mysqld --initialize 会重置 root 密码且不可逆
• 无论哪种方式，升级后首次连接必须用 mysql --socket=/var/lib/mysql8/mysql.sock -u root -p 显式指定 socket，避免连错旧实例

升级最易被忽略的其实是 SELinux 上下文——RPM 包自带 mysql_exec_t 标签，而手动编译安装的二进制默认是 unconfined_exec_t，setsebool -P mysql_connect_any on 都救不了权限拒绝。