-
我为了保证原子性把几万条记录的批量处理塞进了一个数据库事务,结果这个事务跑了好几分钟,期间长时间持锁阻塞了其他业务、占满了连接池、还把回滚段撑得老大、主从延迟飙升:一次大事务拖垮整个库的深度复盘
我有个批量任务要更新几万条记录,想着这些操作得保证原子性、要么全成功要么全回滚,就放进一个事务里:开启事务→循环几万次逐条 update→提交。功能没问题,可一上线跑,整个数据库就开始抖:其他业务大面积报锁等待超时、连接池被占满、主从延迟从毫秒飙到几十秒、DBA 告警 undo 暴涨。复盘才理解大事务的危害:一个事务在开始到提交的整个期间会持有它改过的行的锁、占用一个连接、在 undo log 里…- 0
- 0
-
我刚写入数据库的数据,紧接着一查却说查不到,我一口咬定是事务没提交、对着事务代码排查了好几天,最后才发现是读写分离的主从延迟在作怪的深度复盘
我们为扛读流量做了读写分离:写走主库,读分摊到从库。可一个诡异 bug 折磨了我好几天——用户提交一条数据,代码先写库、紧接着立刻查它,结果那条刚写进去的数据竟然"查不到"、或查到旧值!而且时有时无,测试环境几乎不出,一到高峰就频繁冒。我一口咬定是事务没提交,查了好几天事务代码,最后才醒悟:写走主库、紧接着的读却走了从库,而主从复制是异步的、有复制延迟,数据还没同步到从库就被读…- 0
- 0
-
用户刚保存提示成功一刷新却还是旧内容、下单成功转头查这单却偶发报订单不存在:读写分离架构下主从复制延迟读到旧数据的踩坑复盘
这个 bug 的用户反馈听起来特别像在见鬼:用户明明刚刚保存了修改、系统也提示保存成功了,可页面一刷新显示的还是修改前的旧内容,好像他的修改凭空消失了,于是用户狐疑地又改了一遍又保存刷新,这次有时对了有时还是旧的时灵时不灵。更要命的是另一处:我们的下单流程写入订单成功后紧接着的一个步骤要去查这条刚下的订单,结果偶发性地报订单不存在,一条我们明明刚刚亲手写进数据库的订单转头就查不到了。这两个见鬼的现…- 0
- 0
-
MySQL 读写分离完全指南:从一次"下单后查不到订单"看懂主从延迟
2022 年我们的订单系统做了读写分离:一台主库扛写,两台从库分摊读。上线 QPS 曲线漂亮得想截图发群,我以为这次升级稳了。第三天客服转来投诉:用户下单付完款跳回订单列表,页面却显示"暂无订单",刷新一下又出来了。这种"刷新就好"的 bug 最头皮发麻——不稳定复现、日志无报错、代码挑不出错。盯了很久才反应过来:下单是写、写进主库,跳回列表是读、读的是从库…- 0
- 0
主从延迟
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×