Current situation

On PXB 8.0, --slave-info can only be used without safe_slave_backup if there's GTID, or if the replica is single-threaded.

GTID won't need safe_slave_backup even with MTS replication, because GTID handles gaps and store applied TXs unitarily

MTS replication without GTID force "safe_slave_backup" so that STOP SLAVE is executed, which will fill the gaps.

Proposition:

With this precise context:

• Percona Server flavor

• replica_preserve_commit_order=true, so 8.0.26+

I believe we do not have to force "safe_slave_backup" for MTS replication.

Why on PS only: because performance_schema.log_status will be consistent per my understanding, and contains exec_master_log_pos + relay_master_log_file

Why with replica_preserve_commit_order:

Quoting doc,

• To avoid gaps occurring on a multithreaded replica, set replica_preserve_commit_order=ON (from MySQL 8.0.26) or slave_preserve_commit_order=ON (before MySQL 8.0.26). From MySQL 8.0.27, this setting is the default, because all replicas are multithreaded by default from that release. 

https://dev.mysql.com/doc/refman/8.0/en/replication-features-transaction-inconsistencies.html

Still, there's a potential issue with "source binary log position lags",

• Source binary log position lag. Even in the absence of gaps, it is possible that transactions after Exec_master_log_pos have been applied. That is, all transactions up to point N have been applied, and no transactions after N have been applied, but Exec_master_log_pos has a value smaller than N. In this situation, Exec_master_log_pos is a “low-water mark” of the transactions applied, and lags behind the position of the most recently applied transaction. This can only happen on multithreaded replicas. Enabling replica_preserve_commit_order or slave_preserve_commit_order does not prevent source binary log position lag.

Current implementation already prioritize performance_schema.log_status,

https://github.com/percona/percona-xtrabackup/blob/b3a3c3dd0c558782c65798d100a979c8ec7e37b4/storage/innobase/xtrabackup/src/backup_mysql.cc#L1286-L1392

• it's taking show slave status, and creating a "channels" hashmap

• it's also iterating on "log_status.channels", taken from performance_schema.log_status [https://github.com/percona/percona-xtrabackup/blob/b3a3c3dd0c558782c65798d100a979c8ec7e37b4/storage/innobase/xtrabackup/src/backup_mysql.cc#L1[…]597|https://github.com/percona/percona-xtrabackup/blob/b3a3c3dd0c558782c65798d100a979c8ec7e37b4/storage/innobase/xtrabackup/src/backup_mysql.cc#L1576-L1597]

• Both are then merged for replica positions, prioritizing log_status