Hubbry Logo
Replication (computing)Replication (computing)Main
Open search
Replication (computing)
Community hub
Replication (computing)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Replication (computing)
Replication (computing)
Replication (computing)
View on Wikipedia
from Wikipedia

Replication in computing refers to maintaining multiple copies of data, processes, or resources to ensure consistency across redundant components. This fundamental technique spans databases, file systems, and distributed systems, serving to improve availability, fault-tolerance, accessibility, and performance.[1] Through replication, systems can continue operating when components fail (failover), serve requests from geographically distributed locations, and balance load across multiple machines. The challenge lies in maintaining consistency between replicas while managing the fundamental tradeoffs between data consistency, system availability, and network partition tolerance – constraints known as the CAP theorem.[2]

Terminology

[edit]

Replication in computing can refer to:

  • Data replication, where the same data is stored on multiple storage devices
  • Computation replication, where the same computing task is executed many times. Computational tasks may be:
    • Replicated in space, where tasks are executed on separate devices
    • Replicated in time, where tasks are executed repeatedly on a single device

Replication in space or in time is often linked to scheduling algorithms.[3]

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.[4]

Computer scientists further describe replication as being either:

  • Active replication, which is performed by processing the same request at every replica
  • Passive replication, which involves processing every request on a single replica and transferring the result to the other replicas

When one leader replica is designated via leader election to process all the requests, the system is using a primary-backup or primary-replica 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.[5] Replicas, on the other hand, undergo frequent updates and quickly lose any historical state. Replication is one of the oldest and most important topics in the overall area of distributed systems.

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.

Replication models in distributed systems

[edit]

Three widely cited models exist for data replication, each having its own properties and performance:

  • 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 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.[6][7]
  • 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 multicasts 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.[8]

Database replication

[edit]

Database replication involves maintaining copies of the same data on multiple machines, typically implemented through three main approaches: single-leader, multi-leader, and leaderless replication.[1]

In single-leader (also called primary/replica) replication, one database instance is designated as the leader (primary), which handles all write operations. The leader logs these updates, which then propagate to replica nodes. Each replica acknowledges receipt of updates, enabling subsequent write operations. Replicas primarily serve read requests, though they may serve stale data due to replication lag – the delay in propagating changes from the leader.

In multi-master replication (also called multi-leader), updates can be submitted to any database node, which then propagate to other servers. This approach is particularly beneficial in multi-data center deployments, where it enables local write processing while masking inter-data center network latency.[1] However, it 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 when concurrent modifications occur on different leader nodes.

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. Conflict resolution methods can include techniques like last-write-wins, application-specific logic, or merging concurrent updates.[1]

However, replication transparency can not always be achieved. When data is replicated in a database, they will be constrained by CAP theorem or PACELC theorem. In the NoSQL movement, data consistency is usually sacrificed in exchange for other more desired properties, such as availability (A), partition tolerance (P), etc. Various data consistency models have also been developed to serve as Service Level Agreement (SLA) between service providers and the users.

There are several techniques for replicating data changes between nodes:[1]

  • Statement-based replication: Write requests (such as SQL statements) are logged and transmitted to replicas for execution. This can be problematic with non-deterministic functions or statements having side effects.
  • Write-ahead log (WAL) shipping: The storage engine's low-level write-ahead log is replicated, ensuring identical data structures across nodes.
  • Logical (row-based) replication: Changes are described at the row level using a dedicated log format, providing greater flexibility and independence from storage engine internals.

Disk storage replication

[edit]
Storage replication

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 primary/replica 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. For 10 km distance, the fastest possible roundtrip takes 67 μs, whereas an entire local cached write completes in about 10–20 μs.

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.e., seamless transparency) in the case of local storage failure.[citation needed]

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.

Implementations

[edit]
Main articles: distributed fault-tolerant file systems and distributed parallel fault-tolerant file systems

Many distributed filesystems use replication to ensure fault tolerance and avoid a single point of failure.

Many commercial synchronous replication systems do not freeze when the remote replica fails or loses connection – behaviour which guarantees zero data loss – but proceed to operate locally, losing the desired zero recovery point objective.

Techniques of wide-area network (WAN) optimization can be applied to address the limits imposed by latency.

File-based replication

[edit]

File-based replication conducts data replication at the logical level (i.e., individual data files) rather than at the storage block level. There are many different ways of performing this, which almost exclusively rely on software.

Capture with a kernel driver

[edit]

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 100 bytes, only the 100 bytes are transmitted instead of a complete disk block (generally 4,096 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.

File system journal replication

[edit]

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 2005, which performs periodic updates but does not offer real-time replication.[citation needed]

Batch replication

[edit]

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.

One of the notable implementations is rsync.

Replication within file

[edit]

In a paging operating system, pages in a paging file are sometimes replicated within a track to reduce rotational latency.

In IBM's VSAM, index data are sometimes replicated within a track to reduce rotational latency.

Distributed shared memory replication

[edit]

Another example of using replication appears in distributed shared memory systems, where many nodes of the system share the same page of memory. This usually means that each node has a separate copy (replica) of this page.

Primary-backup and multi-primary replication

[edit]

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. Fault-tolerance is gained, but the identical backup system doubles the costs. For this reason, starting c. 1985, the distributed systems research community began to explore alternative methods of replicating data. 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".[9][10] He argued that unless the data splits in some natural way so that the database can be treated as n disjoint sub-databases, concurrency control conflicts will result in seriously degraded performance and the group of replicas will probably slow as a function of n. Gray suggested that the most common approaches are likely to result in degradation that scales as O(n³). His solution, which is to partition the data, is only viable in situations where data actually has a natural partitioning key.

In the 1985–1987, 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. 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).

