Hi Kristian ! On Sat, Jul 21, 2018, 15:14 Kristian Nielsen <kniel...@knielsen-hq.org> wrote:
> Sachin Setiya <sachin.set...@mariadb.com> 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! >
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp