maria-developers team mailing list archive
Mailing list archive
Re: MariaDB 10 and MaxScale binlog router
i don't honestly remember, but we tend to make a disable switch for all
changes we do...
will check once i get around to it...(have to clear backlog after
conference visit now)
On Thu, Apr 16, 2015 at 8:10 PM, Jean-François Gagné <
> Hi Jonas,
> will it be possible to disable the creation/resource consumption of this
> index ?
> As I am planning to stick to file/position negotiation, I would like to
> avoid consuming resource consumption for features that I do not need.
> Many thanks,
> Jean-François Gagné
> On 2015-04-15 15:28, Jonas Oreland wrote:
> thx for reminding me kristian about the gtid index patch!
> On Fri, Apr 3, 2015 at 12:50 PM, Kristian Nielsen <
> knielsen@xxxxxxxxxxxxxxx> wrote:
>> 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 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',
>> >> START MASTER;
>> >> This works even if the slave was not using GTID mode prior to the
>> >> 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
>> 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
>> 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.
>> 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. And
>> 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