背锅侠日记 - 运维、数据库、AI 编程实战复盘 | 老耿个人技术博客

一次垂直分库的拆库迁移复盘。100 多个库散在十几台物理机上，其中两个库吃掉了所在服务器近一半的磁盘；RAID 阵列扩容风险太大，于是把巨无霸库单独拆到新机器上。方案是单库导出加主从同步：从从库导出时带上 GTID，传到新库导入，再挂回原主库下等复制追平。 问题出在校验。为防 pt 的校验数据污染现有主从，我加了一条复制过滤规则——本想排除 percona 库，写法却反了。工具最终卡死在 Waiting，改用脚本逐表比对行数，才发现新从库缺了多张表，大量表行数对不上。 根因就是那行配置：do 是白名单，不是黑名单。它只放行 percona 库，业务库的变更全被静默丢弃，而 show slave status 显示一切正常。万幸还没做业务切换，数据只丢几天。 修复倒不复杂：改回 ignore 规则重启从库，再全量重导、重建复制，校验全绿之后才把新库正式扶正。那行配置当初只是不想影响现有主从，最后捅出娄子的，恰恰是它。…

我的博客后端用 Redis 做缓存和访问计数，启动必须连上 Redis，否则服务直接挂。以前每次本地改代码都得先开虚拟机把 Redis 跑起来，又慢又费电。 前两天发现 Redis 官方有免费云实例（30 MB 档），适合开发环境临时用。注册时 GitHub 登录报错——邮箱设成隐私不可见导致，换 Google 账号一次成功。 流程：选免费 30 MB 计划 → 香港 Region（ap-east-1）→ 默认账号密码（或 Data Access Control 自定义）→ redis-cli 跑 info 验证 → 改 settings.yml 的 redis.url / password，日志出现「Redis 初始化完成」即接好。…

备份从机MySQL 某天突然自己退出，栈帧显示 InnoDB 在复制回放写入时于 os_file_flush 触发致命失败而就地自尽。根因不在数据库，而在底层 LVM thin pool 元数据 LV 占用 100%（数据才 47%）：元数据记录块分配映射，满格后任何需新分配块的写入都落不了盘。这雷是此前库膨胀加盘时埋的——只扩了数据空间，忘了独立元数据 LV（仅 520MiB）。修复：VMware 加 1T 盘，pvcreate/vgextend 后 lvextend --poolmetadatasize +2G 把元数据扩到 2.51GiB，Meta% 由 100 降到 20.25，再扩数据池与 root 各 900G、xfs_growfs 在线刷新、重启恢复。教训：df 只看数据层，thin pool 的 Meta% 才是隐形杀手，须单独监控、预留空间。…

这是一篇从运维视角出发的复盘。我们的数据库每天做全量物理备份，最初的设计很朴素：先在本地产出备份文件，再上传到一套 S3 接口兼容的对象存储，本地只是"过路"。但库一大，这个看似人畜无害的流程开始反噬——备份产物把本地盘写满，触发硬盘告警；临时目录普遍不够大，于是给备份机挂 NAS 顶上，容量够了却慢且脆。更糟的是备份时间集中、表又多，xtrabackup 往临时目录同时写入海量中间文件，直接写错、进程卡死。兜兜转转，最终出路是把"先落盘再上传"改成"边产生边上传"：用 rclone 做流式直传，备份流从产生那一刻就流向对象存储，本地几乎不再留一片叶子。本文记录这条从踩坑到收敛的完整链路。…

先说个扎心的现实：咱们现在用的那个私人邮箱，早就不干「通信」的活了。它现在就两件事——注册各种服务时随手填一下，收一堆验证码。你点开收件箱翻翻，验证码、注册回执，外加铺天盖地的广告，能划半天才找出一封真人写的信。 所以腾讯这个新出的 `agent.qq.com` 是干嘛的？按官方说法，就是专门给 Agent 收验证码用的独立邮箱。说实话，单看这功能，现在有点扯——验证码这玩意儿，至于专门整个邮箱出来接吗？但转念一想，好歹是腾讯亲儿子，域名就一个 `@agent.qq.com`，前缀先到先得。**功能可以以后再吐槽，ID 这东西，不抢就没了。** 私人邮箱已经够脏了，没必要再塞给 Agent 当垃圾桶。给它一个独立的收件口，才是正经用法。 重点不在「又多了个邮箱」。重点在这个邮箱的前缀是先到先得的，而且——注册好之后**只能改一次**。这两条加一块，意思就很明确了：好记的短前缀，现在不抢，以后就是别人的了。…

Claude Code 这把双刃剑我用快两年——平时省心,时不时就降智,没规律,每次是不同锅.这一年没少踩坑:migration 撞号、同事 KV 段被我手滑覆盖、加钩子测 8 个场景才敢上.痛定思痛后护栏摁进三层.文档层:我口述、cc 整理、另一 AI 复述校反复到几乎逐字一致;再开 session 让 cc 出步骤,我反问为什么嚼到能讲清;对账后丢给 cc,每功能 e2e兜底.对账层:陪练(我用 workbuddy)挑刺 2-3 轮.hook 层:真阻断、强提示、上下文注入三种梯度,CLAUDE.md 反复叮嘱都不管用的(像 dev=生产=同库)只能让 hook 物理拦截.三层摞起来,中型功能慢30%,事故率从月均 1 次干到 0.…

DeepSeek 正式落地峰谷定价，白天 API 调用价格直接翻倍，精准覆盖 9:00–12:00 和 14:00–18:00 的标准上班时间。加上智谱、阿里云等厂商在订阅套餐里玩分时倍率，算力行业的"峰谷电价"已成趋势。偏偏开发者的正经干活时间全在晚上——白天被会议占满，加班才能安静写代码调 AI。峰谷定价一落地，白天开会摸鱼混过去、晚上熬夜赶工省 token 成本，活生生把加班搞成了省钱刚需。本文盘点了各家分时计费的玩法，顺带算了笔账：账面上省的是 Token 成本，背地里耗的是我们的下班时间。…

最近一直用 Claude Code 做项目迭代，踩了一个特别折磨人的坑：明明只是改几行简单代码、修复小Bug，Token 消耗却疯狂暴涨，轻轻松松干掉几千万 Token。而且经常没几次会话上下文就100%了。 一开始我特别费解，改动逻辑一点不复杂，为什么 Token 消耗会爆炸式增长？ 折腾复盘了好几天，彻底摸清了固定时间窗口+周总量Token套餐的消耗逻辑，也摸透了 AI 代码助手的上下文堆叠规则。今天把这套「省Token、不丢上下文、提升迭代效率」的实战技巧完整分享出来，专门适配和我一样用包月/固定额度套餐的开发者。…

上篇设计了"多 LLM 互喷辩论"的代码审查方法论，但偏演示性质。这次我动真格的：用 codex、qoder、workbuddy 三个大模型，对我的博客 e2e 测试框架（394 个用例）完整跑了一遍"审查 → 辩论 → 复核 → 修复 → 验证"全流程。结果揪出了 2 个真生产安全漏洞（公开 API 泄露草稿、JWT 撤销缺失），以及 1 个"跑了但没断言"的摆设测试。最终 5 个 PR 全部落地，测试从 394 条增至 399 条，全绿通过。本文是完整实战记录，包含工具选型、互喷过程、修复细节和踩坑经验。…

我平时 90% 的代码活靠 Claude Code,但有个问题它解决不了 —— 它自己审自己写的代码,我总不放心。同一天我跟同事吃饭,他随口说:"现在会薅很多 agent 的羊毛做代码审查。"我眼睛一亮 —— workbuddy 和 qoder 那俩免费工具我平时基本不开,免费额度反正放着浪费,这次的事正好用上,凑 3 个 LLM 一起审 6 万行 Go 后端。…