Thanks for the docs. It's a very good start. Compared to MySQL 5.6, GTID in MariaDB has some advantages: it is enabled by default and it is easy to read.

There are a few items, though, that should need some more thought:

1) rpl_slave_state is probably ill-named. In this architecture, it is only written by the slaves, and thus the name matches, but I wonder if the master should write this table (or a similar one) to keep track of its progress in the binary log. Rationale: all the info related to replication should be in tables and easy to query.

2) rpl_slave_state does not have enough metadata. What is missing here, and would be extremely useful, is the corresponding binlog+position for each GTID, a timestamp of when the transaction was saved to the binary log, and the timestamp of when it was applied. (The host name of the origin would also be useful). Also very important (when you will implement parallel replication) is a shard identifier.

3) Multiple domains do not integrate well with GTID. In multi-source replication, we use "connection names", but for GTID we use "domain numbers". They do not play well together : there is no correspondence between the gtid_domain_id and the connection name, and a "SHOW ALL SLAVES STATUS" lists all the GTID for every connection. For example:

Connection_name: Bear

Master_Host: 127.0.0.1

Master_Port: 8203

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 1020

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Exec_Master_Log_Pos: 1020

Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20

Connection_name: Wolf

Master_Host: 127.0.0.1

Master_Port: 8204

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 896

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Exec_Master_Log_Pos: 896

Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20

Connection_name: Fox

Master_Host: 127.0.0.1

Master_Port: 8205

Master_Log_File: mysql-bin.000002

Read_Master_Log_Pos: 365

Relay_Master_Log_File: mysql-bin.000002

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Exec_Master_Log_Pos: 365

Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20

Connection_name: Deer

Master_Host: 127.0.0.1

Master_Port: 8206

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 1144

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Exec_Master_Log_Pos: 1144

Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20

Which connection is running which gtid number? Not easy to tell, as the correspondence between domain and connections is only in the DBA's head.

4) gtid_pos is text that includes all sequences from all domains. The docs say that I can modify it if needed, but in a case like the one above, modifying this string can be very error prone. For example, if server_ids are assigned using inet_aton(@IP), you could have a gtid_pos like this

'1001-170062692-230000,1002-170062593-12893445,1003-170062700-672009,1003-170062699-700002'

Instead of editing a string, and risk breaking replication in all domains, I would expect the availability of commands like:

CHANGE GTID for domain 'Wolf' set gtid_pos=1900

That's it for now. Hope there is still room for improvements.