Advanced Replication Guide : Advanced Replication : Principles of operation : Replication models
  
Replication models
Advanced replication supports several different data distribution models that you can tailor to meet the requirements of your application. For example, you can use a geographic or conceptual model to control how data is distributed.
The master/replica architecture of advanced replication supports various replication models. In an advanced replication setup, each computer or device has a database managed by a solidDB® server. The advanced replication functionality is included in all solidDB® server instances. Each solidDB® instance can send data to another solidDB® instance, and the receiving solidDB® instance can store the data in its database.
With advanced replication, you can decide how to divide the data and when to synchronize the data between the solidDB® instances.
Example: Replication models based on data
Identical master and replica databases
You might want every computer to have an exact copy of all of the data. For example, you might want every repair person out in the field to have a complete, up-to-date copy of the repair parts lists and prices
Partitioned replicas
You might want to partition the data to distribute different pieces of the whole to different computers. The distribution might be based on geographic responsibility. For example, the computer at headquarters might have a copy of all of the data (for example, all the customer accounts), while each local branch might keep only a copy of the data that applies to it. Or, you might want to have a rack of telecommunications line cards, each of which is responsible for handling particular connections or addresses. A single master computer keeps a complete set of connections and assigns them to individual line cards.
Example: Replication models based on synchronization frequency
Synchronizing at regular intervals
You might choose to update data at regular intervals, such as once a week, once a day, once a minute, or once every 5 seconds.
Synchronizing as soon as updates are available
You might choose to propagate updated data as soon as the change occurs, rather than according to a clock or calendar. For example, you can use the Sync Pull Notify feature to configure the master to notify replicas when there is new data that might be worth subscribing to.
Synchronizing data based on importance
You might want to propagate certain types of data (updated email addresses, for example) as soon as they are updated, while propagating other types of data (such as billing summaries) once a month.
See also
Principles of operation