Bug #107892 optimize for innodb recovery
Submitted: 15 Jul 2022 8:41 Modified: 15 Jul 2022 13:03
Reporter: alex xing (OCA) Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:8.0.29 OS:Any
Assigned to: CPU Architecture:Any

[15 Jul 2022 8:41] alex xing 
Description:
As we all known,in the period of innodb crash recovery, innodb need to find the end point for redo(recv_scan_log_recs ).
Consider this scenario：when mysqld crash, and the next block of log->flushed_to_disk_lsn just meets conditions：(no == expected_no) and (data_len == OS_FILE_LOG_BLOCK_SIZE)
This is where LOG_BLOCK_CHECKPOINT_NO(lowest 4 bytes of checkpoint_no) come in handy， but in function recv_scan_log_recs.
But I have three questions:
1. LOG_BLOCK_CHECKPOINT_NO(lowest 4 bytes of checkpoint_no) is not always increasing, How to check the sequence by LOG_BLOCK_CHECKPOINT_NO
2. and What does 0x80000000UL mean.
3. How LOG_BLOCK_CHECKPOINT_NO works

The judgment logic in recv_scan_log_recs as below:

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;
}

Note that block_no is derived from log_block_convert_lSN_to_no and Different LSNS‘s block_no  may be the same, that is (no == expected_no)

How to repeat:
just redo the code

Suggested fix:
If save the 8-byte CHECKPOINT NO, we can get the order directly by judging the 8-byte CHECKPOINT NO
[15 Jul 2022 13:03] MySQL Verification Team 
Hi Mr. xing,

Thank you for your bug report.

However, we do not see what you are reporting.

You are asking lot's of questions, while you have not provided any test case, nor have come up with the analysis of the source code that proves the bug.

Do note that you are raising a bug report for a problem that requires full ACID setting. That means that your OS and MySQL have to be configured for full ACID operations, as described in our Reference Manual. We do not see a description of how have you achieved that, including disabling filesystem cache on your OS.

Not a bug.