Primary and Replicate Databases and Warm Standby Applications

A logical database may also function as a primary or a replicate database.

In many Replication Server applications:

A primary database is the source of data that is copied to other databases through the use of replication definitions and subscriptions.
A replicate database receives data from the primary database.

Replication Server treats a logical database like any other database. Depending on your application, the logical database in a warm standby application may function as a database that does not participate in replication and exists solely as a warm standby backup, or the logical database may also function as a primary or a replicate database.

Comparison of Database Relationships

Usually, databases are defined as “primary” or “replicate.” In discussing warm standby applications, however, databases are also defined as “active” or “standby.”

Active and Standby vs. Primary and Destination Databases
Active and Standby Databases	Primary and Replicate Databases
The active and standby databases must be managed by the same Replication Server.	Primary and destination databases may be managed by the same or different Replication Servers.
The active and standby databases must be Adaptive Server databases.	Except where they participate in warm standby applications, primary and destination databases need not be Adaptive Server databases.
The active database has one standby database. Information is always copied from the active to the standby database.	A primary database can have one or more destination databases. Some databases contain both primary and copied data.
The use of replication definitions is optional. Subscriptions are not used.	Replication definitions and subscriptions are required for replication from a primary to a destination database.
The connection to the standby database uses the function-string class rs_default_function_class. You cannot customize function strings for this class.	The connection to a replicate database can use a function-string class in which you can customize function strings. For example, it may use a derived class that inherits function strings from rs_default_function_class.
You can switch the roles of the active and standby databases.	You cannot switch the roles of primary and replicate databases.
Client applications generally connect to the active database. (However, you can perform read-only operations at the standby database.) No mechanism is provided for switching client applications when you switch the Replication Server to the standby database.	Client applications can connect to either primary or destination database. Only primary data can be directly modified. Generally, client applications do not need to switch between primary and destination databases.
The RepAgent for the active database submits all transactions on replicated tables, including maintenance user transactions, to the Replication Server, which reproduces them in the standby database. In a warm standby application for a destination database, transactions in the active database are normally executed by the maintenance user.	In most applications, RepAgent does not submit maintenance user transactions to the Replication Server to be reproduced in destination databases. The maintenance user does not generally execute transactions in primary databases.