Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

andrei.el...@pp.inet.fi writes: > where master maintains an "immediate" (without binlog proxy) > constant connection to slaves (when it breaks the slave would have to > take snapshot, or find a binlog service e.g on some other slave). > [In such a case the master connection would still collect

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

>> I would also raise another but relevant topic of maintaining >> >>gtid_"executed"_pos >> >> which is an union of all GTID executed regardless of their arrival >> method. E.g some of foreign (to the recipient server) domains gtid:s may > >> The master potentially could be (made) interested

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

Andrei Elkin writes: > I would also raise another but relevant topic of maintaining > >gtid_"executed"_pos > > which is an union of all GTID executed regardless of their arrival > method. E.g some of foreign (to the recipient server) domains gtid:s may > The master potentially could be

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

Hi Andrei! The @@gtid_current_pos exists for one sole purpose. This is to let the user promote a slave as the new master and attach the old master as a slave to the new master. By using master_use_gtid=current_pos, the exact same command can be used to attach a slave to the new master,

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

I am sure you can find some who would want something that ignores replicated GTIDs that duplicate GTIDs originating locally. I can only say that my experience is that this can cause unexpected problems, and requires a lot of thought to get a well-defined semantics that users can understand and

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

Kristian, howdy. Thanks for a simple CHANGE MASTER ... IGNORE_SERVER_IDS that you remind us about! (This time evaded myself alone :-)) It perfectly covers a cluster circular case. What motivated me to consider this option for looking for duplicates also in gtid_binlog_pos was the following

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

Sachin Setiya writes: > I have some question related to rpl_slave_state. Suppose A circular > async replication between A < -- > B (gtid_ignore_duplicates on) Why do you set gtid_ignore_duplicates? This option is for multi-source replication:

Re: [Maria-developers] Interaction between rpl_slave_state and rpl_binlog_state

Hi All, On Tue, Nov 28, 2017 at 3:03 PM, Sachin Setiya wrote: > Hi Kristian, Andrei > > I have some question related to rpl_slave_state. Suppose A circular > async replication between A < -- > B (gtid_ignore_duplicates on) > Now, we set some temp server_id on server A