Some of our hosts have a very old GTID domains on their server's binary log.
This can be a problem, not only when reading them as they can be very messy:
```
@@gtid_slave_pos: 0-171970637-5484646134,171966471-171966471-62,171970572-171970572-2942236266,171970577-171970577-101890,171970637-171970637-2116621969,171970661-171970661-3655324752,171970704-171970704-351094624,171970745-171970745-2419896119,171974720-171974720-2572451842,171974884-171974884-1473084269,171978765-171978765-199,171978768-171978768-202416,171978774-171978774-5,171978777-171978777-514400352,180355171-180355171-148310907,180359172-180359172-49702203,180359179-180359179-96523837,180363268-180363268-1082287825
1 row in set (0.001 sec)
```
This can lead to errors when trying to use GTID to switch masters, which is something we eventually want do with Orchestrator (T322993)
In order to clean these up, we need to first identify those gtid_domain_id that do not belong to any of the hosts in the section (master/candidate mostly) and then execute:
```
FLUSH BINARY LOGS DELETE_DOMAIN_ID=(XXX);
```
This needs to be done very carefully, as we can run into replication issues. We should probably start with things where replication isn't an issue until we've built trust that we are doing the right thing (mX, x2)
Progress
[] s1
[] s2
[] s3
[] s4
[] s5
[] s6
[] s7
[] s8
[] m1
[] m2
[x] m3
[] m5
[] es4
[] es5
[x] pc1
[x] pc2
[x] pc3
[] x1
[x] x2
[] db_inventory