GTID Replication Error: GTID Set Mismatch Detected

Problem Context

A MariaDB cluster that has recently transitioned from GTID mode OFF to ON is exhibiting a GTID set mismatch error during replication. The source and replica servers report differing GTID sets in mysql.gtid_executed, causing replication to halt and manual intervention to be required.

Goal and Constraints

The primary goal is to determine a reliable, automated method for reconciling divergent GTID sets without data loss or replication lag. Constraints include maintaining transactional integrity, avoiding gaps in the GTID sequence, and ensuring that the solution works across MariaDB 10.5+ releases.

Unresolved Decision

While the documentation outlines manual reconciliation steps, it does not specify how to handle split-brain scenarios that arise after a network partition or an abrupt GTID mode switch. The lack of an automated, version‑agnostic approach leaves administrators uncertain about the safest path forward.

Specific Questions

1. What is the recommended sequence of commands to safely merge divergent GTID sets on a replica after a network partition in MariaDB 10.5+?
2. Does MariaDB provide any built‑in mechanism to detect and resolve GTID gaps automatically during a mode transition?
3. What impact does a manual GTID set reconciliation have on replication latency and data consistency in a multi‑node cluster?