continuent tungsten mysql replicator guide

Continuent™ Replicator Guide

Continuent™ Replicator Guidewww.continuent.comCopyright © 2008 Continuent

The trademarks, logos, and service marks in this Document are the property of Continuent or other third parties. You are not permitted to use theseMarks without the prior written consent of Continuent or such appropriate third party. Continuent, Tungsten, uni/cluster, m/cluster, p/cluster, uc/connector, and the Continuent logo are trademarks or registered trademarks of Continuent in the United States, France, Finland and other countries.

All Materials on this Document are (and shall continue to be) owned exclusively by Continuent or other respective third party owners and areprotected under applicable copyrights, patents, trademarks, trade dress and/or other proprietary rights. Under no circumstances will you acquireany ownership rights or other interest in any Materials by or through your access or use of the Materials. All right, title and interest not expresslygranted is reserved to Continuent.

All rights reserved.

www.continuent.com

Continuent™ Replicator Guide

Continuent Replicator Guide - Document issue 1.0 iv

Table of Contents1 Building, Installing, and Running Replicator .................................................................................... 1

1.1 Installation Prerequisites ..................................................................................................... 11.2 Building Replicator from Source .......................................................................................... 11.3 Installing Replicator ............................................................................................................ 11.4 Running Replicator ............................................................................................................. 4

2 Replication Architecture and Key Components ............................................................................... 63 Introduction to Replicator .............................................................................................................. 7

3.1 Basic Replication ............................................................................................................... 73.2 Provisioning Slaves ............................................................................................................ 73.3 Switching the Master .......................................................................................................... 83.4 Consistency Checking ........................................................................................................ 83.5 Monitoring and Management APIs .................................................................................... 10

3.5.1 JMX/MBean Interface ............................................................................................ 104 Troubleshooting Replicator .......................................................................................................... 12

4.1 Error Handling ................................................................................................................. 124.2 Dealing with Failed Slaves ............................................................................................... 124.3 Dealing with a Failed Master ............................................................................................ 124.4 Database Failure .............................................................................................................. 134.5 Replicator State Machine .................................................................................................. 13

5 Command Reference Guide ........................................................................................................ 145.1 Running the Replicator from the Command Line Interface .................................................. 145.2 Running the Replicator as an Operating System Service .................................................... 145.3 Controlling a Running Replicator Process .......................................................................... 15

6 Extending the Replicator System ................................................................................................. 17

Building, Installing, and Running Replicator

Continuent Replicator Guide - Document issue 1.0 1

Chapter 1. Building, Installing, and RunningReplicator

This chapter explains how to install and run the Replicator. It is assumed that each Replicator instance runson a separate database node.

1.1 Installation PrerequisitesAnt 1.7.0 or above is required to build the Replicator.

JDK 1.5 or above is required to run the Replicator.

1.2 Building Replicator from SourceBuild the replicator using ant. Build instructions are provided in the README file found at the top of thesource tree (the root directory). The build procedure creates a build subdirectory in the root directory withthe following distribution files.

• tungsten-replicator-version.tgz

• tungsten-replicator-version.zip

You can install either archive as the contents are identical.

1.3 Installing ReplicatorTo install the Replicator, proceed as follows:

1. Copy the distribution archive to the database nodes and unpack at the location of your choice. In thefollowing code examples, we will use this location as the default directory.

On Linux, Solaris, MacOS X, and other Unix variants we recommend installing in directory /opt/continuent. On Windows, use for example the C:\Program Files directory.

NoteIf you use Windows and cannot unpack the .zip distribution archive, try installing another filecompression program, such as the 7-zip. You can also use the jar program distributed with theJava JDK.

2. Prepare the database nodes.

a. Install MySQL on the database nodes.

b. Edit your my.cnf configuration file to enable binlogging and to disable logging of the tungstendatabase. Use, for example, the my.cnf configuration file below:

[mysqld]# Master replication settings.log-bin=mysql-binserver-id=1binlog-ignore-db=tungsten

c. Start MySQL.

