linux下排查主从数据冲突需分层定位：先用show slave status检查复制状态，再用pt-table-checksum比对数据一致性，接着根据错误日志区分人为误操作、结构不一致、非确定性语句或过滤配置问题，最后按范围选择跳过、pt-table-sync修复或全量重建。

Linux 环境下排查主从架构的数据冲突，核心是分层定位：先确认复制链路是否健康，再验证数据一致性，最后分析差异根源。不依赖经验猜测，而是靠命令输出和工具结果说话。

一、检查复制状态是否正常

在从库执行 SHOW SLAVE STATUS\G，重点看三项：

• Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes；若任一为 No，说明复制中断
• Last_IO_Error 或 Last_SQL_Error 字段会直接显示错误原因（如“Duplicate entry”“No such table”）
• Seconds_Behind_Master 持续增长，说明存在延迟积累，可能掩盖已发生的静默不一致

二、确认主从数据是否真实偏离

仅看复制状态不够——SQL线程跑着，不代表数据没被绕过或误改。需主动比对：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 用 pt-table-checksum 在主库运行，生成校验和并同步到从库：
  pt-table-checksum --host=master_ip --user=rep_user --password=xxx --databases=db1,db2
• 再用 pt-table-sync --print 查看差异语句（不执行），确认哪些表、哪几行不一致
• 小范围可手动对比：
  SELECT COUNT(*), MD5(GROUP_CONCAT(id ORDER BY id)) FROM t1; 主从分别执行，比对结果

三、定位不一致的来源类型

根据错误信息和操作日志，区分是哪类问题：

• 人为误操作：从库被直接写入（SET SQL_LOG_BIN=0 后执行 DML）、主库跳过错误后未同步修复
• 结构不一致：主从表字段类型不同、索引缺失、字符集不一致，导致同一条语句在从库解析失败或行为异常
• 非确定性语句：使用 NOW()、RAND()、INSERT ... SELECT 且未设 binlog_format=ROW
• 过滤配置干扰：主库 binlog-ignore-db 或从库 replicate-ignore-db 导致部分库/表未同步

四、选择匹配的修复方式

修复策略取决于不一致范围和业务容忍度：

• 单行主键冲突：用 SET GLOBAL sql_slave_skip_counter = 1; START SLAVE; 跳过（慎用）
• 少量表偏差：用 pt-table-sync --sync-to-master 生成并执行修复 SQL
• 整库或大范围不一致：停写主库，mysqldump 全量导出 + 从库重建，避免增量修复引入新错
• 修复后必须验证：SHOW SLAVE STATUS 中 Seconds_Behind_Master = 0 且无错误，并重跑一次 pt-table-checksum