maria-developers team mailing list archive

[Giuseppe Maxia <g.maxia@xxxxxxxxx>]

Kristian,
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:

mysql -e 'show all slaves status\G' |grep 'Connection_name\|Running\|Master_Host\|Master_Port\|Gtid_Pos\|Master_Log'
              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.

Cheers

Giuseppe