maria-developers team mailing list archive
Mailing list archive
Re: MariaDB 10 and MaxScale binlog router
thx for reminding me kristian about the gtid index patch!
On Fri, Apr 3, 2015 at 12:50 PM, Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
> Jean-François Gagné <jeanfrancois.gagne@xxxxxxxxxxx> writes:
> >>> (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
> >> 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 ?
> Well, it's needed in the general case to be able to get the correct GTID
> position to automatically switch to a different master using GTID, as
> It is not _really_ needed in the sense that the DBA can just manually
> SET GLOBAL gtid_slave_pos='<position>' instead. Or the DBA might not have
> need for using GTID in the first place.
> One of the primary goals of MariaDB GTID was to make it easy to start using
> it, that is why this was implemented.
> > 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
> > 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
> Correct. The GTID position in the general case has one GTID per replication
> domain id. And since some of those domains may have no replicated
> for a long time, the binlog_gtid_pos() call is used to fetch the full
> > 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
> Yes, you are right, there will be a need to scan the most recent binlog. So
> there is the potential for a performance regression, more so with large
> files and/or frequent slave connects.
> The intention was to have an index on the binlog files so that the GTID
> position can be found quickly (both for the gtid_slave_pos() call in the
> non-GTID case, and for GTID connect). But pressure to get the feature out
> meant it was released without, and I agree that this was unfortunate.
> Jonas Oreland said he has a patch already that implements this, and that
> be contributed soon...
> > 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.
> > 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
> That could be reasonable.
> The counter-argument is that we need binlog indexing anyway for GTID mode.
> with binlog indexes, the overhead for binlog_gtid_pos() will be
> negligible. So
> we could avoid the complications of introducing new kinds of states of a
> ("has a valid GTID position" vs. "does not have a valid GTID position").
> In any case, if this causes a performance regression in practice, we will
> some solution. Waiting to get the position from the header of the next
> as you suggested, or some option to disable the binlog_gtid_pos() call, or
> > 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.
> The binlog server can probably just ignore that call. It should not cause
> problems - only the automatic switch to GTID mode will not work, but I
> the binlog server does not support GTID anyway.
> - Kristian.
> Mailing list: https://launchpad.net/~maria-developers
> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help : https://help.launchpad.net/ListHelp