Modern multi-primary replication protocols optimize for the common failure-free operation. Chain replication[11] is a  popular family of such protocols. State-of-the-art protocol variants[12] 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, Hermes,[13] 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

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Replication (computing)

View on Grokipedia
from Grokipedia
In computing, replication refers to the process of creating and maintaining multiple identical copies, or replicas, of , services, or computational resources across distributed nodes or systems to enhance , reliability, and . This technique is fundamental in environments such as databases, , and distributed file systems, where it mitigates risks from hardware failures, network partitions, or disasters by ensuring that no disrupts access or operations. Replication operates through various mechanisms tailored to specific contexts, including synchronous replication, where updates to all replicas occur simultaneously before a transaction completes to guarantee but at the cost of higher latency, and asynchronous replication, which propagates changes in the background for better performance while allowing for and potential data lag. In database systems, common approaches include primary-backup models, where a single primary replica handles writes and propagates them to passive backups, or multi-master setups enabling concurrent updates across active replicas, often resolved via consensus protocols like or to manage conflicts. Distributed systems extend these concepts to services and state machines, employing techniques such as active-active replication for load balancing or quorum-based voting to tolerate failures while preserving properties like or . The primary benefits of replication include improved data availability through geographic distribution, reduced recovery time objectives (RTO) and recovery point objectives (RPO) for business continuity, and enhanced scalability by distributing read workloads across replicas. However, it introduces challenges such as ensuring consistency models under the constraints of the —balancing consistency, availability, and partition tolerance—and resolving update conflicts through methods like timestamps, multi-version (MVCC), or conflict-free replicated data types (CRDTs). Applications span (e.g., Azure's geo-redundant storage), frameworks like Hadoop Distributed (HDFS) with its default three-replica policy, and high-availability clusters in enterprise environments.

Core Concepts

Definition and Purpose

In , replication is the process of maintaining multiple identical copies, known as replicas, of , resources, or services across distributed nodes to ensure continuous and resilience against failures. This technique is fundamental in distributed systems, where replicas are synchronized to varying degrees to support and performance optimization. The concept of replication originated in the 1970s amid early distributed systems research, with seminal implementations appearing in the late decade, such as the primary copy replication scheme in the distributed INGRES database system developed in 1979. These early efforts addressed the challenges of coordinating updates across multiple sites in emerging network environments, laying the groundwork for modern replication strategies. The core purposes of replication include providing via mechanisms like zero-downtime , facilitating disaster recovery through geographic across sites, enhancing by enabling load distribution such as read scaling in large-scale web services, and promoting data durability to withstand hardware or site failures. For instance, in disaster recovery scenarios, replicas stored in remote locations allow rapid restoration without data loss. Key benefits of replication are reduced access latency through localized data copies, improved by mitigating single points of failure via , and facilitation of parallel processing to handle concurrent workloads efficiently. Replication models, such as synchronous and asynchronous approaches, serve as foundational methods to realize these objectives while balancing consistency and performance trade-offs.

Key Terminology

In replication within computing, a replica refers to a copy of data, a service, or an entire system component maintained across multiple nodes to enhance availability and fault tolerance. The primary or master denotes the authoritative source of truth, where updates originate and are propagated to other copies. In contrast, secondary or backup nodes (formerly termed slave nodes) are synchronized copies that receive and apply updates from the primary to maintain consistency. Replication lag describes the temporal delay between an update on the primary and its reflection on secondary replicas, often arising from network latency or processing overhead in distributed environments. Within the broader context of distributed systems, a is the minimum number of replicas or nodes—typically a —that must acknowledge or participate in an operation to ensure agreement and progress, as formalized in consensus protocols. Partitioning involves dividing data across multiple replicas or nodes to distribute load and enable , allowing operations to target specific subsets rather than the entire . Sharding, a form of horizontal partitioning, further scales systems by assigning distinct data subsets () to separate nodes or clusters, facilitating replication within each shard for localized . Replication strategies distinguish between full replication, where complete copies of the entire dataset are maintained on all participating nodes to maximize availability, and partial replication, which duplicates only selected data fragments across nodes to optimize storage and reduce synchronization overhead. A snapshot captures a point-in-time copy of the data or state, enabling consistent replication or recovery without interrupting ongoing operations.

Replication Models

Synchronous Replication

Synchronous replication ensures that write operations in a distributed system are only confirmed to the client after all have successfully received and applied the update, thereby maintaining immediate consistency across all copies. This blocking behavior guarantees that no operation completes until to every replica is verified, preventing any in states during normal operation. The mechanism relies on atomic commitment protocols, such as the two-phase commit (2PC), where a coordinator first sends a prepare request to all replicas to vote on the transaction; only if all respond affirmatively does it proceed to the commit phase to finalize the update across the system. Consensus algorithms like , which coordinates agreement through propose-accept phases among proposers, acceptors, and learners, or , which uses leader-based log replication with heartbeat-driven synchronization, are commonly employed to implement this synchronous coordination in replicated environments. A key advantage of synchronous replication is its provision of , where all replicas reflect identical data at any given time, enabling one-copy serializability equivalent to a single non-replicated system. Additionally, it achieves zero data loss—known as recovery point objective (RPO) of zero—even during failures, as updates are durably committed everywhere before acknowledgment. However, these benefits come at the cost of increased latency from multiple network round-trips required for confirmations, which can degrade performance significantly in wide-area networks with high round-trip times, and it imposes limitations by blocking operations if any replica is unresponsive. This approach is particularly suited to use cases demanding (Atomicity, Consistency, Isolation, Durability) properties, such as financial systems where transaction logs in banking applications must remain perfectly synchronized to avoid discrepancies in account balances or trade records. For instance, banks like the Bank of New York and have deployed synchronous replication in triplexed data centers to ensure continuous and no loss of critical transaction during outages.

Asynchronous Replication

Asynchronous replication is a technique in distributed systems where updates to on a primary are propagated to secondary replicas after the primary has acknowledged the write operation to the client, without waiting for confirmation from the secondaries. This approach ensures that write operations complete quickly on the primary, with changes queued for background transmission to replicas using mechanisms such as transaction logs or message queues. In practice, updates are often batched or sent lazily post-commit, allowing the system to prioritize responsiveness while aiming for across all replicas. The primary advantage of asynchronous replication lies in its low latency for write operations, as the primary does not block on network round-trips to remote replicas, enabling high throughput in performance-sensitive environments. It also enhances , particularly in geo-distributed setups, by decoupling write acknowledgment from replica , which reduces bandwidth demands and supports larger numbers of replicas without impacting primary . However, asynchronous replication introduces risks of if the primary fails before updates reach the secondaries, as replicas may contain stale data during outages, potentially leading to recovery point objectives (RPOs) measured in seconds or more. Additionally, it provides only , where temporary inconsistencies can occur, requiring application-level handling to manage read-after-write anomalies or conflicts during propagation delays. Common use cases include content delivery networks (CDNs), where asynchronous propagation of web assets across edge servers prioritizes availability and low-latency delivery over immediate uniformity, as seen in solutions for websites. It is also prevalent in analytics databases, such as those using systems like Sybase, where freshness is secondary to large-scale queries efficiently, allowing replicas to lag without disrupting reporting workloads. For recovery after failures, techniques like log shipping involve periodically backing up and transferring transaction logs from the primary to secondaries, enabling them to apply missed updates and catch up asynchronously. (CDC) complements this by scanning database logs to identify and replicate only the deltas (inserts, updates, deletes) to lagging replicas, minimizing data transfer volume while ensuring ordered application of changes.

Primary-Backup Replication

Primary-backup replication, also known as leader-follower or master-slave replication, employs a featuring a single primary replica that handles all write operations while propagating changes to one or more read-only replicas. The primary processes client requests, updates its state, and forwards the necessary updates to before acknowledging the request, ensuring that maintain a consistent copy of the state for read queries or . This architecture provides by allowing a backup to be promoted to primary in the event of the primary's failure, minimizing downtime while centralizing writes to avoid conflicts. Changes from the primary are propagated to backups using various methods, depending on the system. Statement-based replication replays SQL statements executed on the primary, which is efficient for logging but may lead to inconsistencies with non-deterministic functions. Row-based replication transmits binary logs capturing only the affected rows, offering greater consistency and safety for complex operations but generating larger log volumes. Logical replication applies semantic changes, such as inserts, updates, or deletes in terms of table , independent of the storage engine, enabling replication across heterogeneous systems. The failover process begins with heartbeat monitoring, where the primary periodically sends "alive" messages to backups; failure to receive these within a timeout triggers detection. Leader election then promotes a backup to primary, often using quorum-based voting or atomic operations on shared storage to select the most up-to-date replica. To prevent split-brain scenarios—where multiple primaries emerge—fencing mechanisms isolate the failed primary, such as revoking its network access or storage locks, ensuring only one active primary exists. The failover time is bounded by message delivery delays, typically 2δ for f failures, where δ is the maximum message latency. This model is commonly used in traditional relational databases, such as MySQL's master-slave setups, to scale read workloads by directing queries to backups and provide through . It supports applications requiring , like solutions or geographic distribution, where replicas serve local reads without impacting the primary. Despite its simplicity, primary-backup replication creates a write bottleneck at the single primary, limiting scalability for high-write workloads. introduces delays from promotion and reconfiguration, potentially ranging from seconds to minutes in manual processes, and state transfer during catch-up can consume significant bandwidth.

Multi-Primary Replication

Multi-primary replication, also referred to as , enables multiple nodes in a distributed system to accept write operations concurrently, allowing for scalable write distribution across the cluster. This contrasts with primary-backup replication by eliminating a single point of coordination for writes, instead relying on decentralized mechanisms to handle concurrent updates. In such architectures, each node maintains a writable copy of the data, and updates are propagated asynchronously to ensure among replicas. To manage conflicts from simultaneous writes, multi-primary systems employ conflict-free replicated data types (CRDTs), which are designed to converge to a consistent state without coordination through commutative and associative operations, or last-write-wins (LWW) strategies that resolve disputes based on timestamps or version numbers. CRDTs, for instance, support operations like counters or sets that merge updates idempotently, avoiding the need for explicit locking. LWW, commonly used in key-value stores, discards older versions in favor of the most recent timestamped update, though it risks data loss if clocks skew. Synchronization in multi-primary replication typically occurs via gossip protocols, where nodes periodically exchange state summaries with randomly selected peers to propagate updates efficiently across the network, ensuring rapid dissemination without a central coordinator. Alternatively, vector clocks can track causal ordering by associating each update with a vector of node-specific timestamps, allowing replicas to detect and resolve dependencies during merges. These methods facilitate fault-tolerant propagation but require careful tuning to balance network overhead and convergence speed. The primary advantages of multi-primary replication include significantly higher write throughput, as load is distributed across multiple nodes rather than funneling through a single primary, enabling horizontal scaling for high-velocity workloads. It also supports geo-redundancy by replicating across geographically dispersed data centers, reducing latency for global users and enhancing without single points of failure, as any node can serve writes locally. However, challenges arise in conflict detection and resolution, where concurrent modifications to the same item must be identified using timestamps, versioning vectors, or operational logs, often leading to increased complexity in application logic to handle merges or rollbacks. This can result in temporary inconsistencies or the need for manual intervention in sophisticated scenarios, demanding robust versioning to prevent lost updates. Practical use cases include databases like , which implements multi-primary replication with tunable consistency levels—allowing applications to choose quorum requirements for reads and writes—and leverages LWW for resolution while supporting multi-data-center deployments for geo-distribution. Similarly, collaborative applications such as utilize techniques, akin to multi-primary principles, to enable concurrent edits across user replicas with automatic preserving user intent.

Storage Replication

Database Replication

Database replication involves synchronizing data across multiple database instances to ensure availability, , and load distribution in relational and systems. It enables by allowing to secondary instances and supports read scaling by distributing query loads. Unlike lower-level storage replication, database replication operates at the , capturing and applying changes based on database-specific mechanisms such as transaction logs or operation streams. There are three primary types of database replication: physical, logical, and snapshot-based. Physical replication creates byte-for-byte copies of the database files, the exact physical structure of the primary instance, which is efficient for identical setups but requires compatible hardware and configurations. Logical replication, in contrast, captures changes at a higher level by recording and replaying SQL statements or logical operations, allowing for differences between instances and selective replication of tables or databases. Snapshot-based replication periodically generates full copies of the database at specific points in time and applies them to replicas, suitable for infrequent updates but prone to higher latency and usage during . Common tools and protocols facilitate these types across popular databases. In , binary logs record all data modifications on the primary server, enabling asynchronous replication where replicas apply these logs to stay in sync; this position-based method supports both statement and row formats for flexibility. employs streaming replication, which continuously ships write-ahead log (WAL) segments over the network to standbys, achieving near-real-time synchronization in physical setups, while logical replication uses publication-subscription models for selective data flow. For databases like , replica sets maintain multiple data-bearing nodes that elect a primary for writes, with secondaries replicating operations via the oplog for automatic and read scaling. Replicating database schemas introduces challenges, particularly with triggers, stored procedures, and foreign keys. Triggers on replicas are typically not fired for changes originating from the primary to avoid infinite loops or redundant processing, as seen in MySQL where row-based replication skips trigger activation on slaves. Stored procedures must be identically defined across instances for logical replication to execute them correctly, or they risk inconsistencies if schemas diverge. Foreign keys often use a "NOT FOR REPLICATION" clause to defer enforcement during sync operations, preventing violations from out-of-order applies while ensuring integrity for local transactions. In multimaster environments, these elements can amplify conflicts, requiring careful design to maintain referential integrity without halting replication. Modern trends emphasize real-time and flexible synchronization. (CDC) tools like Debezium capture row-level changes from logs and stream them as events, enabling low-latency updates without full reloads and integrating with event-driven architectures. Bi-directional replication, supported by tools such as AWS Database Migration Service, allows changes in both directions for scenarios like live migrations or active-active setups, with built-in to handle concurrent updates. As of , these approaches address gaps in traditional replication by supporting hybrid integrations and reducing downtime in cloud migrations.

Disk Storage Replication

Disk storage replication involves creating redundant copies of data at the block or volume level across storage devices, ensuring and independent of higher-level s or applications. This approach operates below the file system layer, treating storage as raw blocks to provide seamless redundancy for underlying data structures. Common techniques include , where data is duplicated in real-time across multiple disks, as seen in RAID 1 configurations that maintain identical copies on paired drives to tolerate single-drive failures. Another method is striping with parity, exemplified by RAID 5, which distributes data blocks across three or more drives while computing parity information to enable reconstruction if one drive fails, balancing capacity efficiency with redundancy. Additionally, snapshot replication captures point-in-time images of volumes for versioning, allowing recovery from corruption or errors without full data duplication, as these read-only copies consume minimal additional space. Implementations of disk storage replication span software and hardware solutions. Software-based options like the Distributed Replicated Block Device (DRBD) mirror block-level data between nodes over IP networks, providing a shared-nothing replicated storage layer suitable for high-availability clusters. Hardware RAID controllers, such as those integrated into server motherboards or dedicated cards, manage mirroring and parity calculations directly on the controller, offloading processing from the host CPU for improved performance in enterprise environments. Synchronization modes determine the trade-offs in data consistency and latency. Synchronous mirroring writes data to primary and secondary storage simultaneously, achieving zero Recovery Point Objective (RPO) by ensuring no data loss upon failure, though it requires low-latency connections to avoid performance bottlenecks. In contrast, asynchronous replication first commits writes to the primary site before propagating to remote replicas, enabling use over longer distances but introducing potential data lag, with RPO measured in minutes depending on synchronization intervals. Key use cases for disk storage replication include (SAN) and (NAS) environments, where block-level redundancy supports shared access for multiple hosts in data centers. It is particularly vital for storage, allowing and without data interruption in hyper-converged infrastructures. Recent advancements, such as NVMe over Fabrics (NVMe-oF), enhance remote replication by enabling low-latency block access over Ethernet fabrics, facilitating faster synchronous mirroring across sites compared to traditional protocols. This low-level redundancy forms a foundation for higher-level mechanisms like database replication, providing resilient storage underpinnings.

File-Based Replication

File-based replication duplicates files and directories at the logical level across distributed systems, focusing on entire files including metadata to maintain structural and . This approach contrasts with lower-level storage replication by operating above the block layer, enabling features like selective and easier integration with user-space applications. It is essential for scenarios requiring , such as systems, content distribution networks, and shared storage in enterprise environments. One primary method involves kernel driver capture, where a specialized intercepts file input/output (I/O) calls to detect and propagate changes in real time. For instance, in Windows environments, the Distributed File System Replication (DFSR) service employs a filter to monitor file modifications and initiate replication without altering application behavior. This interception ensures low-latency capture of updates, though it requires kernel-level privileges and careful configuration to avoid overhead. Another method is journal-based replication, which utilizes the file system's built-in logging mechanisms to record and replay changes. In systems like ext4, the journaling layer captures metadata and data modifications in a sequential log before committing them to disk; replication tools can then transmit these journal entries to remote sites, where they are applied to a base snapshot for consistency. This technique, as demonstrated in filesystem-layer approaches for cloud computing, offers application transparency and high efficiency. Batch approaches complement real-time methods by performing periodic scans or scheduled transfers, suitable for large-scale file servers where continuous monitoring may be resource-intensive. Tools like conduct incremental by comparing file timestamps, sizes, and checksums, transferring only modified portions via a delta-encoding that computes differences on blocks within files. This enables efficient handling of massive datasets, such as daily backups, with minimal bandwidth usage even over wide-area networks. Prominent tools for file-based replication include , which supports bi-directional synchronization between replicas on different hosts or disks, propagating updates from either side while detecting conflicts for manual resolution. Unison employs compression and rsync-like optimizations for efficient delta transfers, making it resilient to network interruptions and suitable for cross-platform use without requiring access. In distributed file systems, GlusterFS facilitates replication through replicated or distributed-replicated volumes, where files are automatically duplicated across multiple storage bricks to ensure ; administrators configure replica counts (e.g., replica 2 for basic ) to balance and . Key challenges in file-based replication include managing file locks to avoid concurrent modifications leading to or loss. In multi-master setups like DFSR, the absence of distributed locking allows simultaneous edits across sites, resolved via a "last writer wins" policy that may discard earlier changes into a conflict folder, complicating recovery during outages. Efficiency is further addressed through delta mechanisms, such as block-level diffs, which minimize transfer volumes by synchronizing only altered segments rather than entire files, though this requires robust to handle partial updates accurately. By 2025, advancements in real-time file synchronization have expanded its role in collaborative tools and . Platforms like enable near-instantaneous file sharing and co-editing for distributed teams, integrating with for seamless updates across devices. In edge environments, solutions provide asynchronous near-real-time replication with delta-level efficiency, supporting low-latency data access in IoT and remote operations while reducing central dependency.

Advanced Replication Techniques

Distributed Shared Memory Replication

(DSM) systems replicate memory pages across multiple nodes to provide the illusion of a single, unified for parallel applications running on distributed hardware. In page-based DSM architectures, memory is divided into fixed-size pages that can be replicated for read access by multiple nodes, while write access is typically restricted to a single owner to maintain coherence. This replication often employs lazy release mechanisms, such as , where a node creates a local duplicate of a page upon modification without immediately propagating changes, deferring updates until points to minimize network traffic. Alternatively, eager update protocols propagate modifications immediately to all replicas upon a write, ensuring prompt coherence but at the cost of higher communication overhead, particularly in wide-area networks. Key protocols for fault-tolerant memory replication in DSM include those implemented in systems like Munin and Ivy. Munin, a software DSM developed in the early 1990s, supports fault tolerance by replicating critical state, such as data pages and metadata, across physically separated nodes, enabling recovery through checkpointing and lazy updates even after node failures. Ivy, one of the earliest page-based DSM prototypes from the late 1980s, facilitates read replication across nodes connected by a token-ring network, using sequence numbers to detect and resolve inconsistencies in replicated pages without custom hardware. These protocols track page ownership using tokens, where a write token is held by the current modifier, and invalidation or diffusion messages are sent to revoke read-only copies when ownership transfers. Consistency in DSM replication is commonly achieved through release consistency models, which relax strict sequential ordering by synchronizing updates only at explicit acquire and release operations, reducing unnecessary coherence traffic. In Munin, this model is extended with multiple protocols—such as write-invalidate for private data and diff-based updates for shared data—to optimize for different access patterns while using tokens for ownership management. Such approaches ensure that applications see a consistent view post-synchronization without requiring full , which would impose excessive latency in distributed environments. DSM replication finds primary use cases in clusters for parallel applications, such as scientific simulations that require shared access to large datasets without explicit . For instance, systems like Strings leverage DSM on clusters of symmetric multiprocessors to accelerate computations in fields like , where replicated memory pages enable efficient data sharing among nodes. Evolving from 1990s research prototypes like Ivy and Munin, which demonstrated viability on workstation networks, modern DSM integrations extend to cloud-based virtual machines, supporting scalable parallel processing in environments like private clouds with tools such as Unified Parallel C.

Replication in Cloud Environments

Replication in cloud environments leverages and to ensure data availability, durability, and performance across distributed systems, often integrating with auto-scaling and serverless architectures for dynamic workloads. providers offer built-in replication mechanisms that handle automatically, reducing operational overhead compared to traditional on-premises setups. These approaches support hybrid and multi-cloud deployments, enabling seamless data flow while addressing global latency and compliance needs as of 2025. Key strategies include cross-region replication, which copies data asynchronously between geographic regions to enhance resilience. For instance, Amazon S3 Cross-Region Replication (CRR) automatically replicates objects and their metadata across AWS regions, supporting compliance requirements and low-latency access for global applications. Similarly, Azure Blob Storage's object replication feature asynchronously copies block blobs between storage accounts in different regions, minimizing latency for disaster recovery and content distribution. In containerized environments, Kubernetes enables auto-scaling of replicas through Horizontal Pod Autoscaler (HPA), which adjusts the number of pod replicas based on metrics like CPU utilization to maintain replication during varying loads. Cloud-native tools facilitate managed replication for databases and applications. Google Cloud SQL provides read replicas for , , and SQL Server instances, allowing offloading of read traffic and to secondary instances for . Serverless options, such as functions triggered by events from services like streams or S3, enable custom replication pipelines without provisioning servers, supporting cross-account data movement for hybrid setups. Emerging trends emphasize real-time data integration across clouds. (CDC) with Kafka Connect captures database changes and streams them in real-time to topics, enabling multi-cloud synchronization through connectors like Debezium for low-latency pipelines in 2025 deployments. For IoT applications, edge-cloud synchronization replicates data from edge devices to central clouds, using protocols like CouchDB replication to ensure bidirectional updates and reduce bandwidth usage in distributed networks. Benefits of cloud replication include elastic scaling, where resources automatically adjust to demand, improving performance without over-provisioning, and built-in geo-redundancy, which distributes across regions for and quick recovery from outages. However, challenges persist, such as , where proprietary APIs complicate migrations to other providers, and high transfer costs for egress during replication across regions.

Intra-Object Replication

Intra-object replication refers to redundancy mechanisms integrated directly into individual data objects, such as files or blocks, to enhance without relying on full copies across storage nodes. These techniques embed protective data within the object itself, allowing recovery from partial losses or errors at the logical level. Unlike system-wide replication, intra-object methods focus on internal structure to optimize space and performance in distributed environments. Key techniques include erasure coding, which divides an object into data fragments and generates parity fragments using algorithms like Reed-Solomon codes to enable reconstruction from a subset of fragments. In Reed-Solomon erasure coding, for instance, an object is split into k data chunks and m parity chunks, tolerating up to m failures while requiring only k chunks for recovery. Another approach is intra-file duplication, where backup blocks or redundant segments are inserted within media files to support error correction, such as (FEC) that adds repair packets to compensate for transmission losses. In applications like systems, intra-object replication is prominently used in Ceph, where erasure-coded pools stripe objects across object storage daemons (OSDs) with integrated parity for internal . Ceph's erasure code profiles, such as the default (k=2, m=2), split objects into chunks stored on multiple OSDs, enabling efficient fault recovery without full object mirroring. This approach supports use cases in RADOS Gateway (RGW) for S3-compatible storage and extends to block () and file (CephFS) systems with partial write optimizations since the Luminous release. These methods offer significant advantages, including efficiency—erasure coding typically uses 1.5x to 2x overhead compared to 3x for full replication—while providing comparable without duplicating entire objects. They also reduce bandwidth for repairs by reconstructing only lost fragments, making them suitable for large-scale storage where full would inflate costs. Examples include video file redundancy, where FEC embeds parity data within streams to correct packet losses during network transmission, as demonstrated in techniques that maintain minimal delay for real-time playback. In database systems, binary large object (BLOB) replication applies erasure coding internally, as in Windows Azure Storage, where blobs are encoded across fragments for durability exceeding 99.999999999% (11 9s) annually without full copies. Historically, intra-object replication evolved from concepts introduced in 1988, which used parity for block-level redundancy, but adapted to logical objects in distributed systems during the to handle at scale. Seminal works like Patterson et al.'s paper laid the groundwork, transitioning to Reed-Solomon-based schemes in production object stores by the for enhanced efficiency.

Challenges and Considerations

Consistency Models

In distributed replication systems, consistency models define the guarantees provided to clients regarding the ordering and visibility of operations across replicas, ensuring synchronized data views while balancing performance and . These models range from strong to weak, with stronger models offering intuitive correctness at the cost of reduced and under failures. , the strongest model, ensures that every operation appears to take effect instantaneously at some point between its invocation and response, preserving real-time ordering as if executed on a single atomic object. relaxes this by guaranteeing that operations appear in a single consistent with each process's program order, but without real-time constraints. further weakens guarantees by preserving only the order of causally related operations—those where one depends on the result of another—while allowing independent operations to be reordered. , the weakest model, promises that if no new updates occur, all replicas will eventually converge to the same value, but intermediate reads may return stale data. Brewer's CAP theorem formalizes trade-offs in replicated systems, stating that during network partitions, a system can guarantee at most two of consistency (all reads see the latest write), (every request receives a response), and partition tolerance (the system continues despite network failures). Strong models like prioritize consistency over availability in partitions, potentially blocking operations until replicas synchronize, whereas favors availability by allowing reads from any replica, even if temporarily inconsistent. Quorum-based implementations achieve tunable consistency by requiring writes to a write quorum WW of replicas and reads from a read quorum RR, where W+R>NW + R > N (with NN as the total replicas) ensures overlap and thus consistency for recent writes. These mechanisms guide system design; for instance, Amazon DynamoDB offers tunable consistency levels, allowing users to select strongly consistent reads (reflecting all prior successful writes) or eventually consistent reads (potentially stale but faster) via configurable quorum parameters. As of 2025, research emphasizes probabilistic consistency models in AI-driven distributed systems, where multi-agent large language models use probabilistic frameworks to quantify and mitigate inconsistencies in response ordering across replicas, enhancing reliability in dynamic, inference-heavy environments.

Performance Trade-offs

Replication introduces several key performance metrics that highlight inherent trade-offs between reliability and efficiency. Latency is often increased by synchronous replication overhead, where updates must be acknowledged across replicas before committing, adding coordination delays that can extend transaction times from milliseconds to seconds depending on the number of replicas. For instance, Google's Spanner system incurs additional latency from its synchronous TrueTime-based replication to ensure across global data centers. Throughput, conversely, can improve via read replicas that offload query workloads from primary nodes, enabling parallel processing and scaling read operations; however, write throughput may suffer under synchronous modes due to blocking waits. Bandwidth consumption rises with data propagation, as change logs or full snapshots are transmitted between sites, potentially saturating networks during high-update scenarios. Network topology significantly influences these trade-offs, with local area networks (LANs) supporting low-latency synchronous replication due to minimal propagation delays, while wide area networks (WANs) favor asynchronous approaches to avoid prohibitive round-trip times. In LAN environments, replication can achieve sub-millisecond added latency, but WAN setups often see delays exceeding 100ms, necessitating optimizations to maintain viability. Replica count further amplifies costs: while more replicas enhance fault tolerance by distributing load and redundancy, they escalate synchronous coordination expenses, reducing overall throughput as seen in systems balancing isolation and performance. Eventual consistency models can mitigate latency by decoupling reads from writes, though at the expense of temporary inconsistencies. To address these challenges, optimizations like selective replication focus on "hot" data—frequently accessed items—to minimize overhead, replicating only critical subsets rather than entire datasets, which preserves query on replicas without full burdens. Compression techniques during transfers further reduce bandwidth usage; for example, applying lossless algorithms to streams can significantly reduce transmission sizes in bandwidth-constrained environments. In enterprise benchmarks, synchronous replication typically targets recovery time objectives (RTO) on the order of seconds and recovery point objectives (RPO) of zero , as demonstrated in AWS Aurora's multi-AZ deployments achieving typically under 35 seconds. Emerging 2025 technologies underscore evolving performance gaps, with NVMe storage delivering 500,000+ for read/write operations, enabling near-instantaneous local replication syncing that traditional HDDs could not match. Coupled with networks providing sub-10ms edge-to-cloud latency, these advancements facilitate low-latency distributed replication for real-time applications, reducing WAN propagation bottlenecks that previously limited asynchronous viability.

Security Implications

Replication in computing introduces several security risks due to the distribution of data across multiple nodes. One primary concern is the increased , as replicating data to additional locations expands the number of potential entry points for unauthorized access, making systems more vulnerable to breaches, particularly with sensitive stored in . Propagation channels for are susceptible to man-in-the-middle (MITM) attacks, where unencrypted network transfers allow interception or alteration of data in transit. Additionally, occurs when malicious updates are injected into one replica and propagate to others, compromising across the system, especially in distributed environments relying on consensus protocols for . To mitigate these risks, organizations employ for data in transit, such as (TLS), to protect against interception during replication over networks; mutual TLS (mTLS) further enhances this by requiring bidirectional between nodes. Integrity checks using cryptographic hashes or digital signatures verify that replicated data remains unaltered, preventing the spread of poisoned updates. These measures, while effective, can introduce overhead, such as added latency from encryption processing. Compliance with regulations like the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA) is essential for replicated data, particularly regarding locality and auditing. Under GDPR, while strict is not mandated, replication must adhere to rules for cross-border transfers, ensuring of EU residents remains protected if replicas are stored outside the , often requiring adequacy decisions or standard contractual clauses. HIPAA mandates comprehensive auditing of access to (PHI) during replication, including logs of data movements to demonstrate accountability and detect unauthorized changes, with records retained for at least six years. In modern replication pipelines as of , zero-trust models address these challenges by assuming no implicit trust among nodes, enforcing continuous verification of identities and data flows in distributed systems. This includes applying zero-trust principles to data replication through dynamic policy enforcement and monitoring, reducing risks from internal threats. Encrypted (CDC) streams exemplify this, using TLS to secure real-time change while maintaining compliance and integrity in dynamic environments.

