On Fri, May 3, 2013 at 3:26 AM, Kristian Nielsen <knielsen@knielsen-hq.org> 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