Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.2.3
-
None
-
Windows Server 2012 R2 Standard
128 GB RAM
-
10.2.4-1
Description
MariaDB server crashed after upgrade from MariaDB 10.2.2.
MariaDB 10.2.2 crashed also after I did an upgrade from MariDB 5.5 to 10.2.2.
This crash was solved with 10.2.3.
Attachments
Issue Links
- duplicates
-
MDEV-9663 InnoDB assertion failure: *cursor->index->name == TEMP_INDEX_PREFIX, or !cursor->index->is_committed()
-
- Closed
-
- relates to
-
MDEV-18272 InnoDB fails to rollback after exceeding FOREIGN KEY recursion depth
-
- Closed
-
-
MDEV-12463 Unable to find a record to delete-mark just after upgrading from 10.2.4 to 10.2.5
-
- Closed
-
In MG-GUI-SSD2.err, I see several purge error messages before the assertion failure:
2017-01-10 9:11:11 3972 [ERROR] InnoDB: tried to purge non-delete-marked record in index `NCI_MsgID2Message_Message` of table `zissystem`.`msgid2message`
…
2017-01-10 09:11:44 0x2ce4 InnoDB: Assertion failure in thread 11492 in file row0ins.cc line 277
InnoDB: Failing assertion: !cursor->index->is_committed()
The data set is corrupted, and it would be interesting to know where the corruption was introduced in the first place. MySQL 5.5 already? There might have been some bug fixes in this area over the past few years, but I believe that the problem is not fully fixed. Because the problem is so hard to repeat, I think that the InnoDB delete buffering that I implemented in MySQL 5.5 could be to blame. Both the error messages and the assertion failure occur for a secondary index. See my comments in MySQL Bug #61104.
The InnoDB process of purge removes old undo log records and delete-marked index records that are no longer needed for MVCC. All purgeable records should be delete-marked in the index. The error here is that we find a record that is not delete-marked, even though it should be. Probably because purge refused to remove these records, INSERT would crash when it finds that the key already exists and is not delete-marked.
I would say that this bug is a duplicate of
MDEV-9663. I had replaced the assertion failure expression with a logically equivalent one in MySQL 5.7, which was merged to MariaDB 10.2.