Is this not covered with --binlog-info=off?

According to the documentation, this is to retrieve the binary log file and position. Not the binary logs itself.

The same thing happens from the mariabackup SST script. I have therefore increased the priority.

I believe this is the reason we are now experiencing downtime due to the read lock being held while the large binary logs are being copied. With previous mariabackup versions the read lock was held for a few seconds, but now it's 44 minutes.

We found a working workaround for a customer with the same issue. We replaced the mariabackup binary containing the bug (version 10.3.35), with the last previously working binary (version 10.3.34).

1) backup the old binary: sudo cp /usr/bin/mariabackup /usr/bin/mariabackup_35
2) copy or install mariabackup version 10.3.34 to: /usr/bin/mariabackup

I'm experiencing what I suspect is the same issue in 10.6.8

I recently upgraded a replica used exclusively for taking backups from 10.1.48 -> 10.6.8, and using mostly the same command line for mariabackup instead of innobackupex - backup times have at least doubled and backup sizes have gone from 25-30GB to 120GB, and replication comes to a grinding halt while the BACKUP LOCK is taken and held while 2 days of binary logs are also backed up.

Old:
innobackupex --parallel=4 --compress --stream=xbstream ./ 2> /var/log/backup.log | ssh admin@host"cat > *path*/$(date +'%Y%m%d').xbstream

New:
mariabackup --backup --parallel=4 --stream=xbstream | pigz -p4 -c | ssh admin@host "cat > *path*/$(date +'%Y%m%d').xbstream.gz

I reverted Maria Backup to 10.6.7 and the behaviour is now as expected - i.e. binlogs are NOT copied. Backup is still slower and larger than in 10.1 with Xtrabackup but it's better than it was.

Same bug in mariabackup 10.5.16, there is no such problem in 10.5.15 with same cmd

mariabackup --user=root --password=xxx  --target-dir /home/db/b/tmp/$date --backup  --slave-info --safe-slave-backup --parallel=10

I'm also seeing the issue in version 10.5.16 on openSuse Leap 15.3 x86_64

Im my configuration, all binlog files are stored in the main database directory /var/lib/mysql/
Version 10.5.16 copies all binlog files into the backup directory, significantly increasing lock duration and backup size.
The previous version 10.5.15 did not include binlog files into the backup directory.

In my particular server configuration with automated backups stored on a remote host, these bloated backups impact server performance and waste resources (network traffic and backup space).
As a temporary worakround, I now use a low value for server variable "expire_logs_days" (alternatively "binlog_expire_logs_seconds") to purge binary logs faster than previously configured.

I have tried to implement the work-around of binary logs in a separate directory. This unfortunately did not make a difference. The binary logs are still copied from the custom binlog directory in the backup location.

This is a very serious bug, cause we store bin logs and snapshots of data for a long time. Each snapshot is around 1Tb and binlogs for 1Tb at all, so when we take an snapshot with new version of mariabackup - full backup is around 2Tb and long lock time while backuping.

Now we are using mariabackup 10.5.15 on 10.5.16 server, but i think it's not normal for such company like MariaDB not to solve it.

After an Update we also ran into this Bug. Please fix this or give us a hint how to prevent the creation of binlog archives in backup dir.

mariadb-backup --backup --host=localhost --user=root --password=xxx--target-dir /export/mariadbbackup/$(hostname)/$date --parallel=8 --compress --compress-threads=4

be286c57a looks ok to me

ok to push

https://github.com/MariaDB/server/commit/7fb1f919d0629d0c2bc68c616de557b658068fa0
https://github.com/MariaDB/server/commit/5b4154373a93b323c3502692c46dcc51b1731785
https://github.com/MariaDB/server/commit/5197519f4f7b31c61e3abccf75650e5356aecd4c