Multi-threaded innodb_log_archive parsing

Log based recovery will start from a checkpoint up to which all changes have been persistently written. It has to parse all write-ahead log records that have been written since this point. Normal recovery starts from the latest checkpoint as of the time when the server had been killed. Applying log after a backup will start from the latest checkpoint as of the time when the backup process was started. For large log volumes, this could take a long time.

The most recent improvement in this area was MDEV-29911, which improved the memory management and implemented multi-threaded write-only page recovery. But, before we can start to apply log records in multiple threads, the log needs to be parsed into the recv_sys.pages data structure. Because this is taking place in a single thread, processing large amounts of log is all but single-threaded, according to Amdahl's law.

Before the introduction of the innodb_log_archive=ON format (MDEV-37949), the InnoDB redo log would store at most two pointers to the latest log checkpoints, and only one of them is expected to be valid. Therefore, the only option was to parse the log sequentially.

In the innodb_log_archive=ON format, each log file header will store up pointers to several checkpoints. When restoring an incremental or full backup that makes use of this format, we may specify the applicable checkpoint with the option innodb_log_recovery_start. If this is behind the latest checkpoint, then it will be possible to start parsing concurrently from each checkpoint between innodb_log_recovery_start and the latest checkpoint. The biggest benefit should be expected for the MDEV-39054 incremental backup scenario.