标题确实说明了一切。以下是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`)'
有人曾经为 Magneto 设置过主从设备吗?
答案1
通常,此类复制错误是由主服务器和从服务器之间的数据不一致引起的 - 由于查询成功,主服务器上的约束显然得到满足,但从服务器上却并非如此。
此时,您的整个(从属)数据库都会变得可疑。您可以跟踪特定的不一致并手动修复它,但您怎么知道这是唯一的一个?安全的做法是启动一个新的从属,一旦复制完成,就关闭旧的从属。
但是,这只是解决了症状;您需要首先考虑从服务器如何与主服务器不同步。到目前为止,最常见的问题是在从SELECT
服务器上运行修改(即非)命令。不幸的是,您无法完全禁用此功能,因为 MySQL 的复制过程需要写入权限,但您可以审核谁有权限。每个对从服务器有查询权限的人都需要知道他们不应该运行UPDATE
s(并且,理想情况下,限制他们的权限,以便他们不能)。与从属设备对话的每一段代码同样只需要执行SELECT
s 即可。
另一个可能的原因是,您用于创建从属服务器的初始数据集(例如,从主服务器的备份中启动它)的过程存在缺陷,并且在复制开始之前就出现了不一致的情况。