d. Create a new empty database called tungsten. Use, for example, the following command onyour MySQL client:



mysql> create database tungsten;

3. Dump the master database and upload it to all slaves in the cluster. For example, issue the followingcommand on the master:

mysqldump -uuser -ppassword -hmaster_host --all-databases > mydump.sql

On the slave:

mysql -uuser -ppassword -hslave_host < mydump.sql

Note

On Debian based distributions, you may have to copy the password value in /etc/mysql/debian.cnf from the master to the slave after taking a dump. Otherwise MySQL scripts willnot work.

4. Configure the Replicator instances.

a. In the unpacked distribution, open the conf/replicator.properties configuration file oneach node.

b. See below for example configurations. Pay attention to the following restrictions and instructions:

• replicator.node_id must be a unique name for each Replicator. The host name is a goodvalue if you have one Replicator per host.

• replicator.thl.remote_uri must contain the host name of the master.

• replicator.dbms_uri must have the correct host, port, login, and password vale for theserver

• The extractor binlog directory must be the same as defined with the log_bin option in themy.cnf MySQL configuration file.

In some Linux distributions, the MySQL binlog resides in /var/lib/mysql instead of the de-fault value in conf/replicator.properties (/var/log/mysql).

Master MySQL:=============## Node Identifier. This must be unique for each node.#replicator.node_id=master_host

## Transaction History UUID. This parameter is used to uniquely# identify transaction history. #replicator.history_uuid=2a849f26-d08d-4d69-9ee1-65cb5775fa02

## Replicator DBMS driver#replicator.dbms_driver=com.mysql.jdbc.Driver

## Replicator SQL Database URI. Must have administrator rights.#replicator.dbms_uri=jdbc:mysql://localhost/?user=root&password=rootpass



## Schema to store Replicator metadata#replicator.schema=tungsten

replicator.thl.uri=thl://0.0.0.0/replicator.thl.remote_uri=thl://master_host/

## Replicator SQL Event Extractor type. Currently recognized# values are 'dummy' and 'mysql'.#replicator.extractor=mysql## Replicator MySQL Event Extractor binlog directory.# Notice that in some operating system distributions# the MySQL binlog resides in /var/lib/mysql.#replicator.extractor.mysql.binlog_dir=/var/log/mysql## Replicator MySQL Event Extractor binlog file name pattern.#replicator.extractor.mysql.binlog_file_pattern=mysql-bin

## Set for events to contain checksums.# Possible values are 'SHA' or 'MD5' or empty for no checksums# The master and slave checksum settings must match#replicator.event.checksum=md5

## How to react on consistency check failure (stop|warn)#replicator.applier.consistency_policy=stop

Slave MySQL:============## Node Identifier. This must be unique for each node.#replicator.node_id=slave_1_host

## Transaction History UUID. This parameter is used to uniquely# identify transaction history. #replicator.history_uuid=2a849f26-d08d-4d69-9ee1-65cb5775fa02

## Replicator DBMS driver#replicator.dbms_driver=com.mysql.jdbc.Driver

## Replicator SQL Database URI. Must have administrator rights.



#replicator.dbms_uri=jdbc:mysql://localhost/?user=root&password=rootpass

## Schema to store Replicator metadata#replicator.schema=tungsten

replicator.thl.uri=thl://0.0.0.0/replicator.thl.remote_uri=thl://master_host/

## Replicator SQL Event Extractor type. Currently recognized values# are 'dummy' and 'mysql'.#replicator.extractor=mysql## Replicator MySQL Event Extractor binlog directory.# Notice that in some operating system distributions# the MySQL binlog resides in /var/lib/mysql.#replicator.extractor.mysql.binlog_dir=/var/log/mysql## Replicator MySQL Event Extractor binlog file name pattern.#replicator.extractor.mysql.binlog_file_pattern=mysql-bin

## Set for events to contain checksums.# Possible values are 'SHA' or 'MD5' or empty for no checksums# The master and slave checksum settings must match#replicator.event.checksum=md5

