1. 升级前先想清楚为什么升、风险在哪前两天接了一个升级工单把一台跑了近两年的MySQL从5.7升到8.0。接手前我以为这活儿不复杂——下载新版本、停库、替换二进制、启动最多再跑一遍upgrade脚本半天应该能搞定。真正落地才发现MySQL升级这件事难的不是“装新版”而是升级过程里的兼容性迁移、数据安全和业务无感切换。特别是当你的业务系统里还跑着老存储过程、老驱动、老连接池配置的时候每一步都可能变成坑。这篇文章我把整个升级过程踩过的坑、列过的检查项、写过的脚本和最终验证方案都整理一遍适合这几类人看正在准备给线上MySQL做版本升级的DBA或运维同学、跑着MySQL 5.7想升8.0但迟迟不敢动手的全栈开发、以及所有要把“升级”当成一次正经项目来推进的同行。看完你至少能知道升级前要准备什么、升级中每一步在做什么、升级后怎么确认业务真的没受影响。先说结论MySQL升级本质上是“一次有计划的数据搬迁加一次兼容性适配”。所谓搬迁是因为数据库不只是几个文件它上面挂着结构定义、权限体系、配置参数、插件、存储过程、事件调度器、binlog位点这些都要跟着版本一起走所谓适配是因为新版本对老版本的行为约定可能完全不认账。MySQL官方文档里把大版本升级定义为一次“不可逆的数据库迁移事件”这个定位非常准确——一旦跨版本升级向下兼容是不保证的回滚的成本远高于预防的成本。1.1 升级不是“装新版”而是兼容性迁移MySQL 5.7和8.0之间的差异远不止版本号上的一个数字。我挑几个升级后最容易爆雷的点提前给你打个预防针认证插件从mysql_native_password换成caching_sha2_password。老版本的客户端驱动、老版本的Navicat、老版本连接池默认不认新插件连上就报Authentication plugin caching_sha2_password cannot be loaded。系统表结构从MyISAM全部换成InnoDB元数据的管理方式变了以前能在.frm文件里看到的表结构定义在8.0里直接看不到了。默认字符集排序规则从utf8mb4_general_ci变成utf8mb4_0900_ai_ci如果业务里对排序结果有依赖这里要重新验证。SQL模式默认值变严格了ONLY_FULL_GROUP_BY、NO_ZERO_DATE、NO_ZERO_IN_DATE、STRICT_TRANS_TABLES默认开启。以前能跑的SQL升级后可能直接报错。隐式类型转换行为变了数值和字符比较的规则更严格可能出现原来走索引的SQL升级后索引失效。8.0里一些老参数直接被移除比如query_cache_size、innodb_file_format、innodb_large_prefix配置文件里还写着这些参数MySQL可能直接启动失败。这些差异决定了你的升级方案不能是“把文件拷过去就完事”而是要先做一轮全量的兼容性体检确认业务SQL、存储过程、配置项都在新版本里还能正常工作。1.2 数据量越大兼容性成本越高我这次升级的库总共1.2TB核心表最大的一张超过200GBbinlog一天能产生80GB。这种规模下任何“跑一遍脚本就完事”的幻想都会被打碎。你需要注意三个数字备份耗时物理备份全库用了将近4个小时升级耗时mysqld启动后的数据字典升级跑了将近40分钟验证耗时全库逻辑导出校验跑了6个多小时。所以升级窗口的估算绝不能只算“停库几分钟”而是要把备份、传输、升级、校验全链路的时间都算进去。很多团队升级翻车就是低估了这个总时长最后凌晨三点发现窗口不够被迫带着半升级状态硬扛业务高峰。1.3 升级路径怎么选in-place还是逻辑迁移两条主流路线我直接给结论同机rpm替换in-place升级数据文件原地保留安装新版本后启动时自动升级数据字典。耗时相对短适合版本跨度不大、环境相对标准化的场景。5.7升8.0走这条路最常用。逻辑迁移mysqldump导出导入或xtrabackup备份恢复到新实例数据重新导入天然解决了结构、数据、权限的兼容性问题适合跨大版本、异构环境、或者顺便要换服务器换系统的场景。缺点是时间长导入导出对业务影响大。我用的是两者结合先用xtrabackup做物理全备把数据恢复到一台新服务器上在新服务器上执行rpm升级验证确认没问题后再回头处理原机的升级。这样既有了“先验证后操作”的安全垫又不至于被逻辑导入导出的时间拖垮。2. 升级前必须做好的三件事很多升级事故问题出在准备工作做得不够。MySQL升级前有三件事缺一件都别动手。2.1 全套备份加恢复演练不是“备份”而是“能恢复”备份不是执行一条命令就完了而是要确认备份文件能真正恢复出可用的数据。我这里说的“可用”有三个层次备份文件本身完整没有损坏恢复出的数据能启动能查询恢复出的数据能和原库的binlog位点对上能继续追增量。mysqldump做逻辑备份时要注意参数别只写一句mysqldump -uroot -p --all-databases backup.sql就交差。我这边实际用的备份策略是双轨并行物理备份用xtrabackup做全备加增量备份期间记录binlog文件名和位点逻辑备份用mysqldump加--single-transaction --quick --routines --events --triggers --hex-blob确保存储过程、事件、触发器、二进制类型都完整导出。恢复演练至少要做两次一次在测试机上验证备份能恢复一次在备用机上验证恢复出来的数据能被业务SQL正常查询。很多人跳过演练直接升我劝你千万别学——备份不能恢复的时候它只是一堆占用磁盘空间的无用数据。2.2 兼容性体检把检查项列成清单升级前我建议你把下面这些检查项整理成一张表逐项确认检查项检查方法关注点存储过程、函数、触发器、事件数量select count(*) from information_schema.routines;等升级后这些对象是否全部保留老SQL模式依赖select sql_mode;并对比业务代码中依赖默认值的SQL升级后默认值行为是否变化保留字和字段名检查建表语句、SQL中是否使用新版本保留字8.0新增了部分保留字可能导致SQL解析失败字符集和排序规则select table_schema, default_character_set_name from information_schema.schemata;排序行为变化是否影响业务失效索引select table_name, index_name from information_schema.statistics;隐式转换、索引失效问题老参数引用检查my.cnf中是否有8.0已移除的参数配置文件报错导致启动失败这一步不要省尤其是业务系统如果经过了多年迭代没人能拍胸脯保证所有SQL都规范。体检越细升级后的惊吓越少。2.3 升级窗口和回滚预案升级窗口建议选业务低峰期并且至少预留出“备份耗时升级耗时验证耗时”两倍的时间buffer。回滚预案要提前写好保留旧版本的rpm安装包upsream的数据目录完整副本留一份在原位或备份盘上。升级出问题的时候能停掉新版本、恢复旧数据目录、重新启动老版本这个操作必须提前演练一遍而不是等到出问题再查文档。3. Linux环境下rpm方式升级实操从5.7到8.0下面进入正题这节内容是整个升级过程的核心我按实际操作顺序展开。3.1 环境整理和旧版本信息采集升级前先摸清家底。这一步我在原机上执行了这些命令把关键信息落到文本文件里保存# 确认当前版本 mysql -uroot -p -e select version(); # 查看插件加载情况 mysql -uroot -p -e show plugins; # 查看当前生效的全部参数 mysql -uroot -p -e show variables; # 查看数据库、表、存储过程等对象清单 mysql -uroot -p -e select table_schema, count(*) from information_schema.tables group by table_schema; select routine_schema, count(*) from information_schema.routines group by routine_schema; # 确认配置文件路径和内容 mysql --help | grep -A 1 Default options cat /etc/my.cnf这一步容易踩的坑是my.cnf里有大量历史遗留参数有些参数你可能已经忘了为什么加进去。升级到8.0后参数名变化、参数被移除的情况很常见。我这次就遇到query_cache_type和query_cache_size直接导致mysqld无法启动——8.0把查询缓存整个移除了配置里残留的这两个参数必须删掉。建议升级前用这个命令做一次参数校验逐条确认哪些参数在新版本里还存在哪些已经被改名或移除mysqld --verbose --help | grep -E query_cache|innodb_file_format|innodb_large_prefix如果没有任何输出说明这些参数在新版本里已经不存在了必须从配置文件里清掉。3.2 关停业务前最后的数据确认升级窗口正式开始时先不要急着重启数据库。按这个顺序来通知业务侧进入只读维护状态对外页面按流程挂维护通知让用户知道这段时间系统在升级。在MySQL里执行FLUSH TABLES WITH READ LOCK;把内存里的脏页强制刷盘保证数据文件处于一致状态。执行SHOW MASTER STATUS;记录当前binlog文件名和Position。再做一次全量物理备份确认备份完成后才解除锁。执行SHOW MASTER STATUS;再次确认位点没有变化。用/etc/init.d/mysql stop或systemctl stop mysqld关停数据库。这里我要特别强调第4步很多人以为备份在升级前一晚做过了升级窗口开始时就不用再做。但备份和升级窗口之间业务还在写入binlog还在增长。你升级用的“基线数据”必须是最新、最一致的那一份。所以窗口内再补一次全备不是多余是保险。3.3 安装新版本rpm包我这次是在CentOS 7环境上操作用的是官方Yum仓库的方式。大致流程如下先确认系统里已安装的MySQL相关包避免和旧版本冲突rpm -qa | grep -i mysql然后下载并安装官方仓库配置包。这里要注意5.7和8.0的仓库配置包是区分开的直接装对应的release包即可# 下载mysql 8.0的仓库配置包 wget https://repo.mysql.com/mysql80-community-release-el7-7.noarch.rpm # 安装仓库配置 rpm -ivh mysql80-community-release-el7-7.noarch.rpm # 安装8.0社区版服务端 yum install mysql-community-server -y安装过程中yum会自动处理依赖但要注意几点如果之前安装的是5.7版本建议先移除5.7的server包但保留数据目录。数据目录一般在/var/lib/mysql不要动它。如果直接yum update可能会把5.7自动替换成8.0这种情况下更要谨慎确认数据目录没有被初始化流程覆盖。安装完成先不要急着启动服务。先看看数据目录里的文件是否完整特别是ibdata1、ib_logfile0、mysql目录这些关键文件。这里有个容易被忽略的细节5.7升级到8.0时mysqld第一次启动会执行数据字典的自动升级。这个阶段mysqld的日志里会输出大量[Note] InnoDB: Upgrading...之类的内容耗时和你库的大小直接相关。我这次1.2TB的库这个阶段跑了将近40分钟。期间绝对不能强制kill进程、绝对不能重启机器否则数据字典会处于半升级状态后续基本没法救。启动前检查一下配置文件把8.0里已经移除的参数注释掉。我整理的配置文件改动清单[mysqld] # 8.0已移除必须删除 # query_cache_type0 # query_cache_size0 # 8.0建议显式配置 character-set-serverutf8mb4 collation-serverutf8mb4_0900_ai_ci # 老客户端兼容视情况开启 # default-authentication-pluginmysql_native_password启动命令systemctl start mysqld启动后立刻查看错误日志tail -f /var/log/mysqld.log如果你走到这一步日志里没有出现[ERROR]级别的错误说明数据字典升级顺利。3.4 升级后的数据校验和存储过程专项检查mysqld第一次启动会自动完成数据字典升级但“启动成功”不等于“数据没问题”。我升级完第一件事是执行全库校验确认引擎层数据文件没问题mysqlcheck -uroot -p --all-databases --check-upgrade这个命令会把所有表都检查一遍发现不一致会直接报错。同时还要验证几类容易被忽略的对象存储过程和函数升级后语法解析规则可能变化以前能创建的存储过程可能因为新版本保留了字或者SQL模式变化而无法执行。我建议逐个库调用SHOW PROCEDURE STATUS;确认对象存在再抽样执行几个核心存储过程确认返回结果和升级前一致。事件调度器确认EVENT还在且event_scheduler参数状态正确。触发器用SHOW TRIGGERS;确认都在。这个过程里我踩了一个比较典型的坑业务里有个存储过程依赖NO_ZERO_DATE这个非严格模式。5.7的默认sql_mode是ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION8.0把NO_AUTO_CREATE_USER移除了但严格控制行为整体是趋严的。那个存储过程在8.0默认模式下跑直接报错后来确认是插入语句里用了0000-00-00这种零日期需要在会话级别把NO_ZERO_DATE加回去才能兼容。这个问题如果提前没有业务sql_list的review升级后再排查就会很被动。建议升级窗口内预留一段时间让业务侧配合跑一遍核心接口的回归测试尤其是涉及写入、日期处理、聚合查询的接口。4. 升级后的配置调优与常见报错排查升级完成、数据校验通过不意味着可以松口气。8.0的默认配置和5.7不太一样很多参数如果不主动调优性能可能反而不如升级前。同时客户端连接层的问题也会在升级后集中爆发。4.1 升级完成后第一时间要调整的配置内存参数8.0默认的innodb_buffer_pool_size是128MB这显然不是给生产库用的。我按物理内存的60%~70%来设置比如机器128GB内存设成80GB左右起步再根据命中率微调。binlog策略8.0默认开启binlogexpire_logs_days参数被改名为binlog_expire_logs_seconds。旧配置里写着expire_logs_days7的升级后实际不会生效必须改成binlog_expire_logs_seconds604800。连接数确认max_connections是否还够用8.0的线程模型有些变化连接数设置过大会占用额外内存。慢查询slow_query_logON、long_query_time2这类参数保持和升级前一致方便对比升级后的性能变化。undo表空间8.0的undo是自动管理的不再需要手动配置innodb_undo_tablespaces这类参数。4.2 客户端连接层驱动、SSL、字符集升级后连接层报错是另一个高频翻车现场。最常见的有三种第一种是驱动版本太老。5.7时期的JDBC驱动、PHP mysqli扩展、Python mysqlclient默认不认8.0的caching_sha2_password认证插件连接时报Authentication plugin caching_sha2_password cannot be loaded。解决方式有两个升级客户端驱动到支持8.0的版本或者如果业务侧暂时没法升级驱动在MySQL侧做兼容处理把默认认证插件改回老插件。但我不建议长期走这条路8.0.28之后MySQL已经把这个参数改名并且逐渐弱化老插件的支持力度只会越来越低迟早要升级驱动。第二种是Navicat等图形化工具连不上8.0。老版本Navicat默认不支持8.0的认证方式升级到支持MySQL 8.0的新版客户端即可解决。这里顺便说一句工具连接不上优先考虑官方客户端升级别在旧工具的“破解补丁”上浪费时间那些方案既不安全也解决不了协议层面的问题。第三种是SSL连接错误。8.0默认开启SSL客户端如果走非本地TCP连接服务端会要求安全的传输通道或者至少完成公钥交换。老驱动如果没有配置SSL或者不支持RSA公钥交换客户端会报Unable to connect to any of the specified MySQL hosts这类错误。排查思路是确认驱动支持新认证确认连接串里有没有配置SSL相关的参数如果业务环境是内网低风险可以在MySQL侧关闭强制SSL设置require_secure_transportOFF让老驱动先用非加密通道连接起来再逐步过渡。字符集方面8.0默认utf8mb4_0900_ai_ci如果你的连接串没有显式指定characterEncodingutf8mb4老应用可能出现乱码或者排序不一致。这个比较容易排查但难在可能影响到的业务点位很分散建议升级前就用连接串统一规范。4.3 高频报错排查表把升级过程中最容易遇见的报错整理成一个速查表方便你直接对照报错现象可能原因处理方式Authentication plugin caching_sha2_password cannot be loaded客户端驱动不支持8.0认证插件升级驱动或临时把用户改回mysql_native_passwordUnknown system variable query_cache_size配置文件残留8.0已移除参数删除配置中query_cache_type、query_cache_sizeAccess denied for user xxxx升级后权限表变了确认连接用户是否在8.0中存在必要时重建权限Lost connection to MySQL server during querymax_allowed_packet设置过小调大max_allowed_packet并同步确认客户端连接参数InnoDB: Table xxx doesnt exist in engine表元数据不一致用mysqlcheck --repair修复或从备份恢复该表启动报错缺少libcrypto.so.1.1等动态库系统环境依赖和MySQL新版本不匹配检查openssl、glibc版本按官方要求安装依赖SQL执行报错Expression #N of SELECT list is not in GROUP BY clause8.0默认开启ONLY_FULL_GROUP_BY修改SQL或调整会话级sql_mode这里特别说一下“升级了某个系统组件但程序还是用的旧版本”这个问题。升级MySQL的时候如果遇到依赖库版本不对很多同学第一反应是去升级openssl、升级glibc、升级gcc但升级完发现ldd mysqld依然显示旧版本路径。这通常不是升级没成功而是动态链接器缓存没有刷新或者程序链接了绝对路径下的旧库。排查思路ldd /usr/sbin/mysqld | grep -E ssl|crypto如果发现指向的是旧路径可以检查LD_LIBRARY_PATH环境变量、/etc/ld.so.conf里的配置执行ldconfig刷新缓存后再试。系统组件升级这个事情优先级一定要排在MySQL升级之后——先把MySQL升上去如果确实缺依赖再针对性补别本末倒置否则可能把系统搞到不可用的状态。5. 升级过程中的心得和小技巧整个流程走下来我自己最大的体会是MySQL升级不是一个“技术动作”而是一个“项目”。技术动作只是其中一部分更关键的是把升级窗口、业务影响、回滚方案、验收标准全部拉齐让各个环节的人都清楚自己在什么时间点做什么。有几个小技巧常规文档里不会写但对实操帮助很大升级前把my.cnf完整保存一份带时间戳的副本升级后每次启动出问题先对比新旧配置节省大量排查时间。8.0第一次启动会自动升级数据字典但升级进度不会实时输出到终端而是在错误日志里。升级期间建议单独开一个终端持续tail -f /var/log/mysqld.log看到[Note] InnoDB: Upgrade of the data dictionary completed类似内容才说明这个阶段结束了。别着急执行下一步。备份文件的校验不能只看文件大小要真正去恢复一遍。我这次升级就靠恢复演练发现了一个备份遗漏有台实例的EVENT没有出现在逻辑备份里原因是最早的备份脚本漏了--events参数。再分享一个回滚的小经验升级完成后保留旧版本的rpm包和原数据目录不要急着清理。我之前有次升级因为业务验证拖了比较久顺手把旧包删了。后来真出了问题想回滚发现旧版本根本装不回来只能硬着头皮在原版本上修。后来我就养成了习惯升级成功后至少保留旧包两周确认新版本稳定运行后再清理。最后补充一点如果业务对可用性要求极高常规的在位升级方式可能不太适合你。更稳妥的路子是搭一套独立的8.0新实例做主从同步把数据追平然后做一次主从切换。这个方案对业务的影响最小但架构成本和运维复杂度会高不少。我个人观点是先根据自己业务的容忍度选好升级方式再按这篇文章的流程走至少能避免绝大部分升级事故。