鸿蒙开发者必学：MySQL运维设计实战

　　凌晨三点二十，机房空调嗡嗡响得像快散架的拖拉机，我盯着监控屏右下角那块胶布——上周贴的，遮住屏幕裂痕，现在它翘起来半边，像条死掉的蚯蚓。

　　手机在裤兜里震第三回，是王磊，鸿蒙端刚上线的推送服务负责人。他声音劈叉：“主库连不上，用户注册卡在 OTP 验证，你看看是不是从库切不回来？”我没回，手已经摸到键盘，ssh 连过去敲 df -h。/var/lib/mysql 满了。百分之百。不是九十八，是整整齐齐的一百。

　　我原以为清个 binlog 就能喘口气，结果发现 purge_binary_logs_before_date 这个参数压根没生效——去年六月配的，配置文件里写着，但 mysqld 启动时根本没读那行。我不知道它是被覆盖了还是被注释了，还是启动脚本里顺手加了 --skip-grant-tables（当然没加，但我那一刻真怀疑有人干过这事）。我查 processlist，看到三个长事务卡在 waiting for table metadata lock，其中一个居然是 ALTER TABLE user_profile ADD COLUMN hmon_sdk_version VARCHAR(16) DEFAULT '0.0.0'，去年七月提交的，至今没结束。

　　值班室泡面桶堆在桌角，红烧牛肉味混着机柜散热口飘出的焦糊味。我撕开一包新面，还没倒水，老板在运维大群发了个截图：鸿蒙应用市场实时评分掉到 3.2，底下五十多条评论全带“注册失败”四个字。他没@谁，就甩了张图，后面跟个句号。这比任何@都瘆人。

　　我一边等面泡软一边翻备份日志。backup_20240529.sh 执行时间是凌晨两点十五，但 /backup/mysql/full/20240529 目录下只有两个空子目录，ls -la 显示 mtime 是五月二十八号下午四点十七——备份脚本跑完就 exit 0，压根没校验 rsync 是否真把数据推过去了。我们那个同事老陈，上个月还在群里说“只要脚本不报错就是成功”，那天他儿子发烧三十九度五，他半夜三点在医院输液室改 Jenkinsfile，改完发了个“搞定了”，然后把 Jenkins 权限锁死了两小时。没人敢动。

文章配图，仅供参考

　　窗外开始下雨，不大，但打在机房南侧玻璃上像有人拿指甲刮。我重启 mysql 的时候，手指停在回车键上足足四十来分钟。不是不敢按，是得先确认 my.cnf 里 skip-log-bin 是不是还开着——上一次误开它是在四月十一号，导致 GTID 不一致，主从同步裂开三天，最后靠 pt-table-checksum 血洗全库。可这次呢？这次连 checksum 都跑不了，磁盘满了。我删了最老的三个 binlog，腾出两百兆，服务是起来了。但主从延迟直接飙到八万秒，show slave status\\G 里 Seconds_Behind_Master 字段闪着红光，像急诊室门口的灯。

　　这时候客服小林电话进来，语速快得带颤音：“张工，用户投诉说鸿蒙手表同步手机通讯录时，联系人姓名全变成乱码方块，但安卓和 iOS 端都正常。”我随口问字段 charset，她念了句“utf8mb4_general_ci”。我嗯了一声，其实心已经飘走——去年六月那次灰度发布，我们为了省事，把所有新表默认字符集写成 utf8（不是 utf8mb4），后来发现鸿蒙设备上报的 emoji 带零宽连接符，MySQL 5.7 一存就截断，存进去再捞出来就是空格。我们当时补了 CONVERT 函数硬绕过去，没动表结构。现在它回来了，穿着新 bug 的衣服，坐在新用户的通讯录里，一声不吭。

　　我想起搬家那会儿，纸箱上写的“数据库配置+证书”，被物业当废品收走两箱。其中一箱里有张手写的 SSL 证书路径清单，墨迹被雨洇开，rootCA.pem 变成 r∞tCA.pem。那天下着的也是这种毛毛雨。后来我们用 OpenSSL 自签了一个临时证书，凑合用了三个月，直到某天凌晨五点，鸿蒙设备批量断连——不是 502，是 TLS 握手直接失败，日志里只有一行 handshake failure，连 error code 都没打全。没人怪我，因为那天值班的是实习生，他睡着了，闹钟没响，而我们监控只盯 HTTP 状态码，不抓 TLS handshake rate。

　　我关掉 ssh 窗口，打开微信，找到鸿蒙开发者文档页面，往下拉，拉到“本地存储与远程同步”那一节。底下评论区最新一条是：“为什么鸿蒙 App 用的 MySQL 驱动版本是 5.1.47？连 prepared statement 都不支持 bind null。”下面一百二十多条回复，六十条在问有没有适配 openGauss 的 SDK，三十条在骂华为云 RDS 的慢日志权限粒度太粗，剩下全是截图——一张 show variables like '%timeout%'，一张 explain select from sync_task where status='pending' limit 1000，一张 application.yml 里 datasource.url 写着 jdbc:mysql://xxx:3306/app?useSSL=false&serverTimezone=GMT%2B8&allowPublicKeyRetrieval=true，最后一个参数还是手抖多打了个 e，变 allowPubliceKeyRetrieval=true，MySQL 一概不报错，静默忽略。这个我到现在也没想明白。

　　优胜劣汰不是口号。是鸿蒙设备冷启动连不上 MySQL，用户滑动十次刷新页，第三次就卸载；是备份脚本里那行 rm -rf /tmp/ 写在了 tar 指令前面，清空了临时压缩包，而 nohup.out 日志里只写了 “backup done”；是你们用 DevEco Studio 调试 Network Profiler 时，看到的 SQL 耗时是 32ms，实际 MySQL 里这条查询 locked in InnoDB 里三分钟都没释放——但鸿蒙 UI 已经 fallback 到本地缓存，用户根本感觉不到卡，直到他登另一台设备，发现通讯录没了，消息时间轴乱序了，而他以为是自己手滑删错了。

　　我泡面早坨了，汤浮一层油花。手机又震，王磊发来截图：一个用户反馈“注册后登录失败，提示密码错误”，但他注册时没输密码框，只点了微信一键登录。我们后端接口确实接了鸿蒙的 Account Kit Token，可鉴权中间件里硬编码校验了 user_id LIKE 'wx_%'，而鸿蒙返回的是 hm_account_xxx。这个判断逻辑去年六月写在 auth-filter.js 第 87 行，从来没人改过，也没人测过跨平台兼容性。它不是宕机，不是磁盘满，甚至不算 bug——只是被当成“前端传参格式差异”悄悄吞掉了。

　　明天先把告警阈值调了。把磁盘满的告警从 95% 改成 88%，留七个百分点给人喘气。别的……等我把监控屏上那条胶布撕了再说。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!