3.2. Deploying a Primary/Replica Topology

3.2. Deploying a Primary/Replica Topology
Prev	^Up	Chapter 3. Deploying MySQL Extractors	Next

3.2. Deploying a Primary/Replica Topology

3.2.1. Monitoring the MySQL Extractor

Primary/Replica is the simplest and most straightforward of all replication scenarios, and also the basis of all other types of topology. The fundamental basis for the Primary/Replica topology is that changes in the Primary are distributed and applied to the each of the configured Replicas.

Figure 3.1. Topologies: Primary/Replica

This deployment style can be used against the following sources

MySQL Community Edition
MySQL Enterprise Edition
Percona MySQL
MariaDB

This deployment assumes full access to the host, including access to Binary Logs, therefore this deployment style is not suitable for Cloud Managed database, such as Amazon Aurora or Google Cloud SQL. For these sources, see Section 3.3, “Deploying an Extractor for Cloud Managed SQL”

tpm includes a specific topology structure for the basic Primary/Replica configuration, using the list of hosts and the Primary host definition to define the Primary/Replica relationship. Before starting the installation, the prerequisites must have been completed (see Appendix B, Prerequisites). To create a Primary/Replica using tpm:

Install the Tungsten Replicator package (see Section 2.1.2, “Using the RPM package files”), or download the compressed tarball and unpack it into a staging directory:
```
shell> cd /opt/continuent/software
shell> tar zxf tungsten-replicator-7.0.3-141.tar.gz
```
Change to the Tungsten Replicator staging directory:
```
shell> cd tungsten-replicator-7.0.3-141
```
Onboard Installation
Configure the replicator for extraction from a locally installed and configured MySQL Installation (In this example, the service name is alpha)
```
shell> vi /etc/tungsten/tungsten.ini
```
```
[defaults]
user=tungsten
install-directory=/opt/continuent
profile-script=~/.bash_profile
mysql-allow-intensive-checks=true
rest-api-admin-user=apiuser
rest-api-admin-pass=secret
replicator-rest-api-address=0.0.0.0
install=true

[alpha]
master=localhost
members=localhost
replication-port=3306
replication-user=tungsten
replication-password=secret
```
Configuration group defaults
The description of each of the options is shown below; click the icon to hide this detail:
Click the icon to show a detailed description of each argument.
- user=tungsten
  System User
- install-directory=/opt/continuent
  Path to the directory where the active deployment will be installed. The configured directory will contain the software, THL and relay log information unless configured otherwise.
- profile-script=~/.bash_profile
  Append commands to include env.sh in this profile script
- mysql-allow-intensive-checks=true
  For MySQL installation, enables detailed checks on the supported data types within the MySQL database to confirm compatibility. This includes checking each table definition individually for any unsupported data types.
- rest-api-admin-user=apiuser
  Optional: Must be specified along with rest-api-admin-pass if you wish to access the full API features and use the Dashboard GUI for cluster installations.
- rest-api-admin-pass=secret
  Optional: Must be specified along with rest-api-admin-user if you wish to access the full API features.
- replicator-rest-api-address=0.0.0.0
  Address for the API to bind too.
- install=true
  Install service start scripts
Configuration group alpha
The description of each of the options is shown below; click the icon to hide this detail:
Click the icon to show a detailed description of each argument.
- master=localhost
  The hostname of the primary (extractor) within the current service.
- members=localhost
  Hostnames for the dataservice members
- replication-port=3306
  The network port used to connect to the database server. The default port used depends on the database being configured.
- replication-user=tungsten
  For databases that required authentication, the username to use when connecting to the database using the corresponding connection method (native, JDBC, etc.).
- replication-password=secret
  The password to be used when connecting to the database using the corresponding --replication-user.
In the above example, datasource-mysql-conf, is optional and can be used if the MySQL configuration file cannot be located by tpm, or is in a non-default location
Offboard Installation
Configure the replicator for extraction from a remotely installed and configured MySQL Installation (In this example, the service name is alpha)
In the example below, the server offboardhost is the host that the Replicator is installed upon, and the server dbhost is the database host to apply the events to.
```
shell> vi /etc/tungsten/tungsten.ini
```
```
[defaults]
install-directory=/opt/continuent
user=tungsten
profile-script=~/.bash_profile
mysql-allow-intensive-checks=true
skip-validation-check=MySQLAvailableCheck
skip-validation-check=MySQLConfFile
skip-validation-check=RowBasedBinaryLoggingCheck
rest-api-admin-user=apiuser
rest-api-admin-password=secret
replicator-rest-api-address=0.0.0.0

[alpha]
master=offboardhost
members=offboardhost
enable-heterogeneous-service=true
privileged-master=true
replication-host=dbhost
replication-port=3306
replication-user=tungsten_alpha
replication-password=secret
```
Configuration group defaults
The description of each of the options is shown below; click the icon to hide this detail:
Click the icon to show a detailed description of each argument.
- install-directory=/opt/continuent
  Path to the directory where the active deployment will be installed. The configured directory will contain the software, THL and relay log information unless configured otherwise.
- user=tungsten
  System User
- profile-script=~/.bash_profile
  Append commands to include env.sh in this profile script
- mysql-allow-intensive-checks=true
  For MySQL installation, enables detailed checks on the supported data types within the MySQL database to confirm compatibility. This includes checking each table definition individually for any unsupported data types.
- skip-validation-check=MySQLAvailableCheck
  The skip-validation-check disables a given validation check. If any validation check fails, the installation, validation or configuration will automatically stop.
  Warning
  Using this option enables you to bypass the specified check, although skipping a check may lead to an invalid or non-working configuration.
  You can identify a given check if an error or warning has been raised during configuration. For example, the default table type check:
