If you have an existing dataservice, data can be replicated from a standalone MySQL server into the service. The replication is configured by creating a service that reads from the standalone MySQL server and writes into the master of the target dataservice. By writing this way, changes are replicated to the master and slave in the new deployment.
Additionally, using a replicator that writes data into an existing data service can be used when migrating from an existing service into a new Tungsten Replicator service. For more information on initially provisioning the data for this type of operation, see Section 8.10.2, “Migrating from MySQL Native Replication Using a New Service”.
In order to configure this deployment, there are two steps:
Create a new replicator on an existing server that replicates into a the master of the destination dataservice
Create a new replicator that reads the binary logs directly from the external MySQL service through the master of the destination dataservice
There are also the following requirements:
The host on which you want to replicate to must have Tungsten Replicator 2.2.0 or later.
Hosts on both the replicator and cluster must be able to communicate with each other.
Replicator must be able to connect as the
tungsten user to the databases
within the cluster.
The tpm command to create the service on the replicator
should be executed on
host1, after the
Tungsten Replicator distribution has been extracted:
./tools/tpm configure defaults \ --install-directory=/opt/replicator \ --rmi-port=10002 \ --user=tungsten \ --replication-user=tungsten \ --replication-password=secret \ --skip-validation-check=MySQLNoMySQLReplicationCheck \ --log-slave-updates=true
This configures the default configuration values that will be used for the replication service.
Click the icon to show a detailed description of each argument.
The description of each of the options is shown below; click the icon to hide this detail:
Configures default options that will be configured for all future services.
The installation directory of the Tungsten service. This is where the service will be installed on each server in your dataservice.
Configure a different RMI port from the default selection to ensure that the two replicators do not interfere with each other.
The operating system user name that you have created for the Tungsten
The user name that will be used to apply replication changes to the database on slaves.
The password that will be used to apply replication changes to the database on slaves.
Now that the defaults are configured, first we configure a cluster alias that points to the masters and slaves within the current Tungsten Replicator service that you are replicating from:
./tools/tpm configure beta \ --topology=direct \ --master=host1 \ --direct-datasource-host=host3 \ --thl-port=2113
This creates a configuration that specifies that the topology should read
directly from the source host,
writing directly to
alternative THL port is provided to ensure that the THL listener is not
operating on the same network port as the original.
Now install the service, which will create the replicator reading direct
If the installation process fails, check the output of the
/tmp/tungsten-configure.log file for
more information about the root cause.
Once the installation has been completed, you must update the position of the replicator so that it points to the correct position within the source database to prevent errors during replication. If the replication is being created as part of a migration process, determine the position of the binary log from the external replicator service used when the backup was taken. For example:
show master status;*************************** 1. row *************************** File: mysql-bin.000026 Position: 1311 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.00 sec)
Use tungsten_set_position to update the replicator position to point to the master log position:
/opt/replicator/scripts/tungsten_set_position \ --seqno=0 --epoch=0 --service=beta \ --source-id=host3 --event-id=mysql-bin.000026:1311
Now start the replicator:
Replication status should be checked by explicitly using the servicename and/or RMI port:
/opt/replicator/tungsten/tungsten-replicator/bin/trepctl statusProcessing status command... NAME VALUE ---- ----- appliedLastEventId : mysql-bin.000026:0000000000001311;1252 appliedLastSeqno : 5 appliedLatency : 0.748 channels : 1 clusterName : beta currentEventId : mysql-bin.000026:0000000000001311 currentTimeMillis : 1390410611881 dataServerHost : host1 extensions : host : host3 latestEpochNumber : 1 masterConnectUri : thl://host3:2112/ masterListenUri : thl://host1:2113/ maximumStoredSeqNo : 5 minimumStoredSeqNo : 0 offlineRequests : NONE pendingError : NONE pendingErrorCode : NONE pendingErrorEventId : NONE pendingErrorSeqno : -1 pendingExceptionMessage: NONE pipelineSource : jdbc:mysql:thin://host3:13306/ relativeLatency : 8408.881 resourcePrecedence : 99 rmiPort : 10000 role : master seqnoType : java.lang.Long serviceName : beta serviceType : local simpleServiceName : beta siteName : default sourceId : host3 state : ONLINE timeInStateSeconds : 8408.21 transitioningTo : uptimeSeconds : 8409.88 useSSLConnection : false version : Tungsten Replicator 4.0.7 build 696 Finished status command...