Skip to main content
Tungsten Replicator

Deploying an Active-Active Topology

note

The Active/Active topology outlined in this section is only possible when both Source and Target database hosts are MySQL.

This configuration is not possible with Heterogeneous topologies.

When configuring an active/active topology, tpm automatically creates a number of individual services that are used to define a Primary/Replica topology between each group of hosts. In a three-node active/active setup, three different services are created, each service creates a Primary/Replica relationship between a Primary host and the Replicas. A change on any individual host will be replicated to the other databases in the topology creating the active/active configuration.

For example, with three hosts, host1, host2, and host3, three separate configurations are created:

  • host1 is the Source, and host2 and host3 are Targets of host1 (Service Alpha, yellow)
  • host2 is the Source, and host1 and host3 are Targets of host2 (Service Beta, green)
  • host3 is the Source, and host1 and host2 are Targets of host3 (Service Gamma, red)

These three individual services, one Extractor per host and a two-Applier scenario, effectively creates an Active/Active topology, since a change on any single Source will be replicated to the Targets.

Preparing Hosts for Active/Active​

Some considerations must be taken into account for any Active/Active scenario:

  • For tables that use auto-increment, collisions are possible if two hosts select the same auto-increment number. You can reduce the effects by configuring each MySQL host with a different auto-increment settings, changing the offset and the increment values. For example, adding the following lines to your my.cnf file:

    auto-increment-offset = 1
    auto-increment-increment = 4

    In this way, the increments can be staggered on each machine and collisions are unlikely to occur.

  • Use row-based replication. Statement-based replication will work in many instances, but if you are using inline calculations within your statements, for example, extending strings, or calculating new values based on existing column data, statement-based replication may lead to significant data drift from the original values as the calculation is computed individually on each Extractor. Update your configuration file to explicitly use row-based replication by adding the following to your my.cnf file:

    binlog-format = row

  • Beware of triggers. Triggers can cause problems during replication because if they are applied on the Targets as well as the Source you can get data corruption and invalid data. Tungsten Replicator cannot prevent triggers from executing on a Target, and in an Active/Active topology there is no sensible way to disable triggers. Instead, check at the trigger level whether you are executing on a Source or Target. For more information, see "Triggers".

  • Ensure that the server-id for each MySQL configuration has been modified and is different on each host. This will help to prevent the application of data originating on a server being re-applied if the transaction is replicated again from another Source after the initial replication. Tungsten Replicator is designed not to replicate these statements, and uses the server ID as part of the identification process.

Installing Active/Active Deployments​

To create the configuration use tpm to create the entire configuration with just one command. Before starting the installation, the prerequisites must have been completed (see "Installation Prerequisites"). This takes the list of hosts, and a list of Extractor services that will be configured, and then creates each service automatically:

  1. Download the release package.

  2. Unpack the release package:

    shell> tar zxf tungsten-replicator-8.0.4-132.tar.gz

  3. Change to the unpackaged directory:

    shell> cd tungsten-replicator-8.0.4-132

  4. Create the /etc/tungsten/tungsten.ini on each host using the following template as an example:

    Example tungsten.ini
    [epsilon]
    user=tungsten
    install-directory=/opt/continuent
    profile-script=~/.bash_profile
    topology=all-masters
    replication-user=tungsten
    replication-password=password
    master=host1,host2,host3
    members=host1,host2,host3
    master-services=alpha,beta,gamma
    rest-api-admin-user=apiuser
    rest-api-admin-password=secret
    replicator-rest-api-address=0.0.0.0
    Show argument definitions
    user=tungstenOS System User, for example tungsten. DO NOT use root.
    profile-script=~/.bash_profileAppend commands to include env.sh in this profile script.
    topology=all-mastersReplication topology for the dataservice.
    replication-user=tungstenUser for database connection.
    master=host1,host2,host3Hostname of the primary (or relay) host within this service.
    members=host1,host2,host3Hostnames for the dataservice members.
    master-services=alpha,beta,gammaData service names that should be used on each primary.
    rest-api-admin-user=apiuserSpecify the initial Admin Username for API access.Available from v7.0.0
    rest-api-admin-password=secretSpecify the initial Admin User Password for API access. rest-api-admin-password alias only available from version 7.1.2 onwards.Available from v7.0.0
    replicator-rest-api-address=0.0.0.0Address for the API to bind too.Available from v7.0.0

  5. Once the prerequisites and configuring of the installation has been completed, the software can be installed:

    shell> ./tools/tpm install

