[MDEV-17913] Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work Created: 2018-12-05 Updated: 2021-12-15 Resolved: 2021-04-06 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Encryption, Storage Engine - Aria |
| Affects Version/s: | 10.2, 10.3, 10.4, 10.5 |
| Fix Version/s: | 10.4.19, 10.5.10 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Elena Stepanova | Assignee: | Michael Widenius |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | affects-tests | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Description |
|
Upon next startup after an intentional crash (during DML flow), Aria recovery does not return any errors:
However, further CHECK on a table shows a problem:
Manual repair works:
Setting --aria-recover-options to non-default NORMAL or FORCE does not change anything. The datadir after the initial crash, before any attempt to recover, is here: Unpack and start the server with
Adjust the path to keys.txt if needed. After recovery, run
The general log for the test flow prior to the initial crash is in mysql.log. The test to run the complete flow (might require several trials):
RQG branch and revision are important here, you might not have some of the required files in other branches. Couldn't reproduce on 10.1 with the given test, but possibly there is some difference in the test flow. |
| Comments |
| Comment by Elena Stepanova [ 2019-10-01 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Other errors happening in similar circumstances (failed automatic recovery of encrypted transactional tables):
or
... and many more variations, I won't list them all. After this bug is fixed, workarounds from my tests (forced explicit REPAIR) will need to be removed, and tests to be run again, to see if any variations remain. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2020-12-21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The raw MTR test below currently reproduces at least one of the problems every time.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michael Widenius [ 2021-04-02 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This error happened because of a wrong test in encryption code that wrote a random number over the LSN for pages for transactional Aria tables during repair. The effect was that after an ALTER TABLE ENABLE KEYS of a encrypted I have fixed this and also fixed that CHECK TABLE will report if there are any wrong LSN's stored in the table. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michael Widenius [ 2021-04-02 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Fix pushed to 10.4. Fix with extended check table will shortly be pushed to 10.5 (now in testing) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michael Widenius [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Pushed bug fix to 10.4 and extended version, with test and enhanced aria_chk, to 10.5 |