2015-03-31 69 views
0

MySQL复制对我来说有点新,但它看起来像我一直在努力,直到我不明白的一些错误。奇怪的MySQL复制更新错误(Magento)

一些背景:我将所有数据库(通过SSL)从MySQL 5.6.22服务器复制到MariaDB 10.0.15服务器,该服务器除了作为专用的从服务器之外没有其他任何功能。它执行一些查询,但随后遇到Magento数据库的更新问题。如果我跳过这个查询,它会碰到一个类似的查询导致相同的错误。

这是从状态给我的错误:

无法执行Update_rows上表magento_db.log_visitor事件;列'visitor_id'不能为空,Error_code:1048;在'log_visitor'中找不到记录,Error_code:1032;列'visitor_id'不能为空,Error_code:1048;处理程序错误HA_ERR_KEY_NOT_FOUND;事件的主日志的mysql-bin.000121,end_log_pos 7656个

Exec_Master_Log_Pos是7215,但我认为这是无关紧要的,错误的是,在未来的查询(/事务块)。

这里是一块(详细)mysqlbinlog可以的:

COMMIT/*!*/; 
 
# at 7215 
 
#150330 2:19:45 server id 1 end_log_pos 7292 CRC32 0xf975481b \t Query \t thread_id=25 \t exec_time=0 \t error_code=0 
 
SET TIMESTAMP=1427674785/*!*/; 
 
BEGIN 
 
/*!*/; 
 
# at 7292 
 
# at 7358 
 
#150330 2:19:45 server id 1 end_log_pos 7358 CRC32 0x0312921e \t Table_map: `magento_db`.`log_url_info` mapped to number 2528 
 
#150330 2:19:45 server id 1 end_log_pos 7497 CRC32 0xe3704a8b \t Write_rows: table id 2528 flags: STMT_END_F 
 
### INSERT INTO `magento_db`.`log_url_info` 
 
### SET 
 
### @1=12534083 /* LONGINT meta=0 nullable=0 is_null=0 */ 
 
### @2='http://www.myshop.com/catalog/category/view/id/29?cat=31&color=22&dir=desc&order=position&price=9-' /* VARSTRING(765) meta=765 nullable=1 is_null=0 */ 
 
### @3=NULL /* VARSTRING(765) meta=765 nullable=1 is_null=1 */ 
 
# at 7497 
 
# at 7565 
 
#150330 2:19:45 server id 1 end_log_pos 7565 CRC32 0x340012cd \t Table_map: `magento_db`.`log_visitor` mapped to number 2513 
 
#150330 2:19:45 server id 1 end_log_pos 7656 CRC32 0xd3d2e26f \t Update_rows: table id 2513 flags: STMT_END_F 
 
### UPDATE `magento_db`.`log_visitor` 
 
### WHERE 
 
### @1=3036630 /* LONGINT meta=0 nullable=0 is_null=0 */ 
 
### SET 
 
### @2='deq65v4ks7tgahp2lvih8s74j1' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ 
 
### @3=1427667585 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */ 
 
### @4=1427667585 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ 
 
### @5=12534083 /* LONGINT meta=0 nullable=0 is_null=0 */ 
 
### @6=1 /* SHORTINT meta=0 nullable=0 is_null=0 */ 
 
# at 7656 
 
# at 7714 
 
#150330 2:19:45 server id 1 end_log_pos 7714 CRC32 0xc1eee09b \t Table_map: `magento_db`.`log_url` mapped to number 2529 
 
#150330 2:19:45 server id 1 end_log_pos 7770 CRC32 0xf7bcccad \t Write_rows: table id 2529 flags: STMT_END_F 
 
### INSERT INTO `magento_db`.`log_url` 
 
### SET 
 
### @1=12534083 /* LONGINT meta=0 nullable=0 is_null=0 */ 
 
### @2=3036630 /* LONGINT meta=0 nullable=1 is_null=0 */ 
 
### @3=1427667585 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ 
 
# at 7770 
 
#150330 2:19:45 server id 1 end_log_pos 7801 CRC32 0x51775dd4 \t Xid = 29537 
 
COMMIT/*!*/; 
 
# at 7801 
 
#150330 2:19:53 server id 1 end_log_pos 7886 CRC32 0xd6d724c7 \t Query \t thread_id=26 \t exec_time=0 \t error_code=0 
 
SET TIMESTAMP=1427674793/*!*/;

visitor_id是第一列表示在phpMyAdmin,但是当我执行SHOW COLUMNS FROM log_visitor;也,所以我猜此列映射到'@ 1'(无法找到如何验证这一点)。但是当我用visitor_id 3036630搜索一条记录时,它只找到一条记录。请注意,这不是由于外部查询,当我再次执行START SLAVE;时,它会挂起相同的错误。另外,我尝试在slave上运行mysql_upgrade,但除了一些警告之外,这没有任何解决办法。

底线是:我不知道如何解释这个错误,我可能看错了查询吗?我觉得应该不会有错误,也许有些不兼容?

欢迎任何建议!

编辑:按照要求,一个SHOW CREATE TABLE,这似乎在两台服务器上相同做一个差异后,除了增量指标:

CREATE TABLE `log_visitor` (
 
`visitor_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Visitor ID', 
 
`session_id` varchar(64) NOT NULL COMMENT 'Session ID', 
 
`first_visit_at` timestamp NULL DEFAULT NULL COMMENT 'First Visit Time', 
 
`last_visit_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Last Visit Time', 
 
`last_url_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'Last URL ID', 
 
`store_id` smallint(5) unsigned NOT NULL COMMENT 'Store ID', 
 
PRIMARY KEY (`visitor_id`) 
 
) ENGINE=InnoDB AUTO_INCREMENT=3036631 DEFAULT CHARSET=utf8 COMMENT='Log Visitors Table'

奴隶被创造删除所有数据库(我已经尝试了多次),在获得对主服务器的读锁定之后,对所有数据库执行mysqldump,将其导入到从服务器,然后在正确的位置启动从服务器。它做了一些查询,当我看,它已经得到了像这里描述的更新错误。

+0

这两个DB的表格模式是否完全相同?由于列定义的差异,这些错误会提示在主服务器上工作的更新不适用于从服务器。 – 2015-03-31 19:49:45

+0

请提供'SHOW CREATE TABLE'。 – 2015-03-31 20:55:52

+0

更新了这个问题,因为我明显登出了 – Mike 2015-03-31 22:02:49

回答

1

这似乎是我找到了解决方案。我曾经为master写过一个很好的my.cnf,其中包括MySQL 5.6设置“binlog_row_image = MINIMAL”。这会导致binlog跳过UPDATE的SET-clause中的列,这些列已经在WHERE子句中并且保持不变。 MariaDB似乎没有实现此设置,并且默认的binlog ROW格式需要所有字段的值。