Replicate from GTID disabled source to GTID enabled replica directly

MySQL 8.0.23 introduces a new feature that makes replication possible from a source server that has been configured without Global Transaction Identifiers (GTIDs) to a replica server configured with GTIDs. This can be achieved by configuring replication channels to use the parameter ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS with the CHANGE REPLICATION SOURCE command. Enabling this option will allow the replica to assign a new GTID to every non-GTID(anonymous) transaction received from the source.
Some of the possible use cases of the feature:

  • To test the use of GTIDs on your database setup, just add a new replica having GTID_MODE=ON, and enable the feature on that replica. The new replica will process all your workload and assign GTIDs to the transactions, so you can see that everything works as it should without interfering with the production servers.
  • The feature can also be used when you cannot enable GTIDs on the source, for instance, it is managed by someone else, and you want to migrate to a modern topology that uses GTIDs.

Enabling GTIDs is necessary for tasks such as Group Replication, automatic fail-over, and in general an easier management of database replication, since GTIDs provide a mean to observe and compare the execution state among servers of a topology and determine if a transaction with a given GTID was already processed in some server of a topology.
Let us understand how to use this feature and what are the acceptable inputs for it.

One can assign the values

  • OFF: This is also the default. It simply means we are not enabling the feature on that channel.
  • LOCAL: In this case the UUID used in the GTID will be the same as the ‘server_uuid’ global variable for the server where the channel is being setup.
  • <UUID>: You can specify a valid UUID which will be used while generating GTID transactions on this channel.

Usage

CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS=OFF|LOCAL|<UUID>;

Here are some examples of query execution and replication were you can inspect both the source server binlog file and also the replica relay logs and see the outcome of the option being used.

Below you can see the execution of some commands in the source and also the resulting binlog file.

Lets now look at the relay log files in the replica.

The CREATE command on source will be replicated with ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS=OFF.
The INSERT command on source will be replicated with ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS=LOCAL.

You can see that the GTID associated with the INSERT have the same UUID as the global variable ‘server_uuid’.
This is because we used ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = LOCAL to replicate the INSERT statement.

Now if we set ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = <UUID>

You can see the UUID changed in the later transaction and it is the same as what was passed to ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS in CHANGE REPLICATION SOURCE.

Specifying the UUID manually can be useful to identify the source of each transactions, in case the server replicates from multiple source servers, or if there are clients that commits transactions on the same replica.

If the replication breaks in between running transactions, you will have to manually re-position the replica and do the troubleshooting, a limitation shared with position based replication topologies.

Conclusion:

Whenever possible, we recommend migrating all servers to use GTIDs. The new feature’s intention is to ease the migration in two cases. First, you can preview how it is for your workload to have GTIDs, on a replica that is not in production. Second, in the case that you do not have enough control to enable GTIDs on the source server, you can enable GTIDs on a downstream part of the topology where you do have control. In this case it is important to understand that the benefits of GTIDs only apply within the part of the topology where you have enabled GTIDs.
With this feature, we hope to make the migration to enable GTIDs even easier, so that more people unlock group replication, fail-over, and other features that ease the replication administration.

 10,016 total views,  90 views today