MySQL运维设计实战：36小时构建高可用安全体系

　　去年过年时，凌晨三点十七分，我蹲在IDC机柜前，右手捏着冷掉的饺子——铝箔盒盖上印着“吉祥如意”，油渍洇开，把“如意”俩字糊成了个墨团。左手摸着主库服务器的散热口，烫得像刚出锅的年糕。监控告警灯在机柜顶上无声狂闪红光，第八次了。

　　客服工单系统弹出新消息，自动带出模板：“尊敬的客户，您反馈的502错误我们已记录……”后面半截被运维组群聊窗口盖住了。群里有人发了个“？？？”，另一个人回“主库脑死亡，从库没切过来”，第三个人甩出一条命令行截图：mysql -h 10.2.3.4 -u admin -p 报错 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet'。我原以为是SSL握手超时，结果盯着tcpdump抓包看了一小时，发现根本没发SYN——连握手的机会都没给。

　　值班小王蹲在隔壁机柜后头啃苹果，嘎吱嘎吱嚼着，问我：“叔，是不是主库那个‘安全加固脚本’又自己跑了？”他话音还没落，我手机震了一下，是安全组老李发来的微信：“刚才自动执行了v2.7.3加固策略，屏蔽了所有非192.168段IP的3306访问。”——可主库和从库之间走的是10.网段，根本不在白名单里。我手指悬在键盘上，没敲回车，光看着那句“v2.7.3”在屏幕上发虚。老李补了句：“这版本上周刚过甲方终审。”

文章配图，仅供参考

　　我撕开第二盒饺子，塑料盒掰断了一角，扎进拇指肉里，渗出血珠子。不是疼，是愣住——那脚本本来只该在测试环境跑。但没人记得那天夜里是谁手抖点了“同步至生产”。反正没人承认。我就记得监控后台日志里有条不起眼的记录：Jan 22 02:41:13 db-prod-01 cron[2891]: (root) CMD (/opt/sec/mysql-hardening.sh --apply --env prod --force)，时间戳底下还跟着一行灰色小字：(uid=0)。我也不知道谁uid=0的时候还敢加--force。

　　备份恢复失败这事，其实卡在第七分钟就该停了。restore_db.py脚本报“ERROR: binlog position not found in target instance”，但没人看它。因为所有人眼睛都钉在高可用切换面板上——绿色心跳灯一灭，所有人就自动切到“怎么切回来”，没人问“为什么binlog没跟上”。我调出昨天23点的备份校验日志，第十三行写着：WARN: GTID_EXECUTED mismatch between backup meta and source DB —— 字太小，混在一堆“OK”里，像扫地时漏掉的瓜子壳。有谁会为一颗瓜子壳停掉整条产线？

　　后来抢修完，我顺手点了下机柜顶上的温控探头，屏幕跳出来：当前温度37.2℃（±0.5℃）。而贴在风扇格栅边沿的纸质巡检表，上回签字是腊月二十三，日期写成“2023年1月16日”，笔迹发潮，墨水晕开成一小片蓝雾。我说不清是纸先洇的，还是汗滴下去才洇的。

　　老李凌晨四点打来电话，声音哑：“主库起来了，但GTID set空了一段，要不要手动补？”我没吭声。他那边背景音是泡面桶被碰倒的声音，哐当一下。我听着，突然想起前天吃饭，隔壁桌俩DBA说：“现在哪还手补GTID啊，全是自动续接。”我说：“你们用的啥中间件？”他们笑：“没有中间件——就是MySQL 8.0.33自带的那个replica-automerge功能。”——可我们装的是8.0.22。我原以为他们记错了版本号，结果翻开自己电脑里的安装清单，白纸黑字：mysql-community-server-8.0.22-1.el7.x86_64.rpm。那两个DBA姓什么？我不记得了。

　　现在看，这事站得住的地方就一个：优胜劣汰。活下来的不是最稳的，是反应最快的；不是最懂的，是第一个敢删掉/etc/my.cnf里skip-grant-tables那行的人。至于“高可用安全体系”——它就在你按Ctrl+C打断脚本的那零点三秒里，在你没看清报警标题就敲下mysqladmin shutdown的那一刻，在你发现备份目录下多出一个名为“.recover_temp_$$”的隐藏文件夹、却决定假装没看见的二十来分钟里。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

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