Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.11, 11.2(EOL), 11.4, 11.6(EOL)
Description
--source include/have_binlog_format_row.inc
|
--source include/master-slave.inc
|
|
|
CREATE TABLE t (a INT NOT NULL) ENGINE=CSV; |
INSERT INTO t VALUES (1),(2); |
DELETE FROM t; |
|
|
--sync_slave_with_master
|
|
|
# Cleanup
|
--connection master
|
DROP TABLE t; |
--source include/rpl_end.inc |
|
10.5 855c21eb99a5c6a6f9eb52eea6ce7d3279a9f8c3 |
2024-10-22 19:57:59 7 [ERROR] mariadbd: Can't find record in 't'
|
2024-10-22 19:57:59 7 [ERROR] Slave SQL: Could not execute Delete_rows_v1 event on table test.t; Can't find record in 't', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log master-bin.000001, end_log_pos 898, Gtid 0-1-3, Internal MariaDB error code: 1032
|
2024-10-22 19:57:59 7 [Warning] Slave: Can't find record in 't' Error_code: 1032
|
2024-10-22 19:57:59 7 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'master-bin.000001' position 733
|
It goes all the way back to 5.x versions, reproducible both on MySQL and MariaDB 5.5, but not on MySQL 5.6. I can only guess that we never bothered to file it back at the beginning because it was an upstream issue, but by the time when it was eventually fixed in MySQL 5.6, the versions already diverged and we weren't merging all bugfixes anymore.
Patch: https://lists.mariadb.org/hyperkitty/list/commits@lists.mariadb.org/thread/6C5SIP3657PIXU5OFIR7J67FYHX2M57B/
The root cause here is the value of unused null_bytes bits in the table records, when doing a table scan. The CSV engine sets these to 0, but the row-based replication code sets them to 1 in the records against which it compares.
There is code elsewhere in the server to handle this and accept whatever value the storage engine uses for those bits, for example handler::calculate_checksum(). The proposed patch adds the similar code for the row-based replication. The change only affects row-based replication of tables with no primary key, so the performance impact should be not critical.
I propose to fix this in 11.4 rather than old GA release. The bug has apparently been there forever, so doesn't seem worth to take any risk in old GA releases to fix it there.