[MDEV-31098] InnoDB Recovery doesn't display encryption message when no encryption configuration passed Created: 2023-04-20 Updated: 2023-10-13 Resolved: 2023-10-13 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.6 |
| Fix Version/s: | 10.6.16, 10.10.7, 10.11.6, 11.0.4, 11.1.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Thirunarayanan Balathandayuthapani |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | recovery | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
An attempt to recover the attached data.tar.xz
A crude attempt at fixing this as follows caused a crash.
The problem is that the FIL_LOAD_DEFER return value causes InnoDB crash recovery to "think" that the file will be initialized by redo log records. The FIL_PAGE_LSN in page 0 of the file is 61,024,384, that is, after the checkpoint LSN 14,303,353. The first log record (a WRITE) that recv_sys_t::recover_deferred() would see for the page carries start_lsn = 79742990 and lsn = 79743157, which is even later. The deferred recovery fails because skip_read was not set for the recv_sys.pages entry. In case the problem is actually on the 'write' side (which I doubt), you can access rr replay of the previously killed server as follows:
It starts straight after bootstrap, at LSN 41114. |
| Comments |
| Comment by Thirunarayanan Balathandayuthapani [ 2023-04-25 ] | |
|
If we start the 10.6 server with the following command:
There is no failure in plain 10.6. This issue is related to | |
| Comment by Marko Mäkelä [ 2023-04-26 ] | |
|
Thank you for debugging this and fixing the | |
| Comment by Thirunarayanan Balathandayuthapani [ 2023-09-26 ] | |
|
Patch is in bb-10.6- | |
| Comment by Marko Mäkelä [ 2023-09-28 ] | |
|
Thank you, this is a simple fix. I’d suggest to modify the test encryption.innodb-redo-nokeys to ensure that the error message will be reported. | |
| Comment by Marko Mäkelä [ 2023-10-11 ] | |
|
I understand that due to the somewhat nondeterministic nature of page I/O, it may be hard to write a test that would invoke source include/search_pattern_in_file.inc to ensure that the error message was output. Can you still try to do that? Please also address my minor comments about the added function fil_crypt_check(). |