## How to react on consistency check failure (stop|warn)#replicator.applier.consistency_policy=stop

If you have followed these instructions so far and have MySQL installed, you should not need to make anyother changes.

1.4 Running Replicator

ImportantIn Linux, Solaris, and Mac OS X, the login used to run the Replicator must have permissions to readMySQL binlog files. Add the Replicator login to the mysql group, which will allow it to read but notwrite to the logs.

The Replicator is run and configured by using shell scripts residing in the /bin directory.

In Linux, Solaris, and Mac OS X, use the scripts below:

• trep_start.sh is used to start the Replicator.

• trep_ctl.sh is used to control the Replicator.

In Windows, use the scripts below:

• trep_start.bat is used to start the Replicator.



• trep_ctl.bat is used to control the Replicator.

To start the Replicator in Linux, Solaris, or Mac OS X, proceed as follows:

1. On master and all slaves, start the Replicator process:

bin/trep_start.sh

2. In the master node, command the Replicator to MASTER state.

a. bin/trep_ctl.sh configure

b. bin/trep_ctl.sh goOnline

c. bin/trep_ctl.sh goMaster

3. In all the slave nodes, command the Replicator to SLAVE state.

a. bin/trep_ctl.sh configure

b. bin/trep_ctl.sh goOnline

To start the Replicator in Windows, proceed as follows:

1. On master and all slaves, start the Replicator process:

bin/trep_start.bat

2. In the master node, command the Replicator to MASTER state.

a. bin/trep_ctl.bat configure

b. bin/trep_ctl.bat goOnline

c. bin/trep_ctl.bat goMaster

3. In all the slave nodes, command the Replicator to SLAVE state.

a. bin/trep_ctl.bat configure

b. bin/trep_ctl.bat goOnline

This is all it takes to start Tungsten Replicator master and slaves. You should now have your master andslave Replicators running and you can check the replication by making some data changes in the masterdatabase and verifying that the changes are reflected in the slave databases.

The use of trep_ctl.sh/trep_ctl.bat command is documented in Chapter 5, Command Reference Guide.See also Section 5.2, “Running the Replicator as an Operating System Service”.

Replication Architecture and Key Components


Chapter 2. Replication Architecture and KeyComponents

The Replicator is a process that runs on every host in the cluster. The Replicator has the key responsibilitiesexplained in the chapters below. The figure below depicts the replication architecture:

Figure 2.1. Replication Architecture

The components in the figure are:

• Master DBMS - The Database Management System (DBMS), which acts as the master for the replicationsystem. The master role can change, and any DBMS can be potentially elected as the master for thereplication.

• Slave DBMS - The slave DBMS receives replication events from the master DBMS and applies them.There can be any number of slaves in the replication system.

• Replication Event Extractor - The replication event extractor extracts replication events from the masterDBMS logs. Events are either SQL statements or rows from the replicated database.

• Transaction History Log - The transaction history log provides a persistent storage for replication eventsand communications with other transaction history logs in the cluster.

• Replication Event Applier - The replication event applier applies the replication events into the slaveDBMS.

• Node Manager - Node manager refers to the manager for Tungsten components running either on theslave or master node. Node manager connects to the Tungsten service manager at the upper level.

Introduction to Replicator


Chapter 3. Introduction to ReplicatorThe basic principles of the Replicator system are explained in the following chapters.

3.1 Basic Replication

The Tungsten replication system replicates all changes made in the master database to all the slaves in thecluster. Replication starts as soon as the master node is commanded to the ONLINE state. It is possible tostop and start slave nodes and add more slaves in the system on the fly.

Due to the asynchronous nature of the replication, there is some delay before changes made on the masternode will be reflected in the slave nodes. The latency depends on hardware, communication network, andthe SQL load profile and should be measured separately for each installation.

3.2 Provisioning Slaves

You can add more slaves in the system while the system is online. However, this is not an automatic process.To add a slave, proceed as follows:

1. Command the donor slave to the OFFLINE state:

In Linux, Solaris, or Mac OS X:

