On 2015-04-02 15:05, Kristian Nielsen wrote:
Massimiliano Pinto <massimiliano.pinto@mariadb.com> 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é