Overview
The Skinny
In this blog post we will discuss how the managed cross-site replication streams work in a Composite Multi-Master Tungsten Cluster for MySQL, MariaDB and Percona Server.
Agenda
What's Here?
- Briefly explore how managed cross-site replication works in a Tungsten Composite Multi-Master Cluster
- Describe the reasons why the default design was chosen
- Explain the pros and cons of changing the configuration
- Examine how to change the configuration of the managed cross-site replicators
Cross-Site Replication
A Very Brief Summary
In a standard Composite Multi-Master (CMM) deployment, the managed cross-site replicators pull Transaction History Logs (THL) from every remote cluster's current master node.
The CMM functionality was introduced in Tungsten Clustering software version 6.0.0
Cross-Site Replication: In-Depth
How Does It All Work?
Managed cross-site replicators run in addition to the base replication service for the local cluster. The additional replication services (one per remote site) run on all nodes, and have a relay and slaves. The relay runs on the current master node so as not to make things confusing.
In a Composite Multi-Master cluster, each local cluster must pull data from the other remote sites. There is an additional replication service for each remote site, called a sub-service.
Each sub-service is named to match the remote site.
For example, assume a composite cluster with four sites: east, west, north and south.
On the east cluster, there would be the following three additional replication streams:east_from_west
east_from_north
east_from_south
As you can see, each sub-service is named in a way that makes it easy to understand.
Reading sub-service names is also simple, and so for example "east_from_west" is stated as "I am in cluster east and pulling THL from cluster west".
Below is a diagram showing just two clusters within the "usa" composite service - east and west:
Cross-Site Replication Architecture
Pros and Cons
The default architecture is designed so that the relay node for each cluster service gets the most recent information directly from the remote master, reducing the risk of data latency (staleness).
As of Tungsten Clustering software version 6.0.4, the cross-site replicators within a CMM deployment can be configured to point to slave nodes, and to prefer slave nodes over master nodes during operation.
This configuration allows the slave nodes to handle the load generated by the remote cross-site relays upon the master nodes. This becomes a concern when there are many sites, all of which are pulling THL from the same remote master nodes.
Of course, when using this option, one must accept that the downstream data may be delayed by the additional hop, and that the data replicated to the remote sites could (and probably would) be older than it would be using the standard topology.
Tuning Cross-Site Replication
How To Configure the Replication Streams to Meet Your Needs
To configure the cluster to prefer slave nodes over master nodes, use the --policy-relay-from-slave=true option to tpm.
Both master and slave nodes remain in the list of possible hosts, so if no slave nodes are available during a switch or failover event, then a master will be used.
Summary
The Wrap-Up
In this blog post we discussed Tungsten Composite Multi-Master Cluster cross-site replication configuration.
To learn about Continuent solutions in general, check out https://www.continuent.com/solutions
The Library
Please read the docs!
For more information about monitoring Tungsten clusters, please visit https://docs.continuent.com.
Tungsten Clustering is the most flexible, performant global database layer available today - use it underlying your SaaS offering as a strong base upon which to grow your worldwide business!
For more information, please visit https://www.continuent.com/solutions
Want to learn more or run a POC? Contact us.
Comments
Add new comment