```
ERROR >> centos >> The datasource root@centos:3306 (WITH PASSWORD) » 
 uses MyISAM as the default storage engine (MySQLDefaultTableTypeCheck)
```
  The check in this case is MySQLDefaultTableTypeCheck, and could be ignored using skip-validation-check=MySQLDefaultTableTypeCheck.
  Values can be passed as a comma-separated list, or single skip-validation-check entries for each check to be skipped.
  Setting both skip-validation-check and enable-validation-check is equivalent to explicitly disabling the specified check.
- skip-validation-check=MySQLConfFile
  The skip-validation-check disables a given validation check. If any validation check fails, the installation, validation or configuration will automatically stop.
  Warning
  Using this option enables you to bypass the specified check, although skipping a check may lead to an invalid or non-working configuration.
  You can identify a given check if an error or warning has been raised during configuration. For example, the default table type check:
```
ERROR >> centos >> The datasource root@centos:3306 (WITH PASSWORD) » 
 uses MyISAM as the default storage engine (MySQLDefaultTableTypeCheck)
```
  The check in this case is MySQLDefaultTableTypeCheck, and could be ignored using skip-validation-check=MySQLDefaultTableTypeCheck.
  Values can be passed as a comma-separated list, or single skip-validation-check entries for each check to be skipped.
  Setting both skip-validation-check and enable-validation-check is equivalent to explicitly disabling the specified check.
- skip-validation-check=RowBasedBinaryLoggingCheck
  The skip-validation-check disables a given validation check. If any validation check fails, the installation, validation or configuration will automatically stop.
  Warning
  Using this option enables you to bypass the specified check, although skipping a check may lead to an invalid or non-working configuration.
  You can identify a given check if an error or warning has been raised during configuration. For example, the default table type check:
```
ERROR >> centos >> The datasource root@centos:3306 (WITH PASSWORD) » 
 uses MyISAM as the default storage engine (MySQLDefaultTableTypeCheck)
```
  The check in this case is MySQLDefaultTableTypeCheck, and could be ignored using skip-validation-check=MySQLDefaultTableTypeCheck.
  Values can be passed as a comma-separated list, or single skip-validation-check entries for each check to be skipped.
  Setting both skip-validation-check and enable-validation-check is equivalent to explicitly disabling the specified check.
- rest-api-admin-user=apiuser
  Optional: Must be specified along with rest-api-admin-pass if you wish to access the full API features and use the Dashboard GUI for cluster installations.
- rest-api-admin-password=secret
  Optional: Must be specified along with rest-api-admin-user if you wish to access the full API features.
- replicator-rest-api-address=0.0.0.0
  Address for the API to bind too.
Configuration group alpha
The description of each of the options is shown below; click the icon to hide this detail:
Click the icon to show a detailed description of each argument.
- master=offboardhost
  The hostname of the primary (extractor) within the current service.
- members=offboardhost
  Hostnames for the dataservice members
- enable-heterogeneous-service=true
  - On a Primary
    mysql-use-bytes-for-string is set to false.
    colnames filter is enabled (in the binlog-to-q stage to add column names to the THL information.
    pkey filter is enabled (in the binlog-to-q and q-to-dbms stage), with the addPkeyToInserts and addColumnsToDeletes filter options set to false.
    enumtostring filter is enabled (in the q-to-thl stage), to translate ENUM values to their string equivalents.
    settostring filter is enabled (in the q-to-thl stage), to translate SET values to their string equivalents.
  - On a Replica
    mysql-use-bytes-for-string is set to true.
    pkey filter is enabled (q-to-dbms stage).
- privileged-master=true
  Does the login for the Primary database service have superuser privileges
- replication-host=dbhost
  Hostname of the datasource where the database is located. If the specified hostname matches the current host or member name, the database is assumed to be local. If the hostnames do not match, extraction is assumed to be via remote access. For MySQL hosts, this configures a remote replication Replica (relay) connection.
- replication-port=3306
  The network port used to connect to the database server. The default port used depends on the database being configured.
- replication-user=tungsten_alpha
  For databases that required authentication, the username to use when connecting to the database using the corresponding connection method (native, JDBC, etc.).
- replication-password=secret
  The password to be used when connecting to the database using the corresponding --replication-user.
Note
If you plan to make full use of the REST API (which is enabled by default) you will need to also configure a username and password for API access. This must be done by specifying the following options in your configuration:
```
rest-api-admin-user=tungsten
rest-api-admin-pass=secret
```
Once the prerequisites and configuring of the installation has been completed, the software can be installed:
```
shell> ./tools/tpm install
```

In both of the above examples, enable-heterogeneous-service, is only required if the target applier is NOT a MySQL database

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 can now proceed to configure the Applier service following the relevant step within Chapter 4, Deploying Appliers.

Following installation of the applier, the services can be started. For information on starting and stopping Tungsten Replicator see Section 2.4, “Starting and Stopping Tungsten Components”; configuring init scripts to startup and shutdown when the system boots and shuts down, see Section 2.5, “Configuring Startup on Boot”.

For information on checking the running service, see Section 3.2.1, “Monitoring the MySQL Extractor”.

Prev	Up	Next
3.1. MySQL Replication Prerequisites	^Level	3.2.1. Monitoring the MySQL Extractor

Continuent Documentation

3.2. Deploying a Primary/Replica Topology

Warning

Warning

Warning

Note