Trouver et neutraliser les transactions errant GTID

Commande

-- 1) On the source: get gtid_executed
SELECT @@GLOBAL.gtid_executed;

-- 2) On the replica: GTIDs missing on the source (empty result = clean)
SELECT GTID_SUBTRACT(@@GLOBAL.gtid_executed,
       'af6bc361-c353-11f1-8f12-f69e63ad6c0e:1-13') AS errant_gtids;

-- 3) If the content is harmless: commit an empty transaction per errant GTID on the source
SET GTID_NEXT = 'b030e5a6-c353-11f1-a887-523817ec642a:1'; BEGIN; COMMIT;
SET GTID_NEXT = 'b030e5a6-c353-11f1-a887-523817ec642a:2'; BEGIN; COMMIT;
SET GTID_NEXT = 'AUTOMATIC';

Ce que fait la commande

Détecte par différence d'ensembles GTID les transactions exécutées directement sur une réplique sans équivalent sur la source (errant), et aligne les ensembles GTID de la topologie en les marquant par des transactions vides sur la source.

Quand l'utiliser

Comme vérification de routine avant failover / switchover ; lorsque Orchestrator ou MySQL Shell refuse de promouvoir une réplique à cause d'errant GTIDs, ou qu'une réplique échoue avec 1236 en se rattachant à une nouvelle source.

Attention

Déterminez d'abord ce qu'a fait la transaction errant à partir du binlog de la réplique (mysqlbinlog --include-gtids=...). Si elle a modifié des données, la transaction vide ne fait que masquer le GTID et l'écart de données subsiste ; reconstruisez la réplique (CLONE) ou alignez les données à la main. Les transactions vides validées sur la source se propagent à toutes les répliques ; c'est voulu. Gardez super_read_only=ON sur les répliques pour éviter que cela se reproduise.