In a functioning Replication Server system, transactions occurring in a source database are detected by a Replication Agent and transferred to the local Replication Server, which distributes the information across LANs and WANs to Replication Servers at destination sites. These Replication Servers in turn update the target database according to the requirements of the remote client. If a network or system component fails, data in the process of being delivered is temporarily stored in queues. When the failed component returns to operation, the replication system resynchronizes copies of the data and normal replication resumes.
The primary data is the source of the data that Replication Server replicates in other databases. You “publish” data at primary sites to which Replication Servers at other sites “subscribe.” You first create a replication definition to designate the location of the primary data. The replication definition describes the structure of the table and names the database that contains the primary copy of the table. For easier management, you may collect replication definitions into publications.
The creation of a replication definition or publication does not, by itself, cause Replication Server to replicate data. You must create a subscription against the replication definition (or the publication) to instruct Replication Server to replicate the data in another database. A subscription resembles a SQL select statement. It can include a where clause to specify which rows of a table you want to replicate in the local database, allowing you to replicate only the necessary data.
Beginning with the 11.5 version of Replication Server, you can have multiple replication definitions for a primary table. Replicate tables can subscribe to different replication definitions to obtain different views of the data.
Once you have created subscriptions to replication definitions or publications, Replication Server replicates transactions to databases with subscriptions for the data.
