0

I'm learning about MariaDB GTID replication and one thing I am completely stuck on is why GTIDs have both a domain ID and a server ID, which make up the (domain_id)-(server_id)-(sequence_number) in the GTID, such as 0-1-12345.

The docs are very thorough, but don't address this question directly.

I've learned as a result of this wonderful video that the sequence number increments for each transaction, but is tied to the domain_id. This doesn't seem to be stated anywhere in the GTID docs.

So, if you have two servers with server_id 1 and 2, but the same domain_id (say, 1), the GTIDs would indeed be delineated due to the unique server_id, but they would share the same sequence number.

e.g. Alternating transactions on server 1 followed by server 2 would result in the following:

1-1-1
1-2-2
1-1-3
1-2-4

They're still unique, so I have to figure they work just fine for replication. I'd love to be corrected if that is wrong though.

Anyway, if you set the domain IDs to 1 and 2, this would be the result:

1-1-1
2-2-1
1-1-2
2-2-2

But it is still not clear to me why or how you'd want to have a unique sequence per server.

If two master servers had the same server ID and domain ID, then there would be a conflict. But the question is why would you ever want to have two servers with the same server ID, such that you need to have a unique domain id per server?

Or perhaps there is there a tool and use-case for extracting a specific domain stream out of the shared binlog, which perhaps can't be done just by specifying the server_id?

0

1 Answer 1

1

Server IDs in MariaDB replication should always be unique. They're the thing that identifies which node the transaction was executed on. The domain ID is not a replacement of the server ID.

The Use With Multi-Source Replication and Other Multi-Primary Setups section of the MariaDB knowledgebase explains when you'd want to use a different domain ID.

MariaDB global transaction ID supports having multiple primarys active at the same time. Typically this happens with either multi-source replication or multi-primary ring setups.

In such setups, each active primary must be configured with its own distinct replication domain ID, gtid_domain_id. The binlog will then in effect consists of multiple independent streams, one per active primary. Within one replication domain, binlog order is always the same on every server. But two different streams can be interleaved differently in different server binlogs.

An example of multi-source replication would be aggregating two separate databases that run different applications in their own GTID domains into one reporting replica database that analyzes them both.

A multi-primary ring is a replication topology where the replication forms a cyclical ring. Applications write to some predetermined node to avoid conflicts and changes from other nodes get replicated to all other nodes.

That page also explains that the reason why you need separate domains is to be able to reconnect to a primary in a multi-primary setup.

The GTID position of a given replica is then not a single GTID. Rather, it becomes the GTID of the last event group applied for each value of domain ID, in effect the position reached in each binlog stream. When the replica connects to a primary, it can continue from one stream in a different binlog position than another stream. Since order within one stream is consistent across all servers, this is sufficient to always be able to continue replication at the correct point in any new primary server(s).

However, for most users that just want to replicate from the primary to replicas, there's no need to change the GTID domain and the default gtid_domain_id=0 will work just fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.