分享一次生产服务MySQL升级历程

2022开年第一篇原创还希望大家多多支持，本篇文章分享一次线上服务数据库升级日志，在过程与结果权衡之间、实际碰到的问题、以及后期复盘总结的相关建议，希望能给各位测试、开发朋友带来实质性帮助，也希望后期各位测试大佬，在碰到类似问题，可以像我一样发言给出观点

一、升级背景

根据公司安全新红线宣导进行整改, 禁止使用已停止维护的版本第三方软件，其中某某服务的MySQL数据库5.6版本已到停止维护时间，故将其版本进行升级至5.7

二、升级人员与时间

研发：XX、XX、XX

测试：XX

计划时间：2022.01.11 1:00

三、升级预期方案

1. KAE开启数据迁移任务
2. 新建5.7某某服务
3. 确认同步状态
4. 部署只包含账号合并接口的服务（凌晨1点操作）
5. 停止5.6版本某某全部服务（凌晨1点操作）
6. 数据比对
7. KAE终止数据迁移
8. 修改灰度lb为新的某某
9. 开放外网
10. 删除账号合并的路由
11. 补充需要合并的账号

注：详细流程涉及私密信息不方便透漏

四、升级历程时间轴

开始前置动作

• 开启数据迁移任务
• 新建某某5.7服务
• 确认全量数据同步完成

1.30 开启账号合并服务

1:32 停止线上服务

1:35 新旧库数据表字段对比

1.51 停止数据迁移

1:53 恢复线上服务

实际停服务时间大概23分钟

1:55 自动化验证接口服务

2:02 手动验证前端界面功能

2:10 合并账户数据补录

2:15 手动验证内网安卓端、wen端、PC端前端界面功能

2:30 手动验证外网web端前端界面功能

2.35 迁移完毕

后续监控措施：新旧服务线上接口巡检，时间间隔20min/次

五、升级改进与建议

事件1：进行迁移之前置身用户去考虑实际停服给用户带来的体验与影响

实际表现：

在测试环境进行模拟停服操作，测试人员进行模拟用户正在前端编辑文本操作，停服之后，前端界面无明显感知&友好提示信息，可能会导致用户继续持续输出文本，在此期间数据保存同步失败，后续进行刷新点击其它操作会导致停服之后录入的文本数据丢失，给用户带来不好的体验

改进措施：

1.可以在各端页面顶部新增适配滚顶小黄条，在类似打升级或者停服期间提前将此信息告知到用户，提前预告(例如：尊敬的用户您好：某某服务于2022.1.10 凌晨1:00进行升级服务，请大家在此期间不要进行任何操作，恢复时间预计...)

2.针对某某当前产品形态，停服对用户最大的影响就是增、改数据丢失，再次我们可以在停服、网络中断之后，用户继续操作前端进行有好的toast提示(例如：网络已中断，请勿在进行操作..) 减少用户数据丢失的风险

事件2：数据对比过程中，想缩短停服时间，提前把lb指向了新的服务，结果5.7版本的旧服务副本没有设置为0

实际表现：web端收到了少许请求，多了一条新增某某数据和几条更新的数据，通过数据对比，数据没有丢失，但是增加了数据对比验证的时间。

改进措施：后续不能为了节省时间，多人并行操作，需严格按照步骤流程单人进行操作，其他人进行监督、复检。

事件3：在进行新旧数据对比时，登入数据库表，等相关操作，工作前置

实际表现：昨天发现在登入数据库时，使用账户密码登入报错，少许耗时，会延长停服的时间

改进措施：后续在停服之前可以将这些细节，写入前置动作，提前打开界面，登入数据库，准备好查询表命令，准备好操作文档

事件4：在停服期间研发观察到的写入接口服务还有13QPS/s

实际表现：在此期间进行停服，肯定会对这还在写入用户带来影响

改进措施：可以选择在QPS低峰期进行升级服务操作，这个可以通过后续的天、周、月流量峰值观察，选择合适的时间点进行停服操作

六、总结

• 从研发操作流程来说：提前确认影响面、整理流程文档(细到每一步)、预演方案、按照流程实操、风险预防
• 从用户体验来说：提前预告、给用户友好提示
• 从风险最小化来说：选择流量低峰期、来干这件事