If the installation process fails, check the output of the /tmp/tungsten-configure.log file for more information about the root cause.

Once tpm has completed, the service will be started and the replication will be enabled between hosts.

Management and Monitoring of Active/Active Deployments​

To check the configured services use the trepctl services command:

shell> trepctl services
Processing services command...
NAME              VALUE
----              -----
appliedLastSeqno: 44
appliedLatency  : 0.692
role            : master
serviceName     : alpha
serviceType     : local
started         : true
state           : ONLINE
NAME              VALUE
----              -----
appliedLastSeqno: 40
appliedLatency  : 0.57
role            : slave
serviceName     : beta
serviceType     : remote
started         : true
state           : ONLINE
NAME              VALUE
----              -----
appliedLastSeqno: 41
appliedLatency  : 0.06
role            : slave
serviceName     : gamma
serviceType     : remote
started         : true
state           : ONLINE
Finished services command...

The output shows the three individual services created in the active/active configuration, alpha, beta, and gamma, and information about the current latency, status and role of the current host. This gives you an overview of the service state for this host.

To get detailed information about dataservices, each individual dataservice must be checked individually, and explicitly stated on the command-line to trepctl as there are now multiple dataservices configured. To check the dataservice status the current host will be displayed, in the example below, host1:

shell> trepctl -service alpha status
Processing status command...
NAME                     VALUE
----                     -----
appliedLastEventId     : mysql-bin.000011:0000000000006905;0
appliedLastSeqno       : 44
appliedLatency         : 0.692
channels               : 1
clusterName            : alpha
currentEventId         : mysql-bin.000011:0000000000006905
currentTimeMillis      : 1373891837668
dataServerHost         : host1
extensions             : 
latestEpochNumber      : 28
masterConnectUri       : thl://localhost:/
masterListenUri        : thl://host1:2112/
maximumStoredSeqNo     : 44
minimumStoredSeqNo     : 0
offlineRequests        : NONE
pendingError           : NONE
pendingErrorCode       : NONE
pendingErrorEventId    : NONE
pendingErrorSeqno      : -1
pendingExceptionMessage: NONE
pipelineSource         : jdbc:mysql:thin://host1:13306/
relativeLatency        : 254295.667
resourcePrecedence     : 99
rmiPort                : 10000
role                   : master
seqnoType              : java.lang.Long
serviceName            : alpha
serviceType            : local
simpleServiceName      : alpha
siteName               : default
sourceId               : host1
state                  : ONLINE
timeInStateSeconds     : 254530.987
transitioningTo        : 
uptimeSeconds          : 254532.724
version                : Tungsten Replicator 8.0.4 Build 132
Finished status command...

In the above example, the alpha dataservice is explicitly requested (a failure to specify a service will return an error, as multiple services are configured).

To get information about a specific host, use the -host option. This can be used with the trepctl services command:

shell> trepctl -host host3 services 
Processing services command...
NAME              VALUE
----              -----
appliedLastSeqno: 44
appliedLatency  : 1.171
role            : slave
serviceName     : alpha
serviceType     : remote
started         : true
state           : ONLINE
NAME              VALUE
----              -----
appliedLastSeqno: 40
appliedLatency  : 1.658
role            : slave
serviceName     : beta
serviceType     : remote
started         : true
state           : ONLINE
NAME              VALUE
----              -----
appliedLastSeqno: 41
appliedLatency  : 0.398
role            : master
serviceName     : gamma
serviceType     : local
started         : true
state           : ONLINE
Finished services command...

In the above output, you can see that this host is the Extractor for the dataservice gamma, but an Applier for the other two services.

The following sequence number combinations should match between the different hosts on each service:

Extractor ServiceTarget HostTarget Host
alphahost1host2,host3
betahost2host1,host3
gammahost3host1,host2

The sequence numbers on corresponding services should match across all hosts.

The basis for the Active/Active deployment can also be used in multiple site clustered configurations using Tungsten Clustering. This would be a preferred solution for this type of deployment since Tungsten Clustering offers a more complete solution providing many benefits over and above a standalone Tungsten Replicator installation. For more information on Composite Active/Active deployments, see "Deploying a Composite Active/Active (CAA) Cluster".