maria-developers team mailing list archive

[Jean-François Gagné <jeanfrancois.gagne@xxxxxxxxxxx>]

On 2015-04-02 15:05, Kristian Nielsen wrote:
> Massimiliano Pinto <massimiliano.pinto@xxxxxxxxxxx> writes:
>
> > We [...] got another [...] statement not handled:
> >
> > (2) SELECT binlog_gtid_pos('mst-bin.000001',310)
> This is used by the slave to obtain the correct GTID position corresponding to
> the position at which it is starting, when it is connecting in non-GTID mode.
>
> When the slave has this information, it becomes easy for the DBA to switch to
> a new master using GTID:
>
>    STOP SLAVE;
>    CHANGE MASTER TO master_host='new_master', master_use_gtid=slave_pos;
>    START MASTER;
>
> This works even if the slave was not using GTID mode prior to the CHANGE
> MASTER, thanks to that SELECT binlog_gtid_pos().

Is this really needed ?

My understanding is that the SQL_THREAD will remember the GTID of the 
last executed transaction, which make the GTID provided by "SELECT 
binlog_gtid_pos('mst-bin.000001',310)" quickly obsolete. This SELECT is 
useful when the IO_THREAD is started without starting the SQL_THREAD, in 
which case the SELECT allows us to repoint the slave with GTID to 
another master.  But I do not see why someone would not want to start 
the SQL_THREAD in this situation.

Moreover, I guess that the GTID returned by this function should not be 
the GTID of the transaction at this position, but the GTID of the 
previous transaction.  This needs to read from the beginning of the 
binary logs (reading a binary log backward is not possible to my 
knowledge).  If the binlog file size is 100 GB... (you can see my point 
I think).  Also, if the previous position is not in the same write 
domain as the current transaction, the transaction from the right write 
domain (and all the other transaction from the other write domains) must 
be found.  This looks terribly inefficient.

There might be a subtility with multiple DomainIDs that I am missing: 
that SELECT might return the GTIDs of all write domains up to that 
position...  Again, this needs to read all the binlog up to that 
position (with the hypothesis that the last TransactionID for each write 
domain is in the header of the binlog).  I would prefer to forbid the 
slave to use automatic positioning (with GTID) until it had read the 
header of the next binlog.  Basically, I prefer to push constraints to 
slaves than to have more expensive operations on the master.

I am probably missing something, can someone explain to me why this 
SELECT is needed ?

The need for that "SELECT binlog_gtid_pos(...)" makes it very hard to 
implement the MariaDB Slave Protocol in the Binlog Server is a "simple" 
way.  If it is not needed in the protocol, I would prefer to simplify 
the slave protocol than to complexify the Binlog Server.

Thanks in advance for precisions,

Jean-François Gagné