Replication (computing): Difference between revisions

Revision as of 03:29, 28 February 2023

Revision as of 00:33, 28 March 2023

Line 32:

* '''Transactional replication''': used for replicating [[transactional data]], such as a database. The [[one-copy serializability]] model is employed, which defines valid outcomes of a transaction on replicated data in accordance with the overall [[ACID]] (atomicity, consistency, isolation, durability) properties that transactional systems seek to guarantee.

* '''[[State machine replication]]''': assumes that the replicated process is a [[deterministic finite automaton]] and that [[atomic broadcast]] of every event is possible. It is based on [[Consensus (computer science)|distributed consensus]] and has a great deal in common with the transactional replication model. This is sometimes mistakenly used as a synonym of active replication. State machine replication is usually implemented by a replicated log consisting of multiple subsequent rounds of the [[Paxos algorithm]]. This was popularized by Google's Chubby system, and is the core behind the open-source [[Keyspace (data store)|Keyspace data store]].<ref name=keyspace>{{cite web | access-date=2010-04-18 | year = 2009 | url=http://scalien.com/whitepapers |title=Keyspace: A Consistently Replicated, Highly-Available Key-Value Store | author=Marton Trencseni, Attila Gazso}}</ref><ref name=chubby>{{cite web | access-date=2010-04-18 | year=2006 | url=http://labs.google.com/papers/chubby.html | title=The Chubby Lock Service for Loosely-Coupled Distributed Systems | author=Mike Burrows | url-status=dead | archive-url=https://web.archive.org/web/20100209225931/http://labs.google.com/papers/chubby.html | archive-date=2010-02-09 }}</ref>

* '''[[Virtual synchrony]]''': involves a group of processes which cooperate to replicate in-memory data or to coordinate actions. The model defines a distributed entity called a ''process group''. A process can join a group and is provided with a checkpoint containing the current state of the data replicated by group members. Processes can then send [[multicast]]s to the group and will see incoming multicasts in the identical order. Membership changes are handled as a special multicast that delivers a new "membership view" to the processes in the group.<ref>{{Cite journal |lastlast1=Birman |firstfirst1=K. |last2=Joseph |first2=T. |date=1987-11-01 |title=Exploiting virtual synchrony in distributed systems |url=https://doi.org/10.1145/41457.37515 |journal=Proceedings of the eleventhEleventh ACM Symposium on Operating systemsSystems principlesPrinciples |series=SOSP '87 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=123–138 |doi=10.1145/41457.37515 |isbn=978-0-89791-242-6|s2cid=7739589 }}</ref>

== {{Anchor|DATABASE}}Database replication ==

Line 54:

| author1 = Dragan Simic | author2 = Srecko Ristic | author3 = Slobodan Obradovic

| publisher = Facta Universitatis

}}</ref><ref>{{cite web

| format = PDF

}}</ref><ref>{{cite web

| url = http://oatao.univ-toulouse.fr/12933/1/Mokadem_12933.pdf

| title = Data Replication Strategies with Performance Objective in Data Grid Systems: A Survey

Line 62 ⟶ 61:

| author1 = Mokadem Riad | author2 = Hameurlain Abdelkader

| publisher = Underscience Publisher

}}</ref>

| format = PDF

}}</ref>

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.

Line 134 ⟶ 132:

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).

Modern multi-primary replication protocols optimize for the common failure-free operation. Chain replication<ref>{{Cite journal |lastlast1=van Renesse |firstfirst1=Robbert |last2=Schneider |first2=Fred B. |date=2004-12-06 |title=Chain replication for supporting high throughput and availability |url=https://dl.acm.org/doi/abs/10.5555/1251254.1251261 |journal=Proceedings of the 6th conferenceConference on Symposium on Operating Systems Design & Implementation - Volume 6 |series=OSDI'04 |___location=USA |publisher=USENIX Association |pages=7 |doi=}}</ref> is a  popular family of such protocols. State-of-the-art protocol variants<ref>{{Cite journal |lastlast1=Terrace |firstfirst1=Jeff |last2=Freedman |first2=Michael J. |date=2009-06-14 |title=Object storage on CRAQ: high-throughput chain replication for read-mostly workloads |url=https://dl.acm.org/doi/abs/10.5555/1855807.1855818 |journal=USENIX Annual technicalTechnical conferenceConference |series=USENIX'09 |___location=USA |pages=11 |doi=}}</ref> of chain replication offer high throughput and strong consistency by arranging replicas in a chain for writes. This approach enables local reads on all replica nodes but has high latency for writes that must traverse multiple nodes sequentially.

A more recent multi-primary protocol, [https://hermes-protocol.com/ Hermes],<ref>{{Cite journal |lastlast1=Katsarakis |firstfirst1=Antonios |last2=Gavrielatos |first2=Vasilis |last3=Katebzadeh |first3=M.R. Siavash |last4=Joshi |first4=Arpit |last5=Dragojevic |first5=Aleksandar |last6=Grot |first6=Boris |last7=Nagarajan |first7=Vijay |date=2020-03-13 |title=Hermes: A Fast, Fault-Tolerant and Linearizable Replication Protocol |url=https://doi.org/10.1145/3373376.3378496 |journal=Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems |series=ASPLOS '20 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=201–217 |doi=10.1145/3373376.3378496 |isbn=978-1-4503-7102-5|s2cid=210921224 }}</ref> combines cache-coherent-inspired invalidations and logical timestamps to achieve strong consistency with local reads and high-performance writes from all replicas. During fault-free operation, its broadcast-based writes are non-conflicting and commit after just one multicast round-trip to replica nodes. This design results in high throughput and low latency for both reads and writes.

==See also==