标题真的说了这一切。 这是LAST_ERROR ：
Last_Error: Error 'Cannot add or update a child row: a foreign key constraint fails (`cd1n401`.`cdi_catalog_product_entity_int`, CONSTRAINT `FK_CDI_CAT_PRD_ENTT_INT_ENTT_ID_CDI_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`entity_id`) REFERENCES `cdi_catalog_product_entity` (`entity_id`)' on query. Default database: 'cd1n401'. Query: 'INSERT INTO `cdi_catalog_product_entity_int` (`entity_type_id`,`attribute_id`,`store_id`,`entity_id`,`value`) VALUES ('4', '178', '0', '3', NULL), ('4', '180', '0', '3', NULL), ('4', '181', '0', '3', NULL), ('4', '182', '0', '3', NULL) ON DUPLICATE KEY UPDATE `value` = VALUES(`value`)'
有没有人为磁电机设置一个主从？
通常这种复制错误是由主机和从机之间的数据不一致造成的 – 由于查询成功，主机上的约束显然得到了满足，但它不在从机上。
在那一刻，你的整个（奴隶）数据库变得可疑。 你可以追踪特定的不一致并手动修复，但你怎么知道这是唯一的？ 安全的做法是启动一个新的奴隶，一旦复制赶上，杀死旧的奴隶。
但是，这只是解决症状; 你首先需要考虑奴隶如何与主人不同步。 到目前为止，最常见的问题是在从机上运行修改（即非SELECT ）命令。 不幸的是，你不能完全禁用它，因为MySQL的复制过程需要写权限，但你可以审核谁有权限。 每个有查询访问权限的人都需要知道他们不应该运行UPDATE （并且，理想情况下限制他们的权限，所以他们不能 ）。 每一个与slave通信的代码也只需要做SELECT 。
另一个可能的原因是用于创build从服务器的初始数据集的过程（例如，从主服务器的备份中启动）存在缺陷，并且在复制甚至从未开始之前就开始不一致。