Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
RESET MASTER resets gtid_binlog_pos, but not gtid_slave_pos. This means that gtid_current_pos can still contain GTIDs after RESET MASTER. This can result in some confusing behavior. See MDEV-17156 and MDEV-17853.
To try to make this more clear, what if RESET MASTER threw a warning if gtid_slave_pos was set? Maybe something like:
RESET MASTER successfully reset gtid_binlog_pos, but gtid_slave_pos is non-empty. If you want to reset system's GTID state, then you must also manually reset gtid_slave_pos with "SET GLOBAL gtid_slave_pos = ''"
|
Attachments
Issue Links
- relates to
-
MDEV-17156 Local transactions on a Slave don't update GTID's gtid_current_pos after RESET MASTER on Slave (master_use_gtid value is not relevant)
- Closed
-
MDEV-17368 RESET MASTER doesn't completely reset gtid_current_pos
- Closed
-
MDEV-17369 Document how to reset gtid_current_pos
- Closed
-
MDEV-17853 Document that gtid_binlog_pos can lag behind gtid_current_pos after RESET MASTER
- Closed