binlog_expire_logs_seconds has been there since 10.6.1 as the expire_logs_days did lack granularity less than 1.

Are you using binlog_row_image= NOBLOB or MINIMAL to reduce size?

Also see:

• MDEV-29196
• MDEV-29195

Thanks for your quick reply. I was not aware of the new binlog_expire_logs_seconds when we upgraded to 10.6.x a while back!

I suppose we should first start using MINIMAL, will it cause any issues on the replication slave when changing it dynamically?

EDIT: I did a DROP TABLE xxx on primary cluster, for a table being child of foreign keys and obviously it failed, but for some reason the statement is being replicated and makes the slave constantly exit !? Could it be a side-effect of minimal and how to workaround this?

> I suppose we should first start using MINIMAL, will it cause any issues on the replication slave when changing it dynamically?

Not that I'm aware of. Please do a search here around binlog_row_image=MINIMAL.

> I did a DROP TABLE xxx on primary cluster, for a table being child of foreign keys and obviously it failed, but for some reason the statement is being replicated and makes the slave constantly exit !? Could it be a side-effect of minimal and how to workaround this?

Unsure. Please do new bug report, with MariaDB versions, and examples of your table structures.

MDEV-31404 Implement binlog_space_limit

binlog_space_limit is a variable in Percona server used to limit the total
size of all binary logs.

This implementation is based on code from Percona server 5.7.

In MariaDB we decided to call the variable max-binlog-total-size to be
similar to max-binlog-size. This makes it easier to find in the output
from 'mariadbd --help --verbose'). MariaDB will also support
binlog_space_limit for compatibility with Percona.

Some internal notes to explain implementation notes:

• When running MariaDB does not delete binary logs that are either
  used by slaves or have active xid that are not yet committed.

Some implementation notes:

• max-binlog-total-size is by default 0 (no limit).
• max-binlog-total-size can be changed without server restart.
• Binlog file file sizes are checked on startup, or if
  max-binlog-total-size is set to a value > 0, not for every log write.
  The total size of all binary logs is cached and dynamically updated
  when updating the binary log on on binary log rotation.
• max-binlog-total-size is checked against existing log files during server
  start, binlog rotation, FLUSH LOGS, when writing to binary log
  or when max-binlog-total-size changes value.
• Option --slave-connections-needed-for-purge with 1 as default added.
  This allows one to ensure that we do not delete binary logs if there
  is less than 'slave-connections-needed-for-purge' connected.
  Without this option max-binlog-total-size would potentially deleted
  binlogs needed by slaves on server startup or when a slave disconnects
  as there are then no connected slaves to protect active binlogs.
• If binary log is on and max-binlog-total_size <> 0 then the status
  variable 'Binlog_disk_use' shows the current size of all old binary
  logs + the state of the current one.
• Removed test of strcmp(log_file_name, log_info.log_file_name) in
  purge_logs_before_date() as this is tested in can_purge_logs()
• To avoid expensive calls of log_in_use() we cache the result for the
  last log that is in use by a slave. Future calls to can_purge_logs()
  for this binary log will return false until a slave stats working on
  a new log.

ccounotte,
Could you please clarify your side note about DROP TABLE with foreign keys:

I did a DROP TABLE xxx on primary cluster, for a table being child of foreign keys and obviously it failed, but for some reason the statement is being replicated and makes the slave constantly exit !?

In this context, what is the primary cluster and what is the slave? Do you mean that the statement was replicated within a Galera cluster, between nodes? Or is it about traditional replication? Do you have an example of a binary log?

Review done: https://lists.mariadb.org/hyperkitty/list/developers@lists.mariadb.org/thread/EXIBNZ6PY4FQNBIUWJXS7SHKBMJWFPQU/