我是 MySQL 新手，经过长时间的搜索，我能够配置基于主从 ROW 的复制。我认为它是安全的，我不必一次又一次地重新检查它。
但是今天当我SHOW SLAVE STATUS;在奴隶上做的时候，我发现以下
无法在表 mydatabasename.atable 上执行 Write_rows 事件；键“PRIMARY”的重复条目“174465”，错误代码：1062；处理程序错误 HA_ERR_FOUND_DUPP_KEY；事件的主日志 mysql-bin.000004, end_log_pos 60121977
有人可以告诉我，当master没有这样的错误并且两台服务器上的架构相同时，这怎么可能发生，那么这怎么可能发生。以及如何修复它以使其再次工作以及将来如何防止此类事情发生。
还请让我知道除此之外我还应该期待什么。
它永远不会发生在主人身上，为什么？
该系列SQL是从master复制的，
如果master中已经存在该记录，则mysql拒绝master
但是在从站上，如果失败并且复制位置没有前进到下一个 SQL（它只是停止了）
原因？
该记录的插入查询直接写入从属服务器，而不使用来自主服务器的复制
怎么修？
跳过slave上的错误，比如
SET GLOBAL sql_slave_skip_counter = N;
详细信息 - http://dev.mysql.com/doc/refman/5.0/en/set-global-sql-slave-skip-counter.html
或者删除slave上的重复记录，再次恢复slave（让复制做插入）
更糟糕的情况是，您需要再次重新设置以确保从站上的数据完整性。
如何预防？
检查应用程序级别，确保没有直接写入从机
这包括您如何在命令提示符下连接到 mysql
拆分可以读写的mysql用户，
因此，您的应用程序应该在不需要写入时使用读取用户（主从）。
使用写入用户（仅限主用户）执行需要写入数据库的操作。
跳过计数器始终不是一个可行的解决方案，您正在跳过记录，但它可能会影响进一步的记录。
以下是关于为什么 sql slave skip counter 不好的完整详细信息。
您可以删除从数据库中大于重复的行；
DELETE FROM mydatabasename.atable WHERE ID>=174465;
然后
START SLAVE;