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

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

研发：XX、XX、XX

测试：XX

计划时间：2022.01.11 1:00

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

开始前置动作

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低峰期进行升级服务操作，这个可以通过后续的天、周、月流量峰值观察，选择合适的时间点进行停服操作

0 人点赞