In most of this book, databases are defined as “primary” or “replicate.” In discussing warm standby applications, however, databases are also defined as “active” or “standby.” Table 3-1 explains the difference.
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. |