Difference between revisions of "Data Replication"
Peterkelly (Talk | contribs) (→Master-Slave Replication) |
Peterkelly (Talk | contribs) (→Data Replication) |
||
| Line 6: | Line 6: | ||
====Master-Slave Replication==== | ====Master-Slave Replication==== | ||
This type of replication enables data from one Recital database server (called the master) to be published for replication for one or more Recital database servers (slaves) to subscribe. Replication is asynchronous - your replication slaves do not need to be connected permanently to receive updates published on the master. They just need to connect to the publisher when updating the subscription. Which means that updates can occur over long-distance connections and even temporary solutions such as a dial-up service. Depending on the configuration, you can replicate all databases, selected databases and even selected tables within a database. | This type of replication enables data from one Recital database server (called the master) to be published for replication for one or more Recital database servers (slaves) to subscribe. Replication is asynchronous - your replication slaves do not need to be connected permanently to receive updates published on the master. They just need to connect to the publisher when updating the subscription. Which means that updates can occur over long-distance connections and even temporary solutions such as a dial-up service. Depending on the configuration, you can replicate all databases, selected databases and even selected tables within a database. | ||
| − | === Target uses for MSR in Recital include: === | + | ===== Target uses for MSR in Recital include: ===== |
* Scale-out solutions - spreading the load among multiple slaves to improve performance. In this environment, all writes and updates must take place on the master server. Reads, however, may take place on one or more slaves. This model can improve the performance of writes (since the master is dedicated to updates), while dramatically increasing read speed across an increasing number of slaves. | * Scale-out solutions - spreading the load among multiple slaves to improve performance. In this environment, all writes and updates must take place on the master server. Reads, however, may take place on one or more slaves. This model can improve the performance of writes (since the master is dedicated to updates), while dramatically increasing read speed across an increasing number of slaves. | ||
* Data security - because data is replicated to the slave, and the slave can pause the replication process, it is possible to run backup services on the slave without corrupting the corresponding master data. | * Data security - because data is replicated to the slave, and the slave can pause the replication process, it is possible to run backup services on the slave without corrupting the corresponding master data. | ||
Revision as of 07:11, 26 October 2009
Contents
Data Replication
An Overview of Data Replication in Recital
There are two types of replication in Recital;
- Master to Slave(s); where the updates are performed on one master server and published for slaves to subscribe.
- Peer to Peer; where the updates are performed on many servers and the updates published for each server to subscribe.
Master-Slave Replication
This type of replication enables data from one Recital database server (called the master) to be published for replication for one or more Recital database servers (slaves) to subscribe. Replication is asynchronous - your replication slaves do not need to be connected permanently to receive updates published on the master. They just need to connect to the publisher when updating the subscription. Which means that updates can occur over long-distance connections and even temporary solutions such as a dial-up service. Depending on the configuration, you can replicate all databases, selected databases and even selected tables within a database.
Target uses for MSR in Recital include:
- Scale-out solutions - spreading the load among multiple slaves to improve performance. In this environment, all writes and updates must take place on the master server. Reads, however, may take place on one or more slaves. This model can improve the performance of writes (since the master is dedicated to updates), while dramatically increasing read speed across an increasing number of slaves.
- Data security - because data is replicated to the slave, and the slave can pause the replication process, it is possible to run backup services on the slave without corrupting the corresponding master data.
- Analytics - live data can be created on the master, while the analysis of the information can take place on the slave without affecting the performance of the master.
- Long-distance data distribution - if a branch office would like to work with a copy of your main data, you can use replication to create a local copy of the data for their use without requiring permanent access to the master.
Peer-Peer Replication
This type of replication enables data from one or more Recital database servers to be published for replication for one or more additional Recital database servers to subscribe. Replication is asynchronous - your replication subscription service does not need to be connected permanently to receive updates from the publication service. Which means that updates can occur over long-distance connections and even temporary solutions such as a dial-up service. Depending on the configuration, you can replicate all databases, selected databases and even selected tables within a database.
