Design Considerations v6.2

Keep the following points in mind when designing a replication system:

• Multi-master replication is supported only on PostgreSQL databases. In addition, Advanced Server databases must be running in the same compatibility mode – either all Oracle or all PostgreSQL.
• An Oracle table can be a member of at most one publication if all publications are subordinate to one publication database definition. However, an Oracle table can be a member of multiple publications if each publication is subordinate to a different publication database definition.
• A Postgres table can be a member of at most one publication.
• Each table used in a publication must have a primary key with the exception of tables in snapshot-only publications, which do not require a primary key.
• Make sure table definitions are well established before creating publications. Unless the DDL change replication feature is used as described in Section Replicating DDL Changes, if a table definition is changed, any publication containing the table along with its associated subscription must be deleted and recreated, otherwise replication may fail. The same applies for the table definitions in a primary definition node and its associated primary nodes. Replication failures can be seen in the replication history.
• Views can be members of snapshot-only publications. In the subscription database, a view is replicated as a table.
• A publication may have multiple subscriptions.
• A subscription can be associated with at most one publication.
• A database can contain both publications and subscriptions.
• A given publication server can support only one multi-master replication system. All primary nodes created subordinate to a given publication server are assumed to be part of the same multi-master replication system.
• A table that is created as a result of a subscription can be used in another publication. Thus, a publication can replicate data to a subscription which in turn, can be used in a publication to replicate to another subscription, thus creating a cascaded replication architecture.
• There are restrictions on the combinations and configurations of database servers that can be used for a publication and its subscription. See Advanced Server Compatibility Configuration Modes for details on these restrictions.
• All replication system components must be running in order for replication to occur, or before performing any configuration, operation, or modification in the replication system. (The xDB Replication Console is used for the configuration and modification of a replication system. The xDB Replication Console does not need to be running in order for replication to occur.)
• In general, the order of creation of a replication system is as follows:
  • Create the required physical databases, database user names, tables, and views to be used in the replication system.
  • Define the replication system logical components using the xDB Replication Console or xDB Replication Server CLI.
  • Perform replication.
• In general, the order of removal of a single-master replication system is as follows:
  • Remove the replication system logical components using the xDB Replication Console or xDB Replication Server CLI starting with the subscriptions (Subscription nodes) and then their parent components (Subscription Database nodes).
  • Unregister the subscription server if you no longer have any need for it.
  • Repeat the same process for the publications.
  • After all replication system logical components have been removed (except for possibly the publication server and subscription server) you can drop any of the physical database objects in Oracle, SQL Server, or Postgres. Do not drop the control schema objects manually, for example by using an SQL command line utility. Doing so may cause the xDB Replication Console and xDB Replication Server CLI to become inoperable. (See Deleting the Control Schema and Control Schema Objects if this problem occurs.) Deleting the replication system logical components using the xDB Replication Console or xDB Replication Server CLI automatically drops the control schema objects from the physical database.
• The order of removal of a multi-master replication system is as follows:
  • Remove the replication system logical components using the xDB Replication Console or xDB Replication Server CLI starting with the publication database definitions of the non-MDN nodes.
  • Remove the publication from under the primary definition node.
  • Remove the publication database definition of the primary definition node.
  • After all replication system logical components have been removed (except for possibly the publication server) you can drop any of the physical database objects in Postgres. Do not drop the control schema objects manually, for example by using an SQL command line utility. Doing so may cause the xDB Replication Console and xDB Replication Server CLI to become inoperable.