[Warning] [MY-011825] [Xtrabackup] Log block checksum mismatch

MySQL & MariaDB Percona XtraBackup
1

Hi
I am having some warning and I am trying to identify if this is a real problem.

So, I am backing up MySQL 8.0.40, using Percona xtrabackup 8.0.35-31 on Oracle Linux 8.10.
The data size is big (above 30T). The server is read only replica (statement based).

Here is the backup command and parameters:

time xtrabackup --no-defaults --backup --compress
–parallel=8 --compress-threads=8 --register-redo-log-consumer
–host=localhost --socket=/srv/ppp/run/mysqld_ppp.sock --port=3306 --slave-info=1 --target-dir=/srv/backup/ppp/current_db
2>&1 | tee /srv/backup/ppp/_xb.log

And here is part of the xtrabackup log that is worrying me:

2024-11-13T18:44:14.319679+02:00 1 [Note] [MY-011825] [Xtrabackup] >> log scanned up to (414897578011176)
2024-11-13T18:44:15.324610+02:00 1 [Warning] [MY-011825] [Xtrabackup] Log block checksum mismatch (block no 0 at lsn 414897584118272): expected 0, calculated checksum 3965168067 block epoch no: 0
2024-11-13T18:44:15.324731+02:00 1 [Warning] [MY-011825] [Xtrabackup] this is possible when the log block has not been fully written by the server, will retry later.
2024-11-13T18:44:15.412399+02:00 1 [Note] [MY-011825] [Xtrabackup] >> log scanned up to (414897584118272)

I usually see this in 1-2 minutes after I start the backup.
My redo log size was 4G, I even increased it to 20G (innodb_redo_log_capacity) but this did not help.
I doubt that it’s related to the redo logs size, because I have never seen it being used more than 2G (Innodb_redo_log_logical_size status var) at any time. Also I have --register-redo-log-consumer parameter for xtrabackup, just in case.

Although I think I have enough IO, I played with different number of threads 1/2/4/8, and also tried not using compression at all, but this generally just changes the time I need to wait in order to see the warning.

For now I don’t have complete backup that to try to prepare, so I dont know if this is a real problem or just a warning.

Please help :slight_smile:

Regards,
Georgi

2

Hey there @edhunter,

Yikes! Dataset sizes over 3TB usually call for snapshot-style backups. (At least, in my personal opinion).

Can you use the flag --safe-slave-backup and see if this still occurs?

3

I remember in the past I had some troubles with --safe-slave-backup flag the replication were stopping for the duration of the backup, no matter that we don’t have temporary tables.
But anyway, I will try it later and report back.

4

update1:
Running with --safe-slave-backup for about 20 minutes, I don’t see the “Log block checksum mismatch” warnings. But the replication has stopped in the beginning of the backup.
If I stop the replication manually and run the backup, the warnings also don’t appear.

So that is kind of workaround, but not acceptable in my case I cant afford this server to stay without replication for many hours.

update2:
I have now a backup complete with no compression and without --safe-slave-backup.
It had the checksum warnings but at the end I have “0 [Note] [MY-011825] [Xtrabackup] completed OK!”
So far so good, I am currently running the prepare on this backup for already a hour and there is no any issues.

It seems that the message “[Warning] [MY-011825] [Xtrabackup] Log block checksum mismatch” is not a problem, but it still is bugging me why it’s happening :slight_smile:
I’ve seen in similar previous report for older version of xtrabackup80 this was actually reported as error.

5

You can safely ignore this warning. This happens because xtrabackup and server are operating on the same block(as indicated in the error log).

Typically, this means xtrabackup has parsed all redo logs and still copying data files.

6

Thanks.
I thought it would be so but couldn’t not be sure :slight_smile: