MySQL主从复制是很多系统实现读写分离和高可用的基础，但在实际配置与运行后，经常出现主库写入正常、从库却查不到数据，或者从库频繁报错停止复制的情况。这类特殊问题通常不是安装步骤有误，而是隐藏在复制机制、表结构差异或操作规范之中。理解复制原理并掌握排查路径，才能快速恢复数据一致性。
一、主从复制的基本机制回顾
MySQL主从复制依赖于二进制日志（binlog）和中继日志（relay log）。主库将所有改动数据的操作以事件形式写入binlog，从库的IO线程连接主库并拉取这些事件，存入本地relay log；随后SQL线程读取relay log并重新执行，从而达到数据同步。该过程默认是异步的，因此从库存在一定延迟窗口。
在配置阶段，我们通常会设置server-id保证每个节点唯一，开启log-bin，并建立专门用于复制的账号。看似简单的步骤，一旦某个环节参数不匹配，就可能在运行一段时间后爆发同步异常。比如binlog格式如果选用statement，遇到含UUID或NOW()的语句就可能造成从库执行结果不同，而row格式虽安全却会增加日志量。
二、典型特殊问题：SQL线程报主键冲突
其中一种最让人困惑的现象是，从库SQL线程突然停止，错误日志显示类似“Last_Error: Could not execute Write_rows event on table test.user; Duplicate entry '10' for key 'PRIMARY'”。这通常意味着从库上已经存在主键为10的记录，而主库传来的写入事件又要插入同样的值。
造成该问题的原因有多种：可能是运维人员直连从库手动插入了数据；也可能是主从切换后原主库未彻底只读，双写导致主键重叠；还可能是某些版本下自增步长配置不一致。此时若盲目重启slave，问题依旧。我们需要先识别冲突来源，而非简单跳过。
-- 查看从库状态，定位错误与binlog位置 SHOW SLAVE STATUSG -- 若确认是无关紧要的冲突且需跳过（谨慎操作） STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
上述跳过方式仅适合临时救急。长期来看，应利用pt-table-checksum与pt-table-sync工具定期校验并修复差异，同时严格限制从库账号只有只读权限，避免人为写入破坏复制。
三、隐蔽问题：binlog格式与函数导致回放失败
另一类特殊问题是主库执行成功，但从库SQL线程报“Unknown error”或函数不存在。例如主库使用了自定义函数，但从库未创建；或者使用了UUID()且binlog_format为statement，从库回放时生成了不同的值，引发数据分裂。
为避免此类情况，建议统一使用binlog_format=row，并确保主从数据库版本、字符集、时区一致。如果必须使用存储函数，应通过init_connect或同步创建保证从库具备相同定义。以下示例展示如何检查并修改binlog格式：
-- 查看当前binlog格式 SELECT @@binlog_format; -- 动态修改（需权限，重启后失效，应写进配置文件） SET GLOBAL binlog_format = 'ROW';
在配置文件my.cnf中，应明确写入binlog_format=row及server-id，减少运行时差异。同时开启log_slave_updates可让从库也记录自身应用的中继日志，方便级联复制排查。
四、网络与权限引发的伪同步
有时Seconds_Behind_Master显示0，但数据就是不对。这可能是因为IO线程断开后自动重连，而SQL线程早已因错误沉默。还有一种情况是防火墙策略变更，主库binlog被清理，从库永远卡在某个位点。
排查时不能只信状态变量，应交叉比对主库SHOW BINARY LOGS与从库Relay_Master_Log_File。权限方面，复制账号必须拥有REPLICATION SLAVE与REPLICATION CLIENT权限，且主机白名单准确。错误配置成%（任意主机）虽能连通却留下安全隐患。
-- 主库创建专用复制账号示例 CREATE USER 'repl'@'192.168.0.2' IDENTIFIED BY 'strong_pass'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.0.2'; FLUSH PRIVILEGES; -- 从库指向主库 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='strong_pass', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=154; START SLAVE;
当发现从库长时间无进展，可先STOP SLAVE IO_THREAD，确认主库对应binlog尚在，再START SLAVE IO_THREAD重新拉取，避免位点失效。
五、自增主键与主主模式的坑
如果在主从基础上扩展为主主（双主），但未设置auto_increment_offset与auto_increment_increment，两台机器都可能生成相同自增ID，互相同步时必然冲突。即便纯一主一从，若从库被误设为可写，也会打破自增秩序。
正确做法是在双主中，节点A设offset=1、increment=2，节点B设offset=2、increment=2，使ID奇偶分离。单主从结构则通过read_only=1与super_read_only=1锁死从库写入口，从根源消灭特殊写入冲突。
[mysqld] server-id=2 read_only=1 super_read_only=1 relay-log=relay-bin log-bin=mysql-bin binlog_format=row
通过参数约束与架构规范，大部分“诡异”的同步问题都能转变为可预期的行为。遇到异常时，保持冷静，从线程状态、错误码、binlog位点三层逐步下钻，才是解决MySQL主从特殊配置问题的正道。