A master database can share as much or as little data as required. A user creates publications on the master database, which are sets of data that replica databases can request. A publication is similar to a view — it is a set of data that is defined by specifying the tables that contain the data and the portions of the data that should be included.

After these publications are created, replica databases can register for (or subscribe to) those publications.

After a replica database has registered for a publication, the replica database can get refreshed data from that publication. The replica database can use parameters to request only a subset of the publication. For example, the master database might publish billing summaries for all customers. Replica databases (at branch offices) might need only the billing summaries of the branch customers. To specify the billing summaries that a replica database should receive, the replica database uses input parameters that act as search criteria for the data in the publication.

The following steps describe the process by which data is sent from a master database to a replica database:

The term push is used to describe the situation where a publisher decides when to send data to the recipient. Pull describe the situation where a recipient decides when to get data from the publisher. In solidDB Advanced Replication, the replica database pulls the data from the master database.

However, in some applications, it is important for the master database (the publisher) to send data as soon as it is updated. The solidDB Advanced Replication technology provides a Sync Pull Notify feature that enables a master database to notify replica databases when there is new data available. The Sync Pull Notify functionality provides the equivalent of push technology, but with more flexibility, see Sync Pull Notify.

With solidDB Advanced Replication, the replica database can subscribe to more than one master database. However, data from each master database must be stored in a separate catalog (logical database) in the replica database. One database catalog can contain data from only one master database. However, a single physical database can contain multiple database catalogs. Hence, a replica database can contain data from multiple master databases. One server can also contain both master and replica database catalogs.

With solidDB Advanced Replication, a subscriber can request a full or incremental download (or refresh) of information. An incremental refresh contains just the changes since the most recent refresh. Alternatively, a subscriber can request a full refresh. Replica databases in a solidDB system always start with a full download of the publication; after that, they can request only incremental refreshes if required.

Data sent from the replica database to the master database is not automatically accepted at the master database. The solidDB Intelligent Transaction capability allows the master database to reject or modify data to make sure that only valid data is stored in the master database.

You can configure the Advanced Replication system to automatically keep track of which data is new for each replica database. Furthermore, the incremental data that each replica database requires is tracked independently. A replica database that was not refreshed for a week receives changes from only the most recent week. A replica database that was refreshed an hour ago receives changes from only the most recent hour.

The following example shows an overview of the propagate and refresh process between a master database and a single replica database. The example shows what happens when two records are updated in the replica database but only one of the updates is accepted by the master database (for example, if an update is invalid according to the business rules that are enforced on the master database).