maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

On Fri, May 3, 2013 at 3:26 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> In the bug report, you wondered why there are multiple GTIDs for one domain_id
> in Gtid_list_log_event (there is one for each server id).
>
> This is needed to be able to locate any given GTID in the binlogs, without
> relying on sequence numbers being strictly increasing. There are a number of
> scenarios where this can happen. Even if most of these are undesirable
> configurations / user error, it is sure to occur in practice, and I spent a
> lot of effort in the design to make sure that GTID will still behave
> reasonably in such cases, and not silently corrupt replication.
>
> There is a careful distinction between the slave state (gtid position), which
> has only one GTID per domain id, and master binlog state
> (Gtid_list_log_event), which has one per (domain_id, server_id)
> combination. The latter can accumulate lots of cruft in the form of old, no
> longer used server_id's, but it does not matter, as it is not something users
> ever need to look at. The former _is_ something the user might want to look
> at, and it has the simple format of just one GTID per domain configured by the
> user.

Well, I'd argue that accumulating lots of cruft does matter. Let's say
it accumulated 10,000 different GTIDs. It will significantly slow down
the slave connection initialization and it will blow up binlog size.
The first effect could be especially dangerous because if e.g. 3
slaves are connected to master simultaneously master could fully
consume 3 CPUs for a prolonged period of time which may affect ability
to respond to client queries.

Overall I guess I don't quite like this design decision. It basically
means that in the proper configuration special care should be taken to
make sure that server_id numbers don't get retired forever but get
reused instead...

> (This was BTW a major motivation for redesigning GTID from scratch rather than
> taking the MySQL 5.6 version. In MySQL 5.6, they do not make this distiction,
> so the user-visible slave GTID position will accumulate cruft in the form of
> no longer used server UUIDs, which will hang around basically forever).

Yes, this is a very wise decision by MariaDB.


Pavel