bin/trep_ctl.sh shutdown

In Windows:

bin/trep_ctl.bat shutdown

2. Take dumps from the tungsten database and your own database(s). Here, mydb is used as an ex-ample:

mysqldump -uuser -ppassword tungsten > tungsten.sql

mysqldump -uuser -ppassword mydb > mydb.sql

3. Command the donor slave back to the ONLINE state:


bin/trep_ctl.sh goOnline

In Windows:

bin/trep_ctl.bat goOnline

4. Make sure that MySQL is running on the new slave. Load the tungsten and the application databaseto the new slave:

mysql -uuser -ppassword < tungsten.sql

mysql -uuser -ppassword < mydb.sql

5. Reset the transaction history by using the following command:

mysql -uuser -ppassword -e"UPDATE tungsten.seqno_trxid_map SET trxid = NULL"

6. Start the Replicator on the new slave and command it to the SLAVE state:


bin/trep_start.sh&



bin/start_slave.sh

In Windows:

bin/trep_start.bat

bin/start_slave.bat

3.3 Switching the Master

You can switch the master as follows:

1. Edit the Replicator configuration file (replicator.properties) and setreplicator.thl.remote_uri to point to the new master on all nodes.

2. On the new master, run the command below:


bin/trep_ctl.sh reconfigure

In Windows:

bin/trep_ctl.bat reconfigure

Wait until the Replicator reaches the SLAVE state. Then, run:



bin/trep_ctl.sh goMaster

In Windows:


bin/trep_ctl.bat goMaster

to promote the slave as the new master.

3. On the remaining slaves, run the command below:



In Windows:


Wait until the Replicator reaches the SLAVE state.

3.4 Consistency Checking

