Log tracking initialisation does not find last valid bitmap data correctly

[Laurynas Biveinis]

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.

[Laurynas Biveinis (laurynas-biveinis)]

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.

[Laurynas Biveinis (laurynas-biveinis)]

     https://github.com/percona/percona-server/pull/1313
     https://github.com/percona/percona-server/pull/1314
     https://github.com/percona/percona-server/pull/1315

[Shahriyar Rzayev (rzayev-sehriyar)]

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