References

  1. https://learn.microsoft.com/en-us/azure/reliability/concept-redundancy-replication-backup
  2. https://www.sciencedirect.com/topics/computer-science/replication-process
  3. https://www.sciencedirect.com/topics/computer-science/database-replication
  4. https://www.inf.usi.ch/faculty/pedone/Paper/2000/2000ICDCS.pdf
  5. https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy
  6. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
  7. https://ieeexplore.ieee.org/document/840959
  8. https://dl.acm.org/doi/abs/10.1145/61733.61738
  9. https://dl.acm.org/doi/pdf/10.1145/352515.352521
  10. https://dl.acm.org/doi/abs/10.1007/s11277-023-10240-7
  11. https://ieeexplore.ieee.org/document/7174760/
  12. https://www.geeksforgeeks.org/system-design/replication-lag-in-distributed-systems/
  13. https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf
  14. https://www.ibm.com/think/topics/data-replication
  15. https://www.vldb.org/conf/2006/p715-daudjee.pdf
  16. https://www.cs.cornell.edu/courses/cs530/2004sp/lect/Lec15.pdf
  17. https://courses.cs.washington.edu/courses/cse444/21wi/sections/section9.pdf
  18. https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
  19. https://raft.github.io/raft.pdf
  20. https://www.availabilitydigest.com/public_articles/0502/banks_use_sync_repl.pdf
  21. https://iowngf.org/wp-content/uploads/2025/05/IOWN-GF-RD-FSI_Use_Case-2.0.pdf
  22. https://clouds.cis.unimelb.edu.au/papers/DataReplicationInDSChapter2006.pdf
  23. https://sigmodrecord.org/publications/sigmodRecord/9106/pdfs/119995.115856.pdf
  24. https://ieeexplore.ieee.org/document/8011095
  25. https://learn.microsoft.com/en-us/sql/database-engine/log-shipping/log-shipping-and-replication-sql-server?view=sql-server-ver17
  26. https://www.cs.cornell.edu/fbs/publications/DSbook.c8.pdf
  27. https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/primary-backup-protocol.pdf
  28. https://dev.mysql.com/doc/refman/8.4/en/replication.html
  29. https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
  30. https://homes.cs.washington.edu/~arvind/cs425/doc/mattern89virtual.pdf
  31. https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html
  32. https://dl.acm.org/doi/pdf/10.1145/289444.289469
  33. https://www.postgresql.org/docs/current/logical-replication.html
  34. https://www.opswat.com/blog/database-replication
  35. https://dev.mysql.com/doc/refman/8.4/en/binary-log.html
  36. https://www.postgresql.org/docs/current/high-availability.html
  37. https://www.mongodb.com/docs/manual/replication/
  38. https://dev.mysql.com/doc/refman/8.2/en/stored-program-restrictions.html
  39. https://learn.microsoft.com/en-us/sql/relational-databases/replication/administration/frequently-asked-questions-for-replication-administrators?view=sql-server-ver17
  40. https://docs.oracle.com/cd/B28359_01/server.111/b28326.pdf
  41. https://debezium.io/
  42. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html
  43. https://blogs.oracle.com/dataintegration/post/bidirectional-replication-between-oracle-heatwave-mysql-instances-using-oci-goldengate
  44. https://www.techtarget.com/searchstorage/definition/disk-mirroring
  45. https://www.techtarget.com/searchstorage/definition/RAID-5-redundant-array-of-independent-disks
  46. https://docs.netapp.com/us-en/ontap/concepts/snapshot-copies-concept.html
  47. https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/
  48. https://www.dell.com/support/manuals/en-us/dell-opnmang-srvr-admin-v8.2/omss_ug-v8.1.1/raid-level-5-striping-with-distributed-parity?guid=guid-95e72fe3-1579-45b0-b6f3-7c31f4f31764&lang=en-us
  49. https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/storage-replica-overview
  50. https://www.techtarget.com/searchdatabackup/definition/asynchronous-replication
  51. https://www.netapp.com/learn/cvo-blg-nvme-vs-nvme-of-a-comparison/
  52. https://www.webopedia.com/definitions/replication/
  53. https://www.kernel.org/doc/html/latest/filesystems/ext4/journal.html
  54. https://www.redhat.com/en/blog/sync-rsync
  55. https://www.cis.upenn.edu/~bcpierce/unison/
  56. https://docs.gluster.org/en/main/Administrator-Guide/Setting-Up-Volumes/
  57. https://learn.microsoft.com/en-us/windows-server/troubleshoot/understanding-the-lack-of-distributed-file-locking-in-dfsr
  58. https://www.peersoftware.com/edge-computing-for-enterprise/
  59. https://people.cs.rutgers.edu/~pxk/rutgers/notes/content/12-dsm.pdf
  60. https://dl.mcaclash.com/ADC_Unit-3.pdf
  61. https://sites.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/DSM_protic.pdf
  62. https://www.eecg.toronto.edu/~stumm/Papers/Stumm-SDPS90.pdf
  63. https://www.cs.rice.edu/~dbj/pubs/compcon93-multi.pdf
  64. https://hjemmesider.diku.dk/~vinter/cc/Lecture11DSM.pdf
  65. https://courses.cs.duke.edu/fall98/cps212/slides-pdf/consistx2.pdf
  66. https://students.mimuw.edu.pl/SO/Wyklady-html/15_dsm/munin.pdf
  67. http://nil.csail.mit.edu/6.824/2017/papers/munin.pdf
  68. https://people.eecs.berkeley.edu/~kubitron/cs258/handouts/papers/p13-keleher.pdf
  69. https://www.sciencedirect.com/science/article/abs/pii/S0167739X0400189X
  70. https://cse.buffalo.edu/~vipin/papers/1998/1998_2.pdf
  71. https://space.pitt.edu/sites/default/files/2024-10/Anbar_CCGRID12a.pdf
  72. https://dl.acm.org/doi/10.1145/3708994
  73. https://www.usenix.org/system/files/login/articles/10_plank-online.pdf
  74. https://ftp.cs.wpi.edu/pub/techreports/pdf/99-18.pdf
  75. https://docs.ceph.com/en/reef/rados/operations/erasure-code/
  76. https://ceph.io/en/news/blog/2017/new-luminous-erasure-coding-rbd-cephfs/
  77. https://docs.netapp.com/us-en/storagegrid/ilm/advantages-disadvantages-and-requirements-for-ec.html
  78. https://www.usenix.org/system/files/conference/atc12/atc12-final181_0.pdf
  79. https://www.cs.princeton.edu/courses/archive/fall22/cos418/docs/L14-consistency.pdf
  80. https://dl.acm.org/doi/10.1145/78969.78972
  81. https://lamport.azurewebsites.net/pubs/lamport-how-to-make.pdf
  82. https://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/p172-terry.pdf
  83. https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
  84. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
  85. https://arxiv.org/pdf/2504.07303
  86. https://docs.oracle.com/cd/E19656-01/821-1504/bcari/index.html
  87. https://www.pgedge.com/blog/understanding-and-reducing-postgresql-replication-lag
  88. https://stormatics.tech/blogs/understanding-factors-impacting-data-replication-latency-in-postgresql-across-geographically-distributed-nodes
  89. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts-failover.html
  90. https://www.enterprisestorageforum.com/hardware/how-fast-are-nvme-speeds/
  91. https://www.integrate.io/blog/database-replication-speed-metrics/
  92. https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.8023.pdf
  93. https://ieeexplore.ieee.org/document/11121165
  94. https://learn.microsoft.com/en-us/sql/relational-databases/replication/security/threat-and-vulnerability-mitigation-replication?view=sql-server-ver17
  95. https://techgdpr.com/blog/server-location-gdpr/
  96. https://www.kiteworks.com/hipaa-compliance/hipaa-audit-log-requirements/
  97. https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf
  98. https://www.ibm.com/docs/en/idr/11.4.0?topic=requirements-cdc-replication-security-primer
Add your contribution
Related Hubs
User Avatar
No comments yet.