Currently, the database consistency check is a manual process. This chapter explains how to check thedatabase consistency. This implementation was inspired by Maatkit (http://www.maatkit.org/).

Upon startup, the Replicator node manager creates a special table in the Replicator metadata schema:

CREATE TABLE consistency ( db char(64) NOT NULL,

http://www.maatkit.org/



tbl char(64) NOT NULL, id int NOT NULL, this_crc char(40) NOT NULL, /* Slave checksum */ this_cnt int NOT NULL, /* Slave row count */ master_crc char(40) NULL, /* Master checksum */ master_cnt int NULL, /* Master row count */ ts timestamp NOT NULL, command text NULL, PRIMARY KEY (db, tbl, id) );

The table keeps logs of consistency checks. Consistency check is a result of a specially forged transaction,which should follow the structure below:

START TRANSACTION;SET @crc:='', @cnt:=0;REPLACE INTO tungsten.consistency (id, db, tbl, this_cnt, this_crc) <SELECT_CLAUSE>;SET @crc:='', @cnt:=0;SELECT this_cnt, this_crc INTO @cnt, @crc FROM tungsten.consistency WHERE db = <schema> AND tbl = <table> AND id = <id>;UPDATE tungsten.consistency SET master_cnt = @cnt, master_crc = @crc, command = <REPLACE_STATEMENT> WHERE db = <schema> AND tbl = <table> AND id = <id>;COMMIT;

Where

• <table> - the name of the table to be checked.

• <schema> - the name of the schema that contains the table.

• <id> - a unique check identifier for the table. This identifieris used if you want to separately check differentregions of the table or differentiate between checks. The actual value is not important.

• <SELECT_CLAUSE> - a SELECT statement, which provides the values for the row. Its exact form dependson the table to be checked and the check type. This SELECT statement normally yields the same resultson both master and slave nodes. For example, if a table was created as:

CREATE TABLE my_schema.my_table ( idx int(11) NOT NULL auto_increment, value int(11) NOT NULL, PRIMARY KEY (idx) );

you can check the consistency of the first 100 rows by using a <SELECT_CLAUSE> as follows:

SELECT 1, 'my_schema', 'my_table', COUNT(*) AS cnt, RIGHT(MAX(@crc := CONCAT(LPAD(@cnt := @cnt + 1, 16, '0'), MD5(CONCAT(@crc, MD5(CONCAT_WS(idx, value)))))), 32) AS crc FROM my_schema.my_table WHERE idx > 0 AND idx < 100 LOCK IN SHARE MODE;

The order and number of <SELECT_CLAUSE> outputs must match the REPLACE inputs.

• <REPLACE_STATEMENT> - a concatenation of all transaction statements preceding and including RE-PLACE. In this case, the statements would be the first SET statement and the following REPLACE state-



ment. Notice that the concatenation includes the <SELECT_CLAUSE> as a part of the REPLACE state-ment. This parameter is required in row-level replication. In the case of statement-level replication, thisparameter can be an empty string.

For compatibility with databases that do not support the REPLACE command, the REPLACE command canbe substituted by an equivalent DELETE INSERT superposition as folows:

DELETE FROM tungsten.consistency WHERE db = <schema> AND tbl = <table> AND id = <id>;INSERT INTO tungsten.consistency (id, db, tbl, this_cnt, this_crc) <SELECT_CLAUSE>;

For an example of how to script consistency checks on MySQL, please see the mysql_cc_sample.shscript.

A consistency check is perfomed as follows:

1. When the Extractor detects a consistency check transaction in the binlog stream, it creates a specialconsistency check event. In the case of row-level replication, it uses information contained in the lastUPDATE statement to recover the original <REPLACE_STATEMENT>, and restores the transaction tothe statement form.

2. On the slave, the Applier receives the consistency check event and applies the transaction in theevent, as if it were a normal statement-level SQL event. This causes the slave to perform the same<SELECT_CLAUSE> as the master and the master values are carried by the last UPDATE statement.

Next, the Applier selects the master and slave CRC values from the updated row and compares them.If the comparison fails, the Applier notifies the node manager of the failure and either stops or contin-ues working depending on the replicator.applier.consistency_policy setting, which canbe either stop or warn.

3.5 Monitoring and Management APIs

The Replicator has the following monitoring and management APIs:

3.5.1 JMX/MBean Interface

The JMX/MBean interface is the management interface between the Replicator and the management sys-tem. The high-level architecture of the JMX/MBean interface consists of three components:

• The management system provides a user interface to the Replicator states and error notifications.

• The JMX/MBean interface is the management interface between the Replicator and the managementsystem.

• The Replicator contains the state machine that changes the Replicator state in line with the state changecommands from the JMX/MBean interface. It also sends state change and error notifications to the JMX/MBean interface.

The figure below depicts the high-level failover architecture:



Figure 3.1. High-Level Failover Architecture

The JMX/MBean interface contains the following methods:

• configure() - This method is used to configure the Replicator. It is only allowed in the OFFLINE state.

• reconfigure() - This method is used to re-configure the Replicator. This method only affects param-eters associated to THL connectivity (remote THL address). This method is allowed in all other statesexcept in the MASTER state.

• goOnline() - This method is used to set the Replicator to the ONLINE state.

• goMaster() - This method is used to set the Replicator to the MASTER state. It is only allowed in theONLINE state.

• shutdown() - This method is used to set the Replicator to the OFFLINE state.

• progressPoll() - This method is used to get the Replicator status.

The Replicator also gives notifications. These notifications can be listened to by registering a JMX notifi-cation listener. See Section 4.1, “Error Handling” for more information on errors. The Replicator can givenotifications as follows:

• StateChangeNotification - This notification is sent when the Replicator state machine reaches anew state.

Furthermore, recoverable errors are enclosed into state change notifications.

• ErrorNotification - This notification is sent when one of the Replicator components encounters anunrecoverable error.

Troubleshooting Replicator


Chapter 4. Troubleshooting ReplicatorThis chapter deals with Replicator troubleshooting.

4.1 Error Handling

Recoverable error notifications are enclosed into state change notifications to provide atomic notification oferror and state change for the management system. In the case of an unrecoverable error, the Replicatorwaits in the OFFLINE state - instead of immediately shutting down - to avoid ambiguities that may resultwhen a JMX connection error is detected before an error notification is delivered to the management system.The Replicator in the OFFLINE state must be restarted before its state can be changed again.

4.2 Dealing with Failed Slaves

If one of the Tungsten slave nodes fails, the master node and other slaves will keep on working withoutinterruption. In other words, the cluster is functional despite the slave problem.

To recover from a slave node failure, it is essential to first analyze the reason for the node failure and fixany problem(s) that can prevent the future slave operation.

Once you have fixed the problem on the slave node, you can join the slave node in the cluster by followingthe instructions in Section 3.2, “Provisioning Slaves”.

4.3 Dealing with a Failed Master

This chapter concentrates to a simple failover scenario, where the master database or the master Replicatorprocess failure leads to a failover.

To recover, proceed as follows:

1. Check the Replicator status by issuing the command below:


bin/trep_ctl.sh

In Windows:

bin/trep_ctl.bat

Wait until both slaves end up to the SYNCHRONIZING state.

2. Check the seqno ranges from both slaves by issuing the command below:


bin/trep_ctl.sh

In Windows:

bin/trep_ctl.bat

Select the slave with the greater max seqno as the new master.

3. Edit the Replicator configuration file replicator.properties and setreplicator.thl.remote_uri to point to the new master on both old slave nodes.

4. On the new master, run the command below:



Troubleshooting Replicator


In Windows:


Wait until the Replicator reaches the SLAVE state. Then, run:



bin/trep_ctl.sh goMaster

In Windows:


bin/trep_ctl.bat goMaster

This promotes the slave as the new master.

5. On the remaining slave, run the command below:



In Windows:


Wait until the Replicator reaches the SLAVE state.

4.4 Database Failure

If the database fails, the node is considered as failed and the procedure for a failed master or failed slaveis used, accordingly.

4.5 Replicator State Machine

The Replicator state machine contains the following states:

• OFFLINE - The Replicator process is running, but none of its subprocesses are.

• SYNCHRONIZING - The Replicator applier subprocess is running and is either connecting to the remoteTHL instance or waiting for a reconfiguration that changes the remote THL address and the goOnline()command that follows it.

• ONLINE - The Replicator applier subprocess is running, has connected successfully to the remote THLinstance and detected that a continuous sequence of SQLEvents can be fetched from the remote THL.

• MASTER - The Replicator extractor is running, extracting a database log, and storing SQLEvents intothe THL.

Command Reference Guide


Chapter 5. Command Reference GuideThe Replicator can be run from the command line interface or run as an operating system process. Thefollowing commands are available for the Replicator.

5.1 Running the Replicator from the Command Line Interface

The Replicator bin directory contains scripts that can be used to start and stop the Replicator from thecommand line prompt.

Linux, Solaris, and Mac OS X Command Line Interfaces

Use these commands to run the Replicator from the command line prompt in the Linux, Solaris, and MacOS X operating systems.

• bin/trep_ctl.sh shutdown

This command is used to stop the Replicator in an orderly manner. Run this command before runningthe bin/trep_stop.sh command.

• bin/trep_stop.sh

This command stops the Replicator process if it is running. Run the bin/trep_ctl.sh shutdown commandbefore this command. After you have issued this command, the master or slave Replicator enters theOFFLINE state.

• bin/trep_start.sh

This command starts the Replicator process if it is not already running.

Windows Command Line Interface

Use these commands to run the Replicator from the command line prompt in the Windows operating system.

• bin/trep_stop.bat

This command is used to command the master or slave Replicator to enter the OFFLINE state.

• bin/trep_start.bat

This command starts the Replicator process if it is not running.

5.2 Running the Replicator as an Operating System Service

These instructions are only applicable for the Linux, Solaris, and Mac OS X operating systems.

The Replicator includes a service implementation based on the Java Service Wrapper (http://wrapper.tanukisoftware.org). This allows you to run the Replicator as a service that has protection againstsignals and it also implements the standard interface used by Unix Services. The service implementationalso restarts the Replicator in the event of a crash.

You can adjust the Replicator service configuration by editing the conf/wrapper.properties configu-ration file. Please read the comments in the file for information on legal settings. For most installations, theincluded file should work out of the box.

The Replicator service implementation supports services on 32-bit and 64-bit versions of Linux, and on MacOS X platforms.

The Replicator service wrapper binary is called the trepsvc. in practice, the trepsvc is a replacementfor the trep_start.sh and trep_stop.sh commands. The trepsvc commands are summarized below:

http://wrapper.tanukisoftware.org

http://wrapper.tanukisoftware.org



• trepsvc start - This command starts the Replicator service if it is not already running. Logs are writtento log trepsvc.log.

• trepsvc status - This command prints out the status of the Replicator service, namely whether it is runningand if it is, on which process number.

• trepsvc stop - This command stops the Replicator service if it is currently running.

• trepsvc restart - This command restarts the Replicator service, stopping it first if it is currently running.

• trepsvc console - This command runs the Replicator service in a Java console program that allows youto view log output in a GUI shell.

• trepsvc dump - This command sends a 'kill -quit' signal to the Java VM to force it to write a thread dumpto the log. This command is useful for debugging a stuck process.

5.3 Controlling a Running Replicator Process

The commands in the sections below change the Replicator state.

Controlling a Running Replicator Process in Linux, Solaris and Mac OS X Op-erating Systems

The trep_ctl.sh script allows you to submit commands to the Replicator. These commands change theReplicator state.

• bin/trep_ctl.sh configure [file]

This command uploads the Replicator configuration. The configure command should only be usedinitially, when the node is in the OFFLINE state. For later configuration changes, use the reconfigurecommand.

The Replicator reads the ../conf/replicator.properties file by default. An alternative propertyfile can be specified by giving the configuration property file name as an argument.

• bin/trep_ctl.sh reconfigure [file]

This command uploads the Replicator configuration and resets the applying process in the node. Thereconfigure command can be issued in SYNCHRONIZING and SLAVE states.


• bin/trep_ctl.sh goMaster

This command is used to command the slave Replicator to enter the MASTER state. Always issue thegoOnline command before the goMaster command.

• bin/trep_ctl.sh goOnline

This command is used to command the master Replicator to enter the ONLINE state.

• bin/trep_ctl.sh

Run the bin/trep_ctl.sh command without arguments to check the Replicator state.

Controlling a Running Replicator Process in the Windows Operating System

The trep_ctl.bat script allows you to submit commands to the Replicator. These commands changethe Replicator state.

• bin/trep_ctl.bat configure [file]



This command uploads the Replicator configuration. The configure command should only be usedinitially, when the node is in the OFFLINE state. For later configuration changes, use the reconfigurecommand.


• bin/trep_ctl.bat reconfigure [file]

This command uploads the Replicator configuration and resets the applying process in the node. Thereconfigure command can be issued in SYNCHRONIZING and SLAVE states.


• bin/trep_ctl.bat goMaster

This command is used to command the slave Replicator to enter the MASTER state. Always issue thegoOnline command before the goMaster command.

• bin/trep_ctl.bat goOnline

This command is used to command the master Replicator to enter the ONLINE state.

• bin/trep_ctl.bat

Run the bin/trep_ctl.bat command without arguments to check the Replicator state.

Extending the Replicator System


Chapter 6. Extending the Replicator SystemThe Replicator system can be extended by using adapters for different DBMSs.

To be more specific, the replication event extracting is a generic framework, which allows adapters fordifferent DBMSs to plug in. The master node connects to one DBMS only, which means that only one ofthe adapters is needed for a particular installation. The adapters convert native DBMS log information intogeneric replication events (SQLEvent), which are then propagated to the transaction history log for furtherprocessing.

The diagram below depicts the internal structure of the extracting process and transaction history log. Inthis figure, Oracle is used as the source database.

Figure 6.1. Extracting of Replication Events

continuent tungsten mysql replicator guide

Documents