Use este `Summary`: ```text Regression in 11.4.13: ROW replication of system-versioned tables fails with ER_DUP_ENTRY when secure_timestamp=YES ```

Title:
Regression in MariaDB 11.4.13: ROW replication of system-versioned tables fails with duplicate key when secure_timestamp=YES

Description:
After upgrading from MariaDB 11.4.12 to MariaDB 11.4.13, replication started failing with duplicate primary key errors on system-versioned tables.

The topology is a circular/master-master setup, but the problem was reproduced locally with a minimal Docker-based test using two MariaDB containers.

Production environment:

• MariaDB version: 11.4.13-MariaDB-deb12-log
• OS/package: mariadb.org binary distribution, Debian 12
• Replication mode: classic file/position replication, not GTID
• binlog_format=ROW
• binlog_row_image=MINIMAL
• log_slave_updates=ON
• slave_run_triggers_for_rbr=NO
• slave_parallel_threads was also tested with 0
• secure_timestamp was initially set to YES
• Affected tables use WITH SYSTEM VERSIONING

Example production error:
Could not execute Write_rows_v1 event on table maisdeliveryap.cardapio;
Duplicate entry '4697987' for key 'PRIMARY', Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000002

The same kind of error also happened on other system-versioned tables, such as restaurante and log_api.

We verified that:

• GTID was not being used: MASTER_USE_GTID=no / Using_Gtid: No
• slave_run_triggers_for_rbr=NO
• parallel replication was not the cause; the issue still happened with slave_parallel_threads=0
• auto_increment values were not exhausted and were not the root cause
• master and replica table structures matched
• duplicate rows already existed on the replica because they were part of the restored physical backup, but replication then attempted to apply the system-versioned history Write_rows event and failed with ER_DUP_ENTRY

Minimal reproduction:
I created a small Docker lab with two MariaDB servers and a simple system-versioned table:

CREATE TABLE cardapio (
idCardapio INT(11) NOT NULL AUTO_INCREMENT,
dsNome VARCHAR(45) NOT NULL,
qtEstoque INT(11) NOT NULL DEFAULT 9999,
dtCriacao DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (idCardapio)
) ENGINE=InnoDB WITH SYSTEM VERSIONING
PARTITION BY SYSTEM_TIME (
PARTITION p_hist HISTORY ENGINE=InnoDB,
PARTITION p_cur CURRENT ENGINE=InnoDB
);

Then I configured classic ROW replication and executed INSERT + UPDATE statements on the primary.

Test results:

MariaDB 11.4.12:

• binlog_row_image=MINIMAL + secure_timestamp=YES: PASS
• binlog_row_image=FULL + secure_timestamp=YES: PASS
• binlog_row_image=MINIMAL + secure_timestamp=REPLICATION: PASS
• binlog_row_image=FULL + secure_timestamp=REPLICATION: PASS

MariaDB 11.4.13:

• binlog_row_image=MINIMAL + secure_timestamp=YES: FAIL with ER_DUP_ENTRY 1062
• binlog_row_image=FULL + secure_timestamp=YES: FAIL with ER_DUP_ENTRY 1062
• binlog_row_image=MINIMAL + secure_timestamp=REPLICATION: PASS
• binlog_row_image=FULL + secure_timestamp=REPLICATION: PASS

This suggests a behavior regression between 11.4.12 and 11.4.13 for ROW replication of system-versioned tables when secure_timestamp=YES.

Workaround:
Changing secure_timestamp from YES to REPLICATION on the replica fixes the issue. After restarting the replica with:

secure_timestamp=REPLICATION

replication works again in STRICT mode with:

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: 0
• Last_SQL_Errno: 0

Documentation concern:
The documentation appears inconsistent.

The system-versioned tables documentation says that for replication duplicate key problems, secure_timestamp=YES should be used on the replica.

However, the secure_timestamp system variable documentation says that YES should not be used on replicas, and that REPLICATION allows the replication thread to adjust the timestamp to match the primary.

Based on the reproduction above, MariaDB 11.4.13 requires secure_timestamp=REPLICATION, not YES.

Expected behavior:
Either:
1. secure_timestamp=YES should continue to work as it did in 11.4.12, or
2. the documentation for system-versioned table replication should be updated to recommend secure_timestamp=REPLICATION for replicas.

Actual behavior:
MariaDB 11.4.13 fails ROW replication of system-versioned tables with ER_DUP_ENTRY when secure_timestamp=YES is configured on the replica.

Relevant documentation:

• System-Versioned Tables:
  https://mariadb.com/docs/server/reference/sql-structure/temporal-tables/system-versioned-tables

• secure_timestamp:
  https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/system-variables/server-system-variables