Be sure to place the cluster into MAINTENANCE mode first so the Manager does not attempt to automatically bring the replicator online.
cctrl> set policy maintenanceTo enable parallel replication after installation, take the replicator offline cleanly using the following command:
shell> trepctl offlineModify the configuration to add two parameters:
[defaults]
...
svc-parallelization-type=disk
channels=10Run the tpm command to update the software with the INI-based configuration:
shell> tpm query staging
tungsten@db1:/opt/continuent/software/tungsten-clustering-7.0.3-141
shell> echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`
The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-7.0.3-141
shell> cd {STAGING_DIRECTORY}
shell> ./tools/tpm updateFor information about making updates when using an INI file, please see Section 10.4.4, “Configuration Changes with an INI file”.
You make use an actual data service name in place of the keyword defaults.
Signal the changes by a complete restart of the Replicator process:
shell> replicator restartBe sure to place the cluster into AUTOMATIC mode as soon as all replicators are updated and back online.
cctrl> set policy automaticYou can check the number of active channels on a Replica by looking at the "channels" property once the replicator restarts.
Replica shell> trepctl -service alpha status| grep channels
channels : 10The channel count for a Primary will ALWAYS be 1 because extraction is single-threaded:
Primary shell> trepctl -service alpha status| grep channels
channels : 1Enabling parallel apply will dramatically increase the number of connections to the database server.
Typically the calculation on a Replica would be: Connections = Channel_Count x Sevice_Count x 2, so for a 4-way Composite Composite Active/Active topology with 30 channels there would be 30 x 4 x 2 = 240 connections required for the replicator alone, not counting application traffic.
You may display the currently used number of connections in MySQL:
mysql> SHOW STATUS LIKE 'max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 190 |
+----------------------+-------+
1 row in set (0.00 sec)Below are suggestions for how to change the maximum connections setting in MySQL both for the running instance as well as at startup:
mysql> SET GLOBAL max_connections = 512;
mysql> SHOW VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 512 |
+-----------------+-------+
1 row in set (0.00 sec)
shell> vi /etc/my.cnf
#max_connections = 151
max_connections = 512To change the number of channels you must take the replicator offline cleanly using the following command:
shell> trepctl offline
This command brings all channels up the same transaction in the log,
then goes offline. If you look in the
trep_commit_seqno table, you will
notice only a single row, which shows that updates to the Replica have
been completely serialized to a single point. At this point you may
safely reconfigure the number of channels on the replicator, for example
using the following command:
Click the link below to switch examples between Staging and INI methods...
[alpha]
...
channels=5Run the tpm command to update the software with the INI-based configuration:
shell> tpm query staging
tungsten@db1:/opt/continuent/software/tungsten-clustering-7.0.3-141
shell> echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`
The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-7.0.3-141
shell> cd {STAGING_DIRECTORY}
shell> ./tools/tpm updateFor information about making updates when using an INI file, please see Section 10.4.4, “Configuration Changes with an INI file”.
You can check the number of active channels on a Replica by looking at the "channels" property once the replicator restarts.
If you attempt to reconfigure channels without going offline cleanly,
Tungsten Replicator will signal an error when you attempt to go online
with the new channel configuration. The cure is to revert to the
previous number of channels, go online, and then go offline cleanly.
Note that attempting to clean up the
trep_commit_seqno and
trep_shard_channel tables manually
can result in your Replicas becoming inconsistent and requiring full
resynchronization. You should only do such cleanup under direction from
Continuent support.
Failing to follow the channel reconfiguration procedure carefully may result in your Replicas becoming inconsistent or failing. The cure is usually full resynchronization, so it is best to avoid this if possible.
The following steps describe how to gracefully disable parallel apply replication.
To disable parallel apply, you must first take the replicator offline cleanly using the following command:
shell> trepctl offline
This command brings all channels up the same transaction in the log,
then goes offline. If you look in the
trep_commit_seqno table, you will
notice only a single row, which shows that updates to the Replica have
been completely serialized to a single point. At this point you may
safely disable parallel apply on the replicator, for example using the
following command:
Click the link below to switch examples between Staging and INI methods...
[alpha]
...
svc-parallelization-type=none
channels=1Run the tpm command to update the software with the INI-based configuration:
shell> tpm query staging
tungsten@db1:/opt/continuent/software/tungsten-clustering-7.0.3-141
shell> echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`
The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-7.0.3-141
shell> cd {STAGING_DIRECTORY}
shell> ./tools/tpm updateFor information about making updates when using an INI file, please see Section 10.4.4, “Configuration Changes with an INI file”.
You can check the number of active channels on a Replica by looking at the "channels" property once the replicator restarts.
shell> trepctl -service alpha status| grep channels
channels : 1
If you attempt to reconfigure channels without going offline cleanly,
Tungsten Replicator will signal an error when you attempt to go online
with the new channel configuration. The cure is to revert to the
previous number of channels, go online, and then go offline cleanly.
Note that attempting to clean up the
trep_commit_seqno and
trep_shard_channel tables manually
can result in your Replicas becoming inconsistent and requiring full
resynchronization. You should only do such cleanup under direction from
Continuent support.
Failing to follow the channel reconfiguration procedure carefully may result in your Replicas becoming inconsistent or failing. The cure is usually full resynchronization, so it is best to avoid this if possible.
As with channels you should only change the parallel queue type after the replicator has gone offline cleanly. The following example shows how to update the parallel queue type after installation:
Click the link below to switch examples between Staging and INI methods...
[alpha]
...
svc-parallelization-type=disk
channels=5Run the tpm command to update the software with the INI-based configuration:
shell> tpm query staging
tungsten@db1:/opt/continuent/software/tungsten-clustering-7.0.3-141
shell> echo The staging DIRECTORY is `tpm query staging| cut -d: -f2`
The staging DIRECTORY is /opt/continuent/software/tungsten-clustering-7.0.3-141
shell> cd {STAGING_DIRECTORY}
shell> ./tools/tpm updateFor information about making updates when using an INI file, please see Section 10.4.4, “Configuration Changes with an INI file”.
Show Copy-friendly Text