适用人群后端同学、运维同学、需要排查“两个库同一条设备状态不一致”的场景关键词MySQL 跨库事务、binlogROW、mysqlbinlog、时区、触发器审计背景为什么要做 A 与 B 状态强一致在项目里A 系统与B 系统都有设备表并且设备的“运行状态0~9”在业务上要求一致。早期做法通常是只更新 A 库B 通过异步事件/定时补偿同步或两边各写各的偶发不一致后靠人工 SQL 修正。当设备在线/离线、告警、离网运行等状态频繁跳变时这些方案会出现典型问题消息并发、乱序导致写入覆盖异步同步失败或延迟导致页面展示不一致运维部署时系统卡顿某些更新丢失或延迟执行。因此我们选择了“方案A同 MySQL 实例两库两个 schemaA 为主B 同步写入强一致”在一次事务中同时更新A.eiot_device_info与B.device任何一边更新失败整体回滚避免“只更新一半”现象日志显示 B 更新成功但最终 B 表里 state 变成 0我们在DevicePropertyHandler里根据设备上报runStatus更新状态设备状态更新日志示例2026-03-13 10:57:43.077 DevicePropertyHandler | 设备:PCSEPCS105202512050001状态更新 [8 - 7] 2026-03-13 10:57:43.080 DeviceInfoServiceImpl | [A]更新设备状态成功: deviceSnPCSEPCS105202512050001, state7 2026-03-13 10:57:43.082 DeviceInfoServiceImpl | [B]更新B设备状态成功: deviceSnPCSEPCS105202512050001, state7但事后在数据库里看到A.eiot_device_info.state 7B.device.state 0直觉上会怀疑事务没生效并发乱序覆盖读到了从库旧数据但这类问题一定要用“证据链”说话日志 数据库写入记录binlog。先把链路串起来到底是谁在更新状态状态更新调用链简化DevicePropertyHandler.updateDeviceStatus(...)deviceApi.updateDeviceState(deviceSn, runStatus)DeviceInfoServiceImpl.updateDeviceState(deviceSn, state)Transactional事务内更新A.eiot_device_info更新B.device同一个 MySQL 实例不走 MQ我们在DeviceInfoServiceImpl.updateDeviceState里打印了成对日志[A]更新设备状态成功 ...[B]更新B设备状态成功 ...这意味着10:57:43 这次写入A 和 B 在那一刻确实都写到了 state7。那么“B 最后变成 0”只有一种解释在 10:57:43 之后又有另外一个写入把B.device.state从 7 改回了 0。接下来我们要找的就是这次“改回 0”的写入来自哪里。用 binlog 取证谁在什么时候把 state 改成 01确认 binlog 是否开启、格式是什么进入 MySQLSHOWBINARYLOGS;SHOWVARIABLESLIKEbinlog_format;要点binlog 文件名的数字越大越新如binlog.000157比binlog.000156新binlog_formatROW很常见写入记录按“行变更”存储适合精准还原字段变化2注意mysqlbinlog不是 SQL 命令要在 Linux shell 执行很多人第一次会在mysql里敲mysqlbinlog ...会得到语法错误。正确方式退出 mysql 客户端在服务器终端执行cd/var/lib/mysql# 这个命令容易卡住用ctrlz退出有时候ctrlc退不出mysqlbinlog binlog.000157|less# 如果只需要看最新一百行可以这样先生成 SQL 文件再用 tail 或 lessmysqlbinlog --no-defaults binlog.000157binlog.sqltail-n100binlog.sql|less3时区坑应用日志是本地时间binlog 时间可能是 PST/UTC我们在 binlog 尾部看到了# original_commit_timestamp... (2026-03-13 16:52:16.381990 PST)这说明binlog 输出使用了PST。如果你拿应用日志的2026-03-13 10:57直接作为--start-datetime会查错时间段。实践建议先mysqlbinlog ... | tail看它标注的时区把应用时间换算到 binlog 输出的时区后再查4用 grep 快速定位某设备相关写入按 device_sn我们要找PCSEPCS105202512050001这台设备在 B 表的更新mysqlbinlog --no-defaults --base64-outputDECODE-ROWS-vv\--start-datetime2026-03-12 18:50:00\--stop-datetime2026-03-13 16:10:00\binlog.000156|grep-nPCSEPCS105202512050001-C5这一步能初步确认有没有出现UPDATE \B.device大概在哪个时间点附近发生5拿到关键证据state从 7 被写成 0进一步缩小时间窗示例mysqlbinlog --no-defaults --base64-outputDECODE-ROWS-vv\--start-datetime2026-03-13 15:28:20\--stop-datetime2026-03-13 15:28:50\binlog.000156\|sed-n/### UPDATE B.device/,/COMMIT/p\|sed-n/PCSEPCS105202512050001/,$p输出里会出现类似重点看8### UPDATE B.device ### WHERE ### 2PCSEPCS105202512050001 ### 87 ... ### SET ### 2PCSEPCS105202512050001 ### 80 ... COMMIT这就是铁证15:28:33PSTB.device.state7 → 06把 n 映射回列名避免看错字段binlog 的 ROW 输出用1/2/...表示列序号所以必须确认列顺序SHOWCREATETABLEB.device\G我们看到列顺序里2对应device_sn8对应state因此87 → 80就是state 被改回 0不是别的字段比如 dept_id。结论不是“强一致没生效”而是“B 侧又写了一次覆盖”证据链合并10:57:43 应用日志显示[A]与[B]都更新成功到 state715:28:33 binlog 显示B.device.state7 → 0且这次写入只更新了 B 表没有同时更新 A 表说明不是 A 事务链路写的因此根因不是事务问题也不是“那次没更新到 B”而是B或某个独立进程/脚本/任务在后续把 state 覆盖成 0。典型来源包括B 内部“离线判定/状态纠正”定时任务后台保存设备信息接口携带默认 state0 覆盖运维脚本批量修正如何继续追“到底是谁写的”两种抓凶手方案binlogROW能告诉你“改了什么”但通常不直接带 user/host。要找来源推荐以下两种方式。方案1短时间开启 general_log需要能复现/等待再次发生查看 general_log 状态SHOWVARIABLESLIKEgeneral_log%;如果general_logOFF可以短时间打开建议 1~2 分钟内关掉SETGLOBALgeneral_logON;-- 等待/复现SETGLOBALgeneral_logOFF;然后查看general_log_file中记录的userhost与 SQL。注意general_log 开销大尽量短开。方案2触发器审计不需要立刻复现推荐如果你不知道怎么复现最好用触发器在 DB 侧“长期盯梢”只记录 state 变更。1建审计表CREATETABLEIFNOTEXISTSB.device_state_audit(idBIGINTNOTNULLAUTO_INCREMENT,device_snVARCHAR(64)NOTNULL,old_stateTINYINTNULL,new_stateTINYINTNULL,change_timeDATETIME(3)NOTNULLDEFAULTCURRENT_TIMESTAMP(3),connection_idBIGINTNOTNULL,current_user_nameVARCHAR(128)NOTNULL,session_user_nameVARCHAR(128)NOTNULL,host_nameVARCHAR(128)NULL,PRIMARYKEY(id),KEYidx_device_sn_time(device_sn,change_time))ENGINEInnoDBDEFAULTCHARSETutf8mb4;2建触发器只要 state 变就记录DROPTRIGGERIFEXISTSB.trg_device_state_audit;DELIMITER//CREATETRIGGERB.trg_device_state_auditBEFOREUPDATEONB.deviceFOR EACH ROWBEGINIF(NOT(OLD.stateNEW.state))THENINSERTINTOB.device_state_audit(device_sn,old_state,new_state,connection_id,current_user_name,session_user_name,host_name)VALUES(NEW.device_sn,OLD.state,NEW.state,CONNECTION_ID(),CURRENT_USER(),USER(),hostname);ENDIF;END//DELIMITER;3查询审计结果SELECT*FROMB.device_state_auditWHEREdevice_snPCSEPCS105202512050001ORDERBYidDESCLIMIT50;你会得到哪个账号current_user_name/session_user_name哪个连接connection_id什么时候把状态改成了什么这就能把“写入来源”锁定到某个服务/脚本账号上。最终怎么解决建议落地步骤这类问题最终要“堵住覆盖写”的口子而不是在 A 侧不断重写。推荐落地步骤先用触发器审计方案2抓到 “state0 的写入来源账号/时间”在 B 代码/脚本里定位对应逻辑是否有离线判定任务是否有保存设备信息接口把 state 默认写 0按业务规则修复如果 B 的离线判定只想改“在线/离线”不要覆盖 0~9 运行态要么改写另一个字段例如online要么只在特定条件下更新如 state 为某些值才允许覆盖增加防御对写入 0 的逻辑加日志deviceSn、old/new、调用栈或加 DB 侧约束/触发器拦截谨慎使用附常用命令速查查看 binlog 文件列表数字越大越新SHOWBINARYLOGS;解析 binlogROW为可读输出mysqlbinlog --no-defaults --base64-outputDECODE-ROWS-vvbinlog.000156|less快速搜某设备 SN 的写入mysqlbinlog --no-defaults --base64-outputDECODE-ROWS-vvbinlog.000156\|grep-nPCSEPCS105202512050001-C5确认列顺序把 n 映射到列名SHOWCREATETABLEB.device\G总结这次问题的关键不是“猜”而是“取证”日志证明A→B 强一致更新在 10:57:43 是成功的binlog 证明15:28:33 有另外一次写入把 B state 从 7 改成 0下一步用触发器审计/短期开 general_log 找出写入来源修复 B 侧覆盖写逻辑只要把“覆盖写 state0 的源头”处理掉A 与 B 的状态就能稳定一致。