maria-developers team mailing list archive
Mailing list archive
Re: MariaDB 10 and MaxScale binlog router
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:
CHANGE MASTER TO master_host='new_master', master_use_gtid=slave_pos;
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,