MDEV-34483 Backup may copy unnecessarily much log

[dr-m]

trafficstars

• [x] The Jira issue number for this PR is: MDEV-34483

Description

Let us use metadata_last_lsn as the target LSN for stopping backup. The metadata_to_lsn is actually a checkpoint LSN, which would be a starting point of a log scan.

Release Notes

TODO: What should the release notes say about this change? Include any changed system variables, status variables or behaviour. Optionally list any https://mariadb.com/kb/ pages that need changing.

How can this PR be tested?

./mtr --suite=mariabackup

Basing the PR against the correct MariaDB version

• [ ] This is a new feature or a refactoring, and the PR is based against the latest MariaDB development branch.
• [ ] This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

This bug affects all versions, but porting this to earlier major versions is not trivial due to 685d958e38b825ad9829be311f26729cccf37c46 and 1c55b845e0fe337e647ba230288ed13e966cb7c7.

PR quality check

• [x] I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• [x] For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[dr-m]

We’re partly back to the drawing board. I think that the issue that the current revision may solve is that mariadb-backup --backup will stop copying the log upon reaching the current LSN after BACKUP STAGE BLOCK_COMMIT. I am not sure how much the removal of re-parsing the checkpoint LSN would actually help.

@vaintroub Can you please help to make the test mariabackup.log_tables great again?

[vaintroub]

We’re partly back to the drawing board. I think that the issue that the current revision may solve is that mariadb-backup --backup will stop copying the log upon reaching the current LSN after BACKUP STAGE BLOCK_COMMIT. I am not sure how much the removal of re-parsing the checkpoint LSN would actually help.

@vaintroub Can you please help to make the test mariabackup.log_tables great again?

It is Aria, it is "backup stage" it is written 4.5 years after I was in charge of that utility. I'm happily ignorant now about the new trends in mariabackup, but I'll of course fix what I have broken, which is not the case here. I guess monty can make mariabackup great again, or even Vlad Lesin, who touched it much more recently, but I have to pass on that.

[dr-m]

I tried various things, but I did not figure out yet why the test mariabackup.log_tables would fail.

[dr-m]

Finally, covering the server execution with rr replay reveals that the test mariabackup.log_tables would fail because the last byte of the following file is exactly 1:

od -Ax -t x1  mysql-test/var/tmp/backup/mysql/general_log.CSM

000000 fe 01 6b 00 00 00 00 00 00 00 00 00 00 00 00 00
000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000020 00 00 01
000023

This would trip the following in read_meta_file() of storage/csv/ha_tina.cc:

  /* check crashed bit and magic number */
  if ((meta_buffer[0] != (uchar)TINA_CHECK_HEADER) ||
      ((bool)(*ptr)== TRUE))
    DBUG_RETURN(HA_ERR_CRASHED_ON_USAGE);

I am yet to check when this file was last written by the backed-up server and when it was copied by mariadb-backup --backup.