andrei.elkin@pp.inet.fi writes:

where master maintains an "immediate" (without binlog proxy) constant connection to slaves (when it breaks the slave would have to take snapshot, or find a binlog service e.g on some other slave). [In such a case the master connection would still collect transaction statement till prepare or commit to send them to slaves at those points.] So here replicated transactions need identification on the binlog-less master to display its execution status (which would matter when configuration changes and a new master is reelected).

Aha, so delegate the binlogging task to a slave. I guess there needs to be a binlog *somewhere* for GTID to make sense. I wonder if it would be possible to avoid introducing a new table (for example updating the mysql.gtid_slave_pos table on the master). Having two different places (binlog and mysql.gtid_slave_pos) is already a source of considerable complexity in the MariaDB GTID, something I would have liked to avoid. But I felt that it is was really important to allow a slave to use GTID without --log-slave-updates (hence the need for the table), and also that adding a mandatory extra table operation to every transaction on the master was unacceptable (hence the binlog). Another fundamental design detail of MariaDB GTID is that it supports out-of-order sequence numbers in the binlog. Again, this is a source of considerable complexity. This was needed so that 10.0 could enable GTID by default on the master, so that a simple CHANGE MASTER is sufficient to start using GTID after an update. For example, an existing master-master ring that is upgraded to 10.0 will not have gtid_domain_id set and thus will generate out-of-order GTIDs in the binlog. The implementation is very carefully designed to always be able to find the correct binlog position from a GTID even in case of out-of-order sequence numbers. A consequence is that in MariaDB, it is not in general possible to compare GTIDs without reference to the binlog. This can also easily affect things like extending gtid_current_pos or this idea of binlogless master. I wonder how well understood this generally is by users and developers - and if not, it is a good sign that it is too complicated... My point is - maybe it would be an idea to introduce a fully-strict GTID mode now. In fully-strict mode, GTIDs are guaranteed to be in-order (within each domain) in every binlog in the system. Ie. there would be a marker at the start of every binlog file (GTID_LIST perhaps) that this server is fully-strict and any attempt to disable fully-strict (without CHANGE MASTER) or connect a fully-strict slave would give an error. Then in fully-strict mode sequence numbers are strictly monotonic (within a domain), and GTIDs can be compared simply on sequence numbers. And then a lot of more advanced GTID features can be implemented in a simpler and more intuitive (for the user) way. For example, having GTIDs stored in multiple places is less of a problem, since unification is trivial by just taking the max sequencenumber within each domain. - Kristian.