GotDotNet community for collaboration on this pattern
Complete List of patterns & practices
You are about to design a replication building block with a source and a target that meet the following requirements:
How do you design the replication building block to transmit data from the source to the target and apply appropriate overwrite rules on the target?
Any of the following compelling forces would justify using the solution described in this pattern:
The following enabling forces facilitate the move to the solution, and their absence may hinder such a move:
Copy data from the source to the target without regard to updates that may have occurred to the replication set at the target since the last replication.
Master-Slave Replication uses a single replication building block, as shown in Figure 1.
Figure 1: Master-Slave Replication
The replication link reads the data or its changes from the source, manipulates them for the target structure, and then writes them to the target.
The source database contains the replication set to be copied.
The Acquire service reads the contents of the replication set from the source to get the data to be transmitted. The source is either the data itself or a log of its changes. A replication that transmits only the changes is called an incremental replication. A replication that transmits the entire replication set on every transmission is called a snapshot replication. For a detailed description, see the corresponding patterns.
Hint: Acquiring only the changes is preferred when the following conditions are true:
The average number of changes during a transmission interval is relatively small compared to the size of the replication set. Appropriate means to detect or record the changes on the source are present or can be implemented.
If these conditions are not true, transmission of the entire replication set is preferred.
The Manipulate service receives the data or its changes from Acquire. It can manipulate the data by performing operations on the fields of the current row, and then assigning the result to an output field.
Typical uses of such operations are:
The resulting rows of Manipulate are used by the Write services to update the target database in one of the following manners:
Hint:Master-Slave Cascading Replication is the typical deployment of Master-Slave Replication.
The target is the database, where the transmitted and possibly manipulated data or changes are written.
Hint: You must ensure that the data is written to the target without side effects, such as double updates due to referential integrity. Hence, the target database must not fire any follow-up operations, such as triggers or cascade deletes, during the replication (if the transmission from the source includes those changes as part of its change information). However, if you need referential integrity or triggers for application updates that affect the replication set, you must prevent the replication from triggering these operations. You can achieve this, for example, by using a dedicated user or role for the transmission and by implementing the triggered operations so that they do not perform follow-up operations for the given user or role.
The following paragraphs show two examples of Master-Slave Replication. The first example deals with slow network connections and the second one shows how to divide operational and reporting databases.
Remote Read-Only Access Across a Low Bandwidth Connection
Some of your applications need read-only access to the data, but the network connection does not have enough bandwidth capacity to meet the required response times for user queries.
The solution is to replicate the database to a server in a network segment that can provide a higher bandwidth service for these applications. Because the applications only read the data, a master-slave replication will keep the target up-to-date. The replication should be designed as an incremental replication that transmits the changes from the source to the target as soon as possible.
The Master-Slave Transactional Incremental Replication pattern presents the design of such a particular master-slave replication.
Operational Database and Reporting Database
You have an operational database with ongoing updates by applications, and you need a stable view on last day's state of the database for reporting purposes. You decided to have two separated databases, one for the ongoing operations and one for reporting.
Master-Slave Replication allows you to transmit the data from the operational database to the reporting database every night. On the following day, the reporting database reflects the state of the operational database of the previous day. It will not change until the next transmission.
The transmission from the source to the target can be done with snapshots if the time period reserved for the transmission is sufficient to extract the snapshot from the source and to transfer it and write it to the target. The design of Snapshot Replication is presented in its own pattern.
Because of the nature of a master-slave replication, changes to the target that have been made by applications exist until they are overwritten by a later transmission. If the replication only transmits the changes from the source, local changes on the target might remain even after a transmission. This occurs if the corresponding data has not been changed on the source, and thus the data is not transmitted and does not replace any data on the target.
After you decide to apply the Master-Slave Replication pattern, the following considerations will lead you to a more detailed design:
The use of this pattern inherits the benefits and liabilities from Data Replication and has the following additional benefits and liabilities:
For more information, see the following related patterns:
Patterns That May Have Led You Here
Patterns That You Can Use Next
Other Patterns of Interest