Use the activate config command to activate a configuration. Replication begins immediately as soon as the activation process is complete.

The activation process reads the configuration file, from which it gets all of the information needed for SharePlex to:

• Identify the objects that are in replication
• Route the replicated changes to the appropriate source and target database
• Generate the SQL that Post uses to apply the changes to the target
• Activate all of the tables that have been added to replication

The process that sp_cop calls to activate a configuration is sp_tconf.

Notes: While activating the configuration using logical replication, if any uncommitted transactions are being executed on the PostgreSQL instance, you may experience lag in the config activation. For partitioned tables, users must set the replica identity to full for all its sub-partitions. If not set, verify config will display a message as "Object may not be replicated because replica identity is not full for its partitions." Activation will not add the partitioned table in replication. It will log all the sub-partition table names that do not have replica identity set to full in the activation log.

Guidelines for activation

• To activate a configuration, the database containing the objects to be replicated must be mounted and open. The length of time that activation takes varies, depending on the size, number and structure of the configured objects.
• You can activate one configuration per PostgreSQL server on each system. For example, if there are ConfigA, ConfigB and ConfigC for instance dbname1, you can activate only one of them at a time. Activating another configuration for the same datasource automatically deactivates the first one.

• Before you activate a configuration, use the verify config command to confirm that basic requirements for successful activation and replication have been satisfied. The command alerts you to potential problems that can cause the activation to fail.

View activation status and results

SharePlex activates objects according to their object ID, not their order in the configuration file, so there is no way to predict the order of activation.

To view the results of activation, issue the show config command

What to do if activation fails

Many things can cause the activation of a table or the entire configuration to fail. For example, if one or more components in the configuration file were entered incorrectly, activation of the affected objects fails.

If you did not issue the verify config command before you activated, run it now, and correct any problems that it finds. Then, try activating again.

Usage

Supported sources:	PostgreSQL (pglsn option only applicable for physical replication.) , Amazon RDS for PostgreSQL, Amazon Aurora for PostgreSQL, Azure Database for PostgreSQL Flexible Server, and Google Cloud SQL for PostgreSQL
Supported targets:	PostgreSQL, Oracle, SQL Server, Kafka, Amazon RDS for PostgreSQL, Amazon Aurora for PostgreSQL, Azure Database for PostgreSQL Flexible Server, and Google Cloud SQL for PostgreSQL
Authorization level:	Administrator (1)
Issues for:	source system
Related commands:	abort config, copy config, create config, deactivate config, edit config, list config, purge config, remove config, rename config, show config, verify config , view config

Syntax

Basic command	Command option
activate config filename	pglsn=lsn_value

Syntax description

Component	Description
filename	Required. The name of the configuration that you want to activate. Configuration names are case-sensitive. Example: sp_ctrl(sysA)>activate config sales
pglsn=lsn_number	Use this option to activate the configuration to start replication at a specific LSN in the WAL files. Before activating the configuration, do the following: If there was a previously active configuration, run the pg_cleansp utility on the source and all targets to restore the environment to a clean state. For more information, see pg_cleansp. Use the show last_posted command to get the LSNs of the last transactions that were posted from all the Post processes (if using named queues). Use the lowest of those LSN values for activate config. Example: sp_ctrl> activate config myconfig pglsn=6/555FAE0 Note: Activate with LSN is not supported for logical replication. If database goes out of sync, user need to sync the data manually using external utilities.

Note: After successful activation physical and logical slots will get created in the database.

 

Important! Steps to follow when performing the alter table add/drop column operation which is part of ongoing replication. Cautions: Do not stop the Capture process while altering the table. No DML operations should be performed on the table for which column is being added or dropped. Follow the below steps: Execute the query for alter table add/drop column without performing any DML on the table. Reactivate the config file again so that the latest details are fetched and stored in the object cache of all the processes. Once reactivation is done, then DML operations can be performed on the table. Steps to follow when performing the alter table add/drop partition operation which is part of ongoing replication. Cautions: Do not stop the Capture process while altering the table. (applicable only if reactivation is being done) No DML operations should be performed on the table for which partition is being added or dropped. Follow the below steps: Execute the query for alter table add/drop partition without performing any DML on the table. Reactivate the config file again or restart the Capture process so that the latest partition details are fetched and used by the Capture process. Once reactivation or restart Capture process is done, then DML operations can be performed on the table.