MDEV-20122 Deprecate MASTER_USE_GTID=Current_Pos to favor new MASTER_DEMOTE_TO_SLAVE option
Deprecate the `Current_Pos` option of MASTER_USE_GTID to suggest
the safe alternative option MASTER_DEMOTE_TO_SLAVE=TRUE. See
the previous commit for the implementation and specifics of this
new option.
Reviewed By:
=============
Andrei Elkin <email address hidden>
MDEV-20122: Deprecate MASTER_USE_GTID=Current_Pos to favor new MASTER_DEMOTE_TO_SLAVE option
New Feature:
========
This feature adds a safe replacement to the
MASTER_USE_GTID=Current_Pos (deprecated) option for CHANGE MASTER TO
as MASTER_DEMOTE_TO_SLAVE=<bool>. The use case of Current_Pos is to
transition a master to become a slave; however, can break
replication state due to actively updating gtid_current_pos with
gtid_binlog_pos and gtid_slave_pos.
MASTER_DEMOTE_TO_SLAVE changes this use case by forcing users to set
Using_Gtid=Slave_Pos and merging gtid_binlog_pos into gtid_slave_pos
once at CHANGE MASTER TO time. Note that if gtid_slave_pos is more
recent than gtid_binlog_pos (as in the case of chain replication),
the replication state should be preserved.
Reviewed By
===========
Andrei Elkin <email address hidden>
MDEV-19801: Change defaults for CHANGE MASTER TO so that GTID-based replication is used by default if master supports it
This commit makes replicas crash-safe by default by changing the
Using_Gtid value to be Slave_Pos on a fresh slave start and after
RESET SLAVE is issued. If the primary server does not support GTIDs
(i.e., version < 10), the replica will fall back to Using_Gtid=No on
slave start and after RESET SLAVE.
Additional informational messages are added to notify users when
Using_Gtid is automatically changed. That is, if a RESET SLAVE
reverts Using_Gtid back to Slave_Pos, a message is given; and if a
replica falls back to Using_Gtid=No because the primary doesn’t
support GTIDs, an informational note is logged.
This commit only contains the code and infrastructure-related test
changes. Later commits contain the MTR changes which account for
this change.
Reviewed By:
============
Andrei Elkin <email address hidden>
it starts an EXPLAIN of a multi-table join and tries to KILL it.
no sync points.
depending on how fast the hareware is and optimizer development
it might kill EXPLAIN at some random point in time (generally unrelated
to the Bug#28598 it was supposed to test) or EXPLAIN might finish
before the KILL and the test will fail.
