Details
-
Technical task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
Q3/2025 Maintenance, Q4/2025 Server Maintenance
Description
- ( ) knielsen said that GTID replication does not purge the relay logs if only one of the IO and SQL threads is stopped.
Then why isn't it already capable?- ( ) He also said that it is because critical configs cannot change when not all threads are stopped.
What are they?- ( ) What configs unique to GTID are impactful here?
- ( ) (Non-key) CHANGE MASTER TO
- ( ) @@GLOBAL vars that apply to all connections
- ( ) Replication filters
- ( ) What configs unique to GTID are impactful here?
- ( ) How to extend this partial capability to full?
- ( ) He also said that it is because critical configs cannot change when not all threads are stopped.
- ( ) Given @@GLOBAL.gtid_io_pos is not @@GLOBAL.gtid_slave_pos, what would it be?
- ( ) Something in SSS? Gtid_IO_Pos?
- ( ) Something in the relay log info? Relay_log_info::group_master_log*??
- ( ) Must it scan the (entire!) relay log, especially for the crash recovery case?
- ( ) What are the contents of the GTID indexes, and could they help here?
- ( ) The primary can locate replica-requested GTIDs in the binary logs.
How can the replica leverage this procedure to find where it left off in the relay logs?
(This mostly concerns parallel replicas.) - ( ) Why is --gtid-strict-mode a concern? Isn't out-of-order GTID always an error?
- ( ) What checkpoints are the --gtid-strict-mode checks at?
- ( ) What pattern do the GTIDs of a malformed transaction have?
- ( ) How concerning is the mentioned MDEV-33268?