Bug #107900 InnoDB crash recovery optimize
Submitted: 18 Jul 2022 7:07 Modified: 18 Jul 2022 12:13
Reporter: alex xing (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S5 (Performance)
Version:8.0 OS:Any
Assigned to: CPU Architecture:Any

[18 Jul 2022 7:07] alex xing
Description:
There is NO need to maintain LOG_BLOCK_CHECKPOINT_NO in Redo Log Block.
We can get the end of the redo log in parse phase by LOG_BLOCK_HDR_NO.
Because Block_no of blocks in the same location of a redo file is not equal unless the file is larger than (512GB + 2k*2),and the maximum number of redo files is 512 GB(https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_file_size)

Attached Block_NO calculation method:
inline uint32_t log_block_convert_lsn_to_no(lsn_t lsn) {
  return ((uint32_t)(lsn / OS_FILE_LOG_BLOCK_SIZE) % LOG_BLOCK_MAX_NO + 1);
}
uint32_t LOG_BLOCK_MAX_NO = 0x3FFFFFFFUL + 1;

LOG_BLOCK_HDR_NO * 512/1024/1024/1024 = 512G

How to repeat:
just read the code

Suggested fix:
There is no need to maintain LOG_BLOCK_CHECKPOINT_NO
and no need to check LOG_BLOCK_CHECKPOINT_NO in recv_scan_log_recs

if (*scanned_checkpoint_no > 0 &&
    log_block_get_checkpoint_no(log_block) < *scanned_checkpoint_no &&
    *scanned_checkpoint_no - log_block_get_checkpoint_no(log_block) >
        0x80000000UL) {
  /* Garbage from a log buffer flush which was made
  before the most recent database recovery */

  ib::trace_2() << "Scanned cp no: " << *scanned_checkpoint_no
                << " block cp no "
                << log_block_get_checkpoint_no(log_block);

  break;
}
[18 Jul 2022 12:13] MySQL Verification Team
Hi Mr. xing,

Thank you for your performance improvement report.

We have analysed the code and we agree with you.

Verified as reported.