Replication in computing involves sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance , or accessibility. Replication in space or in time is often linked to scheduling algorithms. Access to a replicated entity is typically uniform with access to a single non-replicated entity.
The replication itself should be transparent to an external user. In a failure scenario, a failover of replicas should be hidden as much as possible with respect to quality of service. When one master replica is designated to process all the requests, the system is using a primary-backup or master-slave scheme, which is predominant in high-availability clusters.
In comparison, if any replica can process a request and distribute a new state, the system is using a multi-primary or multi-master scheme. In the latter case, some form of distributed concurrency control must be used, such as a distributed lock manager. Load balancing differs from task replication, since it distributes a load of different computations across machines, and allows a single computation to be dropped in case of failure.
Load balancing, however, sometimes uses data replication especially multi-master replication internally, to distribute its data among machines. Backup differs from replication in that the saved copy of data remains unchanged for a long period of time. Replication is one of the oldest and most important topics in the overall area of distributed systems.
Goals of data replication
Data replication and computation replication both require processes to handle incoming events. Processes for data replication are passive and operate only to maintain the stored data, reply to read requests and apply updates. Computation replication is usually performed to provide fault-tolerance, and take over an operation if one component fails. In both cases, the underlying needs are to ensure that the replicas see the same events in equivalent orders, so that they stay in consistent states and any replica can respond to queries.
Three widely cited models exist for data replication, each having its own properties and performance:. Database replication can be used on many database management systems DBMS , usually with a master-slave relationship between the original and the copies.
The master logs the updates, which then ripple through to the slaves. Each slave outputs a message stating that it has received the update successfully, thus allowing the sending of subsequent updates. In multi-master replication , updates can be submitted to any database node, and then ripple through to other servers. This is often desired but introduces substantially increased costs and complexity which may make it impractical in some situations.
The most common challenge that exists in multi-master replication is transactional conflict prevention or resolution. Most synchronous or eager replication solutions perform conflict prevention, while asynchronous or lazy solutions have to perform conflict resolution.
For instance, if the same record is changed on two nodes simultaneously, an eager replication system would detect the conflict before confirming the commit and abort one of the transactions.
A lazy replication system would allow both transactions to commit and run a conflict resolution during re-synchronization. Database replication becomes more complex when it scales up horizontally and vertically.
Horizontal scale-up has more data replicas, while vertical scale-up has data replicas located at greater physical distances. Problems raised by horizontal scale-up can be alleviated by a multi-layer, multi-view access protocol. The early problems of vertical scale-up have largely been addressed by improving Internet reliability and performance.
When data is replicated between database servers, so that the information remains consistent throughout the database system and users cannot tell or even know which server in the DBMS they are using, the system is said to exhibit replication transparency. Active real-time storage replication is usually implemented by distributing updates of a block device to several physical hard disks.
This way, any file system supported by the operating system can be replicated without modification, as the file system code works on a level above the block device driver layer. It is implemented either in hardware in a disk array controller or in software in a device driver.
The most basic method is disk mirroring , which is typical for locally connected disks. The storage industry narrows the definitions, so mirroring is a local short-distance operation. A replication is extendable across a computer network , so that the disks can be located in physically distant locations, and the master-slave database replication model is usually applied. The purpose of replication is to prevent damage from failures or disasters that may occur in one location — or in case such events do occur, to improve the ability to recover data.
For replication, latency is the key factor because it determines either how far apart the sites can be or the type of replication that can be employed. The main characteristic of such cross-site replication is how write operations are handled, through either asynchronous or synchronous replication; synchronous replication needs to wait for the destination server's response in any write operation whereas asynchronous replication does not.
Synchronous replication guarantees "zero data loss" by the means of atomic write operations, where the write operation is not considered complete until acknowledged by both the local and remote storage.
Most applications wait for a write transaction to complete before proceeding with further work, hence overall performance decreases considerably. Inherently, performance drops proportionally to distance, as minimum latency is dictated by the speed of light. In Asynchronous replication, the write operation is considered complete as soon as local storage acknowledges it. Remote storage is updated with a small lag. Performance is greatly increased, but in case of a local storage failure, the remote storage is not guaranteed to have the current copy of data the most recent data may be lost.
Semi-synchronous replication typically considers a write operation complete when acknowledged by local storage and received or logged by the remote server. The actual remote write is performed asynchronously, resulting in better performance but remote storage will lag behind the local storage, so that there is no guarantee of durability i.
Point-in-time replication produces periodic snapshots which are replicated instead of primary storage. This is intended to replicate only the changed data instead of the entire volume. As less information is replicated using this method, replication can occur over less-expensive bandwidth links such as iSCSI or T1 instead of fiberoptic lines. Many distributed filesystems use replication to ensure fault tolerance and avoid a single point of failure.
Techniques of wide-area network WAN optimization can be applied to address the limits imposed by latency.
Data Replication in DBMS
File-based replication conducts data replication at the logical level i. There are many different ways of performing this, which almost exclusively rely on software. A kernel driver specifically a filter driver can be used to intercept calls to the filesystem functions, capturing any activity as it occurs. This uses the same type of technology that real-time active virus checkers employ. At this level, logical file operations are captured like file open, write, delete, etc.
The kernel driver transmits these commands to another process, generally over a network to a different machine, which will mimic the operations of the source machine.
Like block-level storage replication, the file-level replication allows both synchronous and asynchronous modes.
In synchronous mode, write operations on the source machine are held and not allowed to occur until the destination machine has acknowledged the successful replication. Synchronous mode is less common with file replication products although a few solutions exist. File-level replication solutions allow for informed decisions about replication based on the location and type of the file.
For example, temporary files or parts of a filesystem that hold no business value could be excluded. The data transmitted can also be more granular; if an application writes bytes, only the bytes are transmitted instead of a complete disk block generally 4, bytes.
This substantially reduces the amount of data sent from the source machine and the storage burden on the destination machine.
Drawbacks of this software-only solution include the requirement for implementation and maintenance on the operating system level, and an increased burden on the machine's processing power.
Similarly to database transaction logs , many file systems have the ability to journal their activity. The journal can be sent to another machine, either periodically or in real time by streaming.
On the replica side, the journal can be used to play back file system modifications. One of the notable implementations is Microsoft 's System Center Data Protection Manager DPM , released in , which performs periodic updates but does not offer real-time replication. This is the process of comparing the source and destination file systems and ensuring that the destination matches the source.
The key benefit is that such solutions are generally free or inexpensive. The downside is that the process of synchronizing them is quite system-intensive, and consequently this process generally runs infrequently. Another example of using replication appears in distributed shared memory systems, where many nodes of the system share the same page of memory.
Data Replication in Distributed System
This usually means that each node has a separate copy replica of this page. Many classical approaches to replication are based on a primary-backup model where one device or process has unilateral control over one or more other processes or devices. For example, the primary might perform some computation, streaming a log of updates to a backup standby process, which can then take over if the primary fails.
This approach is common for replicating databases, despite the risk that if a portion of the log is lost during a failure, the backup might not be in a state identical to the primary, and transactions could then be lost.
A weakness of primary-backup schemes is that only one is actually performing operations.
Data replication in distributed database systems pdf995
Fault-tolerance is gained, but the identical backup system doubles the costs. For this reason, starting c.
An outgrowth of this work was the emergence of schemes in which a group of replicas could cooperate, with each process acting as a backup while also handling a share of the workload. Computer scientist Jim Gray analyzed multi-primary replication schemes under the transactional model and published a widely cited paper skeptical of the approach "The Dangers of Replication and a Solution".
His solution, which is to partition the data, is only viable in situations where data actually has a natural partitioning key. In the —, the virtual synchrony model was proposed and emerged as a widely adopted standard it was used in the Isis Toolkit, Horus, Transis, Ensemble, Totem, Spread , C-Ensemble, Phoenix and Quicksilver systems, and is the basis for the CORBA fault-tolerant computing standard.
Virtual synchrony permits a multi-primary approach in which a group of processes cooperates to parallelize some aspects of request processing.
What is Data Replication?
The scheme can only be used for some forms of in-memory data, but can provide linear speedups in the size of the group. A number of modern products support similar schemes. For example, the Spread Toolkit supports this same virtual synchrony model and can be used to implement a multi-primary replication scheme; it would also be possible to use C-Ensemble or Quicksilver in this manner.
WANdisco permits active replication where every node on a network is an exact copy or replica and hence every node on the network is active at one time; this scheme is optimized for use in a wide area network WAN. From Wikipedia, the free encyclopedia. This article includes a list of references , but its sources remain unclear because it has insufficient inline citations.
Please help to improve this article by introducing more precise citations. October Learn how and when to remove this template message. Main articles: distributed fault-tolerant file systems and distributed parallel fault-tolerant file systems.
This section needs expansion. You can help by adding to it. November