Log tracking initialisation does not find last valid bitmap data correctly

Bug #1658055 reported by Laurynas Biveinis on 2017-01-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.5
Fix Released
High
Laurynas Biveinis
5.6
Fix Released
High
Laurynas Biveinis
5.7
Fix Released
High
Laurynas Biveinis

Bug Description

On server startup, log tracking tries to find the last good bitmap data, discard any later junk, and re-track its log. The intention of the algorithm is to open the last bitmap file, read the last page, check its checksum and last-page flag, and if either check fails, discard it, and seek back in the file.

However, the read loop condition currently is "while (!checksum_ok && read_offset > 0 && !is_last_page)", that is, only read back if both the checksum is wrong and the last page flag is set. This is invalid logic, it should either-or condition.

This results in log initializer stopping too early in the backward search, discarding the whole of the last bitmap file, and either regenerating its data if possible to re-read log, or needlessly creating a hole in bitmap-covered LSN range otherwise.

tags: added: bitmap xtradb

Another issue is if the whole of the opened file is discarded - the file truncated to zero, a new file is created with the same LSN, whereas the truncated-to-zero file could have been reused instead.

description: updated
summary: - Log tracking initialisation does not find the last good bitmap data
+ Log tracking initialisation does not find last valid bitmap data
correctly

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1051

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers