[MDEV-22169] Recovery fails after failing to insert into mlog_init Created: 2020-04-06 Updated: 2020-04-07 Resolved: 2020-04-07 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.5.2 |
| Fix Version/s: | 10.5.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthias Leich | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | recovery | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
|
| Comments |
| Comment by Matthias Leich [ 2020-04-06 ] | ||||||||||
|
Remainings with RR trace of the RQG run described above | ||||||||||
| Comment by Marko Mäkelä [ 2020-04-06 ] | ||||||||||
|
I painstakingly debugged the rr replay of the server that was killed before the recovery, and everything is fine there, as far as I can tell. The problem occurs at crash recovery. My computer recovered the saved dataset just fine (only complaining about an internal XA transaction that was recovered in the XA PREPARE state), even after I reduced to innodb_buffer_pool_size=32M. We have a rr replay of the failed recovery:
We switch to STORE_NO mode, and then we will simply throw away the PAGE_FREE record that we successfully parsed for the problematic page:
There will be no attempt to reread the redo log record. You should see that at when 1586 we switch to STORE_NO mode, and at when 1593 we throw away the FREE_PAGE record. The call to mlog_init.add() in recv_sys_t::add() will be skipped, because store==STORE_NO. As far as I can tell, there could be a similar problem with page initialization records already in 10.2. Before |