Supported MySQL Topologies

Rivery Log-Based Extraction for MySQL supports the following MySQL topologies:

Standalone

When a single MySQL server is used, the server must have the binlog enabled (and optionally GTIDs enabled).
In this case, the MySQL connector always connects to and follows this standalone MySQL server instance.

Master and slave

Rivery can follow one of the masters or one of the slaves only (if the slave has its binlog enabled), but the connector only sees changes in the cluster that are visible to that server. Generally, this is not a problem except for the multi-master topologies.

Highly-available clusters

A variety of high availability solutions exist for MySQL, and they make it far easier to tolerate and almost immediately recover from problems and failures. Most highly-available MySQL clusters use GTIDs so that slaves are able to keep track of all changes on any of the masters.

Note:

For MySQL clusters to run in Rivery, GTID must be enabled.

Enable MySQL GTIDs

To activate MySQL GTIDs (Global Transaction Identifiers), which uniquely recognize transactions within a server cluster, use the following commands in the MySQL console:Global Transaction Identifiers (GTIDs) uniquely identify transactions that occur on a server within a cluster. The identifier allows you to easily confirm if master and slave servers are consistent.
In order to enable the GTIDs in MySQL, run the following command in the MySQL console:

SET gtid_mode=ON;
SET enforce_gtid_consistency=ON;
SHOW global variables like '%GTID%';

To verify the GTID value, execute the following command on the MySQL Server:

SHOW MASTER STATUS;

Here's an example of the expected output:

Please Note:

To enable MySQL GTIDs for Amazon Aurora MySQL, refer to the Amazon documentation for instructions on enabling this feature in your Amazon Aurora MySQL database.