MySQL GTID Set Calculator
With GTID-based replication, every transaction has an ID like 3e11fa47-71ca-11e1-9e33-c80aa9429562:42, and each server tracks the set of IDs it has applied in gtid_executed. Most GTID problems come down to set arithmetic on these values. Which transactions has the replica not applied yet? Which ones exist only on the replica (errant transactions that break failover)? Which needed transactions were already purged from the source's binary logs, so replication stops with error 1236? Paste the source's and the replica's gtid_executed, and optionally the source's gtid_purged. The calculator parses them with the same rules as MySQL: whitespace and line breaks, overlapping and adjacent ranges, empty ranges such as 5-3, numbers with a leading 0 read as octal (012 is 10), the 9223372036854775806 upper limit, and tagged GTIDs (uuid:tag:1-5) from MySQL 8.3 on. It prints the normalized sets, GTID_SUBTRACT in both directions, the intersection, the union and GTID_SUBSET, plus a diagnosis. For errant transactions it lists the SET GTID_NEXT statements that commit empty transactions on the source. For error 1236 it shows the purged range the replica lacks and the gtid_purged statement. Results were checked against GTID_SUBTRACT and GTID_SUBSET on MySQL 8.0.46 and 8.4.11 with thousands of generated sets. Everything runs in your browser.
Do more than mysql gtid set calculator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Run SELECT @@GLOBAL.gtid_executed on the source and on the replica, and optionally SELECT @@GLOBAL.gtid_purged on the source, and paste the values.
- Choose whether your servers accept tagged GTIDs (MySQL 8.3 or later), then click Compare.
- Read the missing, errant and purged sets and the diagnosis, then copy the generated SQL to fix errant GTIDs or error 1236.
Frequently asked questions
How do I find errant transactions on a MySQL replica?
Run SELECT GTID_SUBTRACT(<replica gtid_executed>, <source gtid_executed>). Any GTIDs left over were executed on the replica and never on the source, usually because someone wrote to the replica without super_read_only, or ran a DDL or user change there. They break failover: if this replica is promoted, the other replicas request those GTIDs, and if they are already purged from its binary logs they stop with error 1236. The usual fix is to commit an empty transaction with each errant GTID on the source (SET GTID_NEXT = 'uuid:n'; BEGIN; COMMIT;), after checking that the changes themselves are harmless.
What causes 'Cannot replicate because the source purged required binary logs' (error 1236)?
The replica asked for transactions that are in the source's gtid_purged but not in the replica's gtid_executed, so the binary log files containing them are gone. Typical causes are a replica that was stopped longer than binlog_expire_logs_seconds, a backup restored without the right gtid_purged, or a manual PURGE BINARY LOGS. GTID_SUBTRACT(source gtid_purged, replica gtid_executed) shows exactly what is missing. The safe fix is to rebuild the replica from a fresh copy of the source. SET GLOBAL gtid_purged = '+...' only hides the gap, so use it only when you know the replica already has that data.
Why does my GTID set look different after MySQL prints it?
MySQL normalizes GTID sets. UUIDs are lowercased and sorted, ranges are sorted and merged when they overlap or touch (1-5:6-9 becomes 1-9), and empty ranges such as 5-3 are dropped. Untagged ranges come before tagged ones, and tags are lowercased and sorted. Several entries for the same UUID are combined, and the output separates UUIDs with a comma and a line break. This calculator prints the same form, so you can compare values directly. In Chat2DB you can run these GTID queries on several servers side by side and keep them as saved snippets: download it at chat2db.ai/download or open app.chat2db.ai.
