-
MySQL UPDATE 8000 万行被 kill 后 rollback 90 分钟主库锁死 3 小时的真实事故复盘:InnoDB 回滚机制 + 拆批策略 + 10 条治理纪律
2026 年 2 月一次 UPDATE 8000 万行的合规任务跑了 4 小时,DBA 担心影响早高峰执行 KILL,结果 rollback 比正向执行更慢——花 90 分钟才完成,主库锁死 3 小时,业务超时 41 万笔,直接损失 80 万。复盘 InnoDB 回滚单线程机制 + 5 种大事务典型场景 + SafeBatchUpdater 框架 + 8 条工程纪律。- 4
- 0
-
数据库读写分离完全指南:从一次"改完昵称还显示旧的"看懂为什么主从延迟绕不开
2023 年我给一个电商系统做数据库的读写分离之前所有读写都压在一台主库上大促时主库 CPU 直接打满方案很标准加一台从库写操作发主库读操作发从库把主库的读压力分出去第一版我做得很顺手我在数据库连接层做了个路由 SQL 一看是 SELECT 就走从库是 UPDATE 就走主库本地我测了测读写都正常数据也对我心里很笃定主从复制嘛主库一改从库立刻同步成一模一样的副本读主读从读到的是同一份数据可等它一上…- 0
- 0
-
数据库读写分离完全指南:从一次"用户发完评论刷新就不见了"看懂主从复制延迟为什么坑人
2023 年我做一个内容社区的后端上线一段时间后数据库开始扛不住了用户刷信息流看详情翻评论海量的读请求把单台数据库压得喘不过气怎么让数据库扛住这件事我没多想就有了方案读写分离搭一台从库让它复制主库的数据然后把所有读请求打到从库写请求打到主库压力不就分摊了第一版我做得很顺手配好主从复制在代码里写了个路由读走从库写走主库本地和测试环境一跑读写各走各的主库的压力肉眼可见地降了下来我心里很笃定读写分离嘛不…- 2
- 0
-
数据库读写分离完全指南:从一次"用户下单后看不到自己的订单、主库宕机丢了几千条数据"看懂主从复制
2021 年我做一个交易系统流量涨上来数据库的读压力越来越大。第一版我做得很省事配一套主从复制一主一从然后把所有的读查询全甩给从库写还留在主库。本地我开两个库测了测真不错读和写分了家主库轻松了。我心里很踏实读写分离嘛配好主从复制读全走从库不就行了。可等这套架构真正上线扛起真实流量一串问题冒了出来。第一种最先把我打懵用户刚刚下单成功页面跳到我的订单却看不到那笔刚下的单他以为下单失败了又下了一遍。第二…- 0
- 0
-
数据库读写分离完全指南:从一次"用户改完资料刷新又变回去、刚下单订单列表却没有"看懂主从一致性
2022 年我负责一个用户量正在往上涨的系统。数据库单机越来越吃力尤其是读压力各种列表页详情页的查询把数据库 CPU 压得很高。我做了一个很标准的优化读写分离。一个主库负责写挂两个从库负责读主库的数据通过主从复制同步到从库。我做得很直接在代码里判断 SQL 写操作走主库读操作走从库。本地一测顺极了写进去的数据转头就能从从库读出来主库压力肉眼可见地降了下来。我心里很踏实读写分离嘛不就是写走主读走从。…- 2
- 0
-
MySQL 读写分离完全指南:从一次"下单后查不到订单"看懂主从延迟
2022 年我们的订单系统做了读写分离:一台主库扛写,两台从库分摊读。上线 QPS 曲线漂亮得想截图发群,我以为这次升级稳了。第三天客服转来投诉:用户下单付完款跳回订单列表,页面却显示"暂无订单",刷新一下又出来了。这种"刷新就好"的 bug 最头皮发麻——不稳定复现、日志无报错、代码挑不出错。盯了很久才反应过来:下单是写、写进主库,跳回列表是读、读的是从库…- 0
- 0
-
写完马上读却读到旧数据:一次主从延迟踩坑的复盘
做了读写分离后,用户改昵称提示成功,刷新却还是旧的,过几秒才生效。根子是主从异步复制:写主库、读从库,binlog 还没同步完就被读到了。几天梳理:主从复制三线程、延迟成因、Seconds_Behind_Master 监控、写后读强制主库、并行复制与半同步、读分级与缓存兜底。- 0
- 0
-
MySQL 主从延迟 25 分钟事故复盘:并行复制 + ProxySQL 工程治理
大促前 MySQL 主从延迟突然 25min,从库读到半小时前订单,客服系统乱套。系统性治理:MySQL 8.0 WRITESET 并行复制 + 半同步 + 大事务拆分 + 从库 InnoDB 调优 + ProxySQL 延迟感知路由 + 写后立即读走主库。延迟稳定 < 100ms,从库承载 80% 读流量。- 0
- 0
主从复制
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×