Replication

<aside> 💡 Replication is the process of keeping a copy of data in more than one site or node.

</aside>

A node that has a copy of data is called replica.

There are two primary reasons for replicating data.

1. Data are replicated to increase the reliability of a system.

   • If a file system has been replicated it may be possible to continue working after one replica crashes by simply switching to one of the other replicas.
   • By maintaining multiple copies, it becomes possible to provide better protection against corrupted data.

2. Data are replicated for better performance.

   Replication for performance is important when a distributed system needs to scale in terms of size or in terms of the geographical area it covers.

   • Scaling with respect to size occurs, for example, when an increasing number of processes needs to access data that are managed by a single server. In that case, performance can be improved by replicating the server and subsequently dividing the workload among the processes accessing the data.
   • Scaling with respect to a geographical area may also require replication. The basic idea is that by placing a copy of data in proximity of the process using them, the time to access the data decreases. As a consequence, the performance as perceived by that process increases. Although a client process may perceive better performance, it may also be the case that more network bandwidth is now consumed keeping all replicas up to date.

Problems of replication

• N times more storage
• Much more network bandwidth
• Replication improves reliability and performance but having multiple copies may lead to consistency problems.
  • When one copy is modified→others needs to be updated
  • Even more difficult when replicas are physically far from each other

Strong consistency

A replicated storage system is strongly consistent if clients can’t tell that it’s replicated. E.g., clients should think that there’s only one data storage system(even though, under the hood, there could be multipl+ing together).

Primary Backup Replication

Write operations

• Performed through primary replica
• Primary multicast the update and waits for ACK from all backup replicas
• When last ACK is received, primary commits the update, and sends ACK to client

Read operators

• Read operations are performed by the primary alone
• No need to multicast read request to backup replicas

Advantages & disadvantages of Primary Backup replication

Advantages

• Client process is sure that update is backed up by several backups→fault-tolerant
• All incoming writes are globally ordered

Disadvantages

• Client may be blocked for long time
• Response time depends on longest RTT between Primary and backups
• Scaling in terms of size? (under high load, primary→performance bottleneck)
• Scaling in terms of geo. area? (always need to write/read through primary→not provided)

Chain Replication

Write operations

• Head replica in chain receives the update, performs local update and passes the update to the next replica in chain
• Tail replica in chain updates local copy and send ACK to the client