maria-developers team mailing list archive

[Sachin Setiya <sachin.setiya@xxxxxxxxxxx>]

Hi Kristian !

On Sat, Jul 21, 2018, 15:14 Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
wrote:

> Sachin Setiya <sachin.setiya@xxxxxxxxxxx> writes:
>
> >>> I think that sounds like a very bad idea. The current_pos/slave_pos is
> the
> >>> single biggest source of confusion regarding GTID. (In fact, I think it
> >>> would be best to deprecate/eventually remove current_pos). Better not
> add
> >>> to
> >>> the confusion...
> >>>
> >>> If we remove current pos then how will how will master turned slave
> will
> >> work ?
> >>
> > May be in this case user have to manually update gtid_slave_pos ?
>
> Yes, that is one option, eg. SET GLOBAL gtid_slave_pos = @@gtid_binlog_pos;
>
> Another option is to make an option to CHANGE MASTER that updates the
> gtid_slave_pos _at_the_time_of_that_command_only_, like a one-shot
> master_use_gtid=current_pos. Eg. something like:
>
>   CHANGE MASTER TO master_host=xxx ... gtid_slave_pos_from_master=1;
>
> The idea is that to make old master a slave, a CHANGE MASTER command will
> usually be needed anyway. And _that_ is the point at which user wants the
> binlog position to migrate to the slave position.
>
> But with the current master_use_gtid=current_pos, this migration happens at
> every future slave reconnect, which is very much not expected, and users
> are
> all the time confused that a random manual transation on their slave later
> makes GTID replication break.
>
>  - Kristian.
>
Sounds like a really good idea, I have created a mdev 16800 for it, thanks!

>