Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11.10
-
None
-
None
Description
This issue occurred in the migration of a Galera Cluster from 10.4 to 10.11.10. To migrate, I created a new cluster running 10.11.10.
Each cluster had 3 nodes. The replication ran from node B to node B, from the old cluster to the new cluster. Each node has binary logging enabled and log_slave_updates enabled.
On the new cluster, on nodes A and C (where no asynchronous replication was running!) the mysql.gtid_slave_pos table has many rows and is 3.9GB large.
This not blocks me from setting up an asynchronous replica from nodes A and C. I expect this to block SST as well when nodes A or C are the donor. Is there a safe way to fix this?
Thank you,
Attachments
Issue Links
- duplicates
-
MDEV-34924 gtid_slave_pos table neven been deleted on non replica nodes (wsrep_gtid_mode = 1)
- Confirmed
- is caused by
-
MDEV-31413 Node has been dropped from the cluster on Startup / Shutdown with async replica
- Closed
- relates to
-
MDEV-33977 MariaDB hangs on --wsrep-recover phase
- Confirmed