Replication (computing): Difference between revisions

Revision as of 10:42, 15 September 2020

Revision as of 22:38, 20 December 2020

Line 30:

* '''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 | accessdateaccess-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 | accessdateaccess-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 | archiveurlarchive-url=https://web.archive.org/web/20100209225931/http://labs.google.com/papers/chubby.html | archivedatearchive-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.

Line 36:

[[Database]] replication can be used on many [[database management system]]s (DBMS), usually with a [[master/slave (technology)|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.<ref>{{cite web|title=Conflict Resolution|url=http://www.ittia.com/html/ittia-db-docs/users-guide/replication.html#conflict-resolution|publisher=ITTIA|accessdateaccess-date=21 October 2016}}</ref> The resolution of such a conflict may be based on a timestamp of the transaction, on the hierarchy of the origin nodes or on much more complex logic, which decides consistently across all nodes.

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.<ref>{{cite web

Line 42:

| title = Measurement of the Achieved Performance Levels of the WEB Applications With Distributed Relational Database

| work = Electronics and Energetics | volume = 20 | number = 1 | page = 31{{ndash}}43

| date = April 2007 | accessdateaccess-date = 30 January 2014

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

| publisher = Facta Universitatis

Line 50:

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

| work = Internal journal of grid and utility computing | volume = 6 | number = 1 | page = 30{{ndash}}46

| date = December 2014 | accessdateaccess-date = 18 December 2014

| author1 = Mokadem Riad | author2 = Hameurlain Abdelkader

| publisher = Underscience Publisher