maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

Thank you. I need this info to make sure that our tools work properly.
They need to determine which slave is further in the replication
stream than others (which apparently can be achieved by simple
comparison of sequence number) and detect if slaves have alternate
futures. The latter can happen not only with novice DBAs and bad
setups, but e.g. when experienced DBA has SUPER privilege, makes some
changes on the master and at the same time failover happens...

BTW, I have related questions.
What will happen with MariaDB if sem-sync master is enabled, some
transactions is completed, but before it gets any semi-sync acks all
slaves get disconnected? Will this transaction be rolled back? Or it
will be left committed basically creating an alternate future?

When all flushing to disk is turned off (and maybe with some other
conditions I don't know) is it possible to get in situation when
binlogs and InnoDB state will get out of sync? And I don't mean after
a power outage (without flushing it obviously can lead to any kind of
bad results), but after mysqld crash. And was the answer to this
question different for earlier MariaDB/MySQL versions?

On Wed, May 1, 2013 at 12:27 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Pavel Ivanov <pivanof@xxxxxxxxxx> writes:
>
>> As I understand GTID is constructed as <domain id>-<server
>> id>-<sequence number>. Is it guaranteed that sequence numbers are
>> always increasing inside the domain id? So
>
> The intention is that the user/DBA should configure things so that there is
> only ever one active master for each domain_id. If this is done correctly
> (eg. all slaves are made read-only, no fiddling with manual queries on
> slaves), then sequence numbers will be unique globally per domain_id, and
> server_id is actually unnecessary.
>
> Because if some server is first a slave, and then is promoted to master, then
> it will continue the sequence numbering from the point of the last replicated
> GTID.
>
> However, it is easy for novice users/DBAs to get this incorrect. Maybe they
> just fiddle a little on a slave with some manual queries or something. One can
> usually get away with this with old-style replication, so I tried to make it
> work also for GTID, even though the recommended operation is
> one-master-per-domain. If a user transaction is done on a slave in parallel
> with an active master, then there is no way to avoid duplicate sequence
> number. The server_id then ensures that we can still distinguish the GTIDs
> from the different events.
>
> Basically, the code tries to make sequence numbers unique per domain, but also
> tries to avoid relying on this uniques for correct operation.
>
> (I have thought of making a strict mode for GTID, which will make the slave
> give an error if it detects non-unique sequence number. This would allow
> experienced DBA to enforce one-master-per-domain and catch misconfigurations
> (by setting strict mode), and also allow novice users to not concern
> themselves with this (by not setting strict mode).
>
>> let's say two servers have GTID 0-1-100 and if they have alternate
>> futures then one server will have GTIDs 0-1-101, 0-1-102 and so on,
>> while second server will have 0-2-101, 0-2-102 etc. Is that correct?
>
> Yes (if I understand you correctly). Each server will continue the sequence
> numbering from whichever GTID was last seen.
>
>> BTW, where in the code is sequence number increased exactly?
>
> In MYSQL_BIN_LOG::write_gtid_event().
>
>  - Kristian.