A master database can share as much or as little data as it wants. A user on the master creates publications, which are sets of data that replicas can request. A publication is similar to a view — it is a set of data defined by stating the tables where the data comes from and the portions of the data that should be included.
Once these publications are created, replicas can register for those publications.
Once a replica has registered for a publication, the replica can get refreshes from that publication. The replica can use parameters to request only a subset of the publication. For example, the master might decide to publish billing summaries for all customers. Replicas (at branch offices) might want only the billing summaries of the customers that branch is responsible for. To specify which billing summaries the replica wants, the replica can provide input parameters that act as search criteria for the data of the publication.
The steps for sending data from a master to a replica are as follows:
1 Master creates a publication with specified data (for example, billing summaries of all customers).
2 Replica registers for that publication.
3 Replica requests a refresh from that publication to get all or part of the data.
The model of publish and subscribe is similar, but not identical to the way magazines are published and subscribed to. A large publishing company might sell many different monthly magazines — perhaps one on SQL, one on C, and one on Java™. The publisher decides what information to put into each issue. You do not control the content. You as a subscriber register to receive one or more of those publications. For example, you might send in your money to subscribe to an SQL magazine.
A key difference between the world of magazine publishing and the world of advanced replication synchronization is that in solidDB® synchronization, the recipient, not the publisher, decides when to get new data. In magazine publishing, the magazine company decides when to send the magazine. If you subscribe to a monthly computer magazine, the publisher sends you a magazine each month, whether or not you have time to read it. In the world of advanced replication synchronization, however, it is you the subscriber who decide when to request new data. In this way, solidDB® synchronization is similar to publishing on the web rather than publishing on paper. With web publishing, you pay the publisher, the publisher puts data on the web site whenever the publisher wants, and you visit that web site whenever you want.
The term push is used to describe the situation where the publisher decides when to send data to the recipient. Pull describe the situation where the recipient decides when to get data from the publisher. In the world of web publishing (and solidDB® synchronization), the reader pulls the data.
In some applications, it is important for the master (the publisher) to send data as soon as it is updated. The solidDB® synchronization technology provides a Sync Pull Notify feature that enables a master to notify replicas when there is new data that might be worth subscribing to. The Sync Pull Notify functionality provides the equivalent of push technology, but with more flexibility.
With solidDB® synchronization, similar to magazine publishing, the customer (the replica) can subscribe to more than one master database (more than one magazine). If you want to subscribe to three different magazines, or three different master databases, you can do so. However, data from each master must be stored in a separate catalog (logical database) in the replica. 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 server can contain data from multiple master databases. One server can also contain both master and replica database catalogs.
With solidDB® synchronization, a subscriber can request a full or incremental download (or refresh) of information. An incremental refresh contains just the changes since the most recent prior refresh — analogous to receiving the most recent issue of a magazine, or seeing only the new articles on a web site. Alternatively, a subscriber can request a full refresh — analogous to ordering the complete set of back issues for a magazine or looking at the entire current web site. Replicas in a solidDB® system always start with a full download; after that, they can request only incremental refreshes if they wish.
Tip: Although the term refresh implies that it is an update of previous data, it is used loosely to refer to the initial download as well as subsequent downloads.
Data sent from the replica to the master is not automatically accepted at the master. The solidDB®Intelligent Transaction capability allows the Master to reject or modify data to make sure that only valid data is stored in the master.
The following illustration shows an overview of the propagate and refresh process between a master and a single replica. This illustration includes an example of a record that was accepted by the master and another record that was rejected by the master (for example, because the update was invalid according to business rules enforced on the master).
Propagate and Refresh
1 Initial state
2 Full refresh
3 Anne Anderson (A) and Barry Barrymore (B) update their records and save them for later propagation.
4 Propagate updates to the Master. In this example, the master accepts Anne's change but reject's Barry's.
5 Incremental Refresh. The master sends back Anne's update, but not Barry's, because Barry's update was rejected. Barry's record is left at its last official value.
You can configure the advanced replication system to automatically keep track of which data is new for each replica; users themselves do not need to keep track of anything to request only an incremental update. Furthermore, each replica's need for incremental data is tracked independently. A replica that has not refreshed for a week will receive the most recent week's worth of changes. A replica that refreshed an hour ago will only be sent the most recent hour's worth of changes.
