Bug #94827 | Error 1032 could be more informative (handler error HA_ERR_KEY_NOT_FOUND) | ||
---|---|---|---|
Submitted: | 29 Mar 2019 7:47 | Modified: | 29 Mar 2019 9:19 |
Reporter: | Simon Mudd (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.7.25 | OS: | CentOS (7) |
Assigned to: | CPU Architecture: | x86 | |
Tags: | Error 1032, replication |
[29 Mar 2019 7:47]
Simon Mudd
[29 Mar 2019 7:50]
Simon Mudd
This isn't the first time I've seen it but it does mean I have to trawl the relay logs to find the row update that failed (no tooling), and then find the details of that row on the master (no tooling), and then insert (without writing to binlogs) the upstream data into the slave, and then let replication continue (no tooling).
[29 Mar 2019 9:19]
MySQL Verification Team
Hello Simon, Thank you for the report and feedback. Verifying this as a reasonable feature request to improve the error message in the reported scenario. Sincerely, Umesh
[7 Oct 2020 10:46]
Hendrik Woltersdorf
I get the same messages, when we replicate a table without primary key from ndbcluster to inndodb. Inserts and Update work, but cause extreme cpu load and replication lag, when some replication backlog has accumulated. Version: 5.6.47-ndb-7.4.27-cluster-gpl
[7 Oct 2020 12:04]
MySQL Verification Team
Hendrik, you describe https://bugs.mysql.com/bug.php?id=53375 Summary: row_format=ROW or MIXED, every table should have a PRIMARY KEY.