必须确保主从 server-id 全局唯一、log_bin 开启且 binlog_format 统一为 row；max_allowed_packet 主从需一致（建议 64m）；auto_increment 相关参数须匹配并启用 super_read_only；sync_binlog 和 innodb_flush_log_at_trx_commit 主库必须均为 1，从库至少后者为 1。
检查主从 server-id 和 binlog 配置是否冲突
server-id 重复是最常见、最致命的配置错误，会导致从库无法注册到主库的复制拓扑中，SHOW SLAVE STATUS 中 Slave_IO_Running 直接为 No，错误日志里常出现 Could not find first log file name in binary log index file 或连接后立即断开。
必须确保：
- 所有节点 server-id 是全局唯一整数（不能为 0 或重复）；
- 主库 log_bin 必须开启（如 log_bin = mysql-bin），且 binlog_format 建议统一为 ROW（尤其 MySQL 5.7+）；
- 从库可不开启 log_bin，但如果要做级联复制或故障切换，建议也开启并配好 log_slave_updates = ON。
验证方式：
- 主库执行：SELECT @@server_id, @@log_bin, @@binlog_format;
- 从库执行同样语句，逐项比对，差异项必须修正后重启 mysqld（部分变量如 server-id 不支持动态修改）。
max_allowed_packet 不一致导致 SQL 线程中断
主库能执行的大事务（如批量 INSERT、大 BLOB 字段更新），在从库因 max_allowed_packet 设置过小而报错 Packets larger than max_allowed_packet are not allowed，Slave_SQL_Running 变为 No，Last_SQL_Error 明确提示该错误。
关键点：
- 该参数是会话级生效的，但主从复制的 SQL 线程使用的是从库全局配置值；
- 主库设置为 64M，从库却设为 4M，就极大概率出问题；
- 修改后必须重启 MySQL（该参数不可动态 SET）；
- 生产建议统一设为 64M 或更高（如 128M），避免边界场景踩坑。
检查命令：SELECT @@max_allowed_packet;（单位字节，64M = 67108864）
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
auto_increment 相关参数错配引发主键冲突
当主库写入自增主键表时，若从库的 auto_increment_offset 和 auto_increment_increment 与主库不一致，或从库被误写入数据，后续同步 INSERT 可能触发 Error_code: 1062; Duplicate entry。
典型诱因：
- 双主架构未按规范配置 offset/increment（如主1设 offset=1, increment=2，主2设 offset=2, increment=2）；
- 从库开启了 read_only = OFF，又没设 super_read_only = ON，人为插入了自增 ID；
- 主库 innodb_autoinc_lock_mode = 2（交错模式），而从库为 1（连续模式），在高并发 INSERT 场景下可能造成 ID 分配逻辑偏差。
修复动作：
- 立即确认从库 read_only 和 super_read_only 均为 ON；
- 统一主从 innodb_autoinc_lock_mode（推荐 2，性能更好，但需确保应用不依赖严格连续 ID）；
- 若已发生 1062 错误，跳过前先用 SELECT MAX(id) FROM tbl 校验从库当前最大 ID，再手动调整 auto_increment 值，避免下次再撞。
sync_binlog 和 innodb_flush_log_at_trx_commit 不匹配导致数据丢失风险
这不是立刻报错的类型，但属于“静默不一致”——主库崩溃后部分已提交事务未落盘，从库却同步了这些 binlog，造成主从数据永久性偏差。错误日志里不会直接报错，但 SHOW SLAVE STATUS 中 Seconds_Behind_Master 可能突降为 0 后又飙升，或主库 crash 后从库多出几条记录。
安全基线配置：
- 主库：必须设 sync_binlog = 1 + innodb_flush_log_at_trx_commit = 1；
- 从库：至少设 innodb_flush_log_at_trx_commit = 1（保证 relay log 回放不丢）；
- 两者若不一致（如主库为 1，从库为 0），主库 crash 恢复后 binlog 缺失，但从库已执行对应事务，数据就再也对不上了。
注意：sync_binlog = 1 会带来写性能下降，但这是强一致性前提下的必要代价；线上环境切勿为省一点 IO 而妥协。
