From a technical standpoint, you can set up a bidirectional replication scenario using only two Replication Server database connections (one “primary-and-replicate” connection for each database). However, this document describes four connections, one for each database acting as a primary database, and one for each database acting as a replicate database.
In the following description of bidirectional replication
issues, the two databases are referred to as Database #1
and Database #2, because both databases take on both “primary” and “replicate” roles
in the replication system.
You must consider the following issues in a bidirectional non-Sybase primary to non-Sybase replicate configuration:
The Replication Server primary database connection for Database #1 must include a valid user ID and password for the primary database. This user ID must be the same user ID specified in the Replication Server replicate database connection for Database #1 (the Maintenance User). This user ID must have authority to apply transaction operations to replicate tables in Database #1.
The Replication Agent for Database #1 must be configured to bypass Maintenance User transactions to prevent a transaction from returning from the replicate tables in Database #1. Refer to the appropriate Replication Agent Administration Guide for details on configuring the Replication Agent to bypass Maintenance User transactions.
The Replication Server primary database connection for Database #2 must include a valid user ID and password for the primary database. This user ID must be the same user ID specified in the Replication Server replicate database connection for Database #2 (the Maintenance User). This user ID must have authority to apply transaction operations to replicate tables in Database #2.
The Replication Agent for Database #2 must be configured to bypass Maintenance User transactions to prevent a transaction from returning from the replicate tables in Database #2. Refer to the appropriate Replication Agent Administration Guide for details on configuring the Replication Agent to bypass Maintenance User transactions.
The hds_xxx_setup_for_replicate.sql script for each database must be executed against the database to create the rs_info and rs_lastcommit tables that Replication Server requires for a replicate database.
The Replication Server database connection for replicate Database #1 must be created referencing the correct function-string class designed for this particular database as a replicate database (for example, rs_oracle_function_class.)
The Replication Server database connection for replicate Database #2 must be created referencing the correct function-string class designed for this particular database as a replicate database (for example, rs_informix_function_class.)
The hds_xxx_funcstrings.sql script for each database must be applied to the RSSD of the replicate Replication Server for each database.
The hds_clt_ase_to_xxx.sql script must be applied to the RSSD of each replicate Replication Server to provide class-level translation of Adaptive Server native datatypes to replicate database native datatypes.
Even if you are not replicating from an Adaptive Server primary database, Adaptive Server native datatypes are used in the default Replication Server function-string calls to maintain the rs_lastcommit table. In addition, replication definitions for a non-Sybase primary database may use Adaptive Server native datatypes.
If you use a Replication Server HDS datatype definition to define a column’s datatype in a replication definition (for either Database #1 or Database #2), the hds_clt_xxx_to_yyy.sql script must be applied to the RSSD of the replicate Replication Server to provide automatic translation of the primary database datatype to a replicate database native datatype.
For example, you must apply the hds_clt_informix_to_oracle.sql script to the RSSD of the replicate Replication Server for Database #1. You must apply the hds_clt_oracle_to_informix.sql script to the RSSD of the replicate Replication Server for Database #2.
If you can use existing Replication Server native datatypes to represent all the columns (that is, no datatype definitions are required), then no HDS translation scripts need be applied.
No additional translation script is required if the
same type of
non-Sybase database is used for both primary and replicate databases
(for example, Informix to Informix).
