gh-ost: StreamEvents encountered unexpected error: data len 1259 < expected 14985

Hi,

when I try to alter table I always have the same error

Copy: 85118000/117939928 72.2%; Applied: 60049; Backlog: 0/1000; Time: 5h1m20s(total), 5h1m20s(copy); streamer: dbcn02-bin.000013:339139251; State: migrating; ETA: 1h56m11s
Copy: 85138000/117939928 72.2%; Applied: 60049; Backlog: 0/1000; Time: 5h1m25s(total), 5h1m25s(copy); streamer: dbcn02-bin.000013:469610748; State: migrating; ETA: 1h56m7s
Copy: 85156000/117939928 72.2%; Applied: 60049; Backlog: 0/1000; Time: 5h1m30s(total), 5h1m30s(copy); streamer: dbcn02-bin.000013:601846216; State: migrating; ETA: 1h56m4s
2017/10/25 12:10:19 binlogstreamer.go:47: [error] close sync with err: data len 1259 < expected 14985
2017-10-25 12:10:19 INFO StreamEvents encountered unexpected error: data len 1259 < expected 14985
Copy: 85176000/117939928 72.2%; Applied: 60049; Backlog: 0/1000; Time: 5h1m35s(total), 5h1m35s(copy); streamer: dbcn02-bin.000013:635376151; State: migrating; ETA: 1h56m0s
2017-10-25 12:10:24 FATAL 61 successive failures in streamer reconnect at coordinates dbcn02-bin.000013:4

gh-ost --version 1.0.42

mysql 5.7.18-15-57-log | Percona XtraDB Cluster (GPL), Release rel15, Revision 7693d6e, WSREP version 29.20, wsrep_29.20

my command was

/opt/gh-ost/gh-ost --allow-on-master --allow-master-master --switch-to-rbr --timestamp-old-table --verbose --max-load=Threads_running=25 --critical-load=Threads_running=1000 --chunk-size=2000 --max-lag-millis=1500 --default-retries=60 --conf=/path/to/my.cnf --critical-load-interval-millis=2500 --discard-foreign-keys --cut-over=two-step --panic-flag-file=/tmp/ghost.panic.flag --postpone-cut-over-flag-file=/tmp/ghost.postpone.flag --host=“master” --port=3306 --assume-master-host=“master” --database=“db” --table=“table” --alter=“engine=innodb” --execute

table I want to alter

CREATE TABLE `user_chat_messages` (
  `userChatMessageId` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `chatMessageId` bigint(20) unsigned DEFAULT NULL,
  `userId` bigint(20) unsigned DEFAULT NULL,
  `isRead` tinyint(4) DEFAULT NULL,
  `isDeleted` tinyint(4) DEFAULT NULL,
  PRIMARY KEY (`userChatMessageId`),
  KEY `chatMessageId` (`chatMessageId`),
  KEY `userId` (`userId`),
  KEY `isRead` (`isRead`),
  KEY `isDeleted` (`isDeleted`),
  CONSTRAINT `user_chat_messages_ibfk_1` FOREIGN KEY (`chatMessageId`) REFERENCES `chat_messages` (`chatMessageId`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `user_chat_messages_ibfk_3` FOREIGN KEY (`userId`) REFERENCES `users` (`userId`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=456428768 DEFAULT CHARSET=utf8

Thanks for any help on this

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (9 by maintainers)

Most upvoted comments

@timvaillancourt Thank you very much for your reply. I have verified that this problem does not occur in version 1.0.45. I saw that it was written in the changelog of version 1.0.45: Fix to long JSON values. I also verified that my data does exist in the json field, and when the length is greater than 300, this problem will always occur. I tried to check go-mysql, and found that the problem appeared on json_binary.go. From the perspective of learning, I was just curious why it appeared before, but it did not appear again after the subsequent version was fixed. What is the trigger logic of this bug?

boomballa on Dec 26, 2022