| Table of Contents |
|---|
...
While this creates the best balance of throughput and fault tolerance in most circumstances, there are cases where you might may want to provide the replication task the same priority as reads and writes, which guarantees replication occurs quickly even under heavy sustained loads.
...
With replication set to priority 1, object replication is interleaved in parallel with other operations. This might may have a negative impact on cluster throughput for use cases involving sustained, heavy writes. With health.replicationPriority = 1, it is still possible (though much less likely) that the failure of a node or volume can cause some recently written objects to be lost if the failure occurs immediately after a write operation but before replication to another node can be completed.
...
Without ROW, the client writes a single copy and depends on the Health Processor (HP) to create the necessary replicas. Relying on HP leaves open a small window for data loss: the volume containing the node holding the sole copy can fail before HP completes replication. ROW eliminates the window by guaranteeing all replicas are written on the initial request.
How it works: The ROW feature requires Swarm to create replicas in parallel before it returns a success response to the client. ROW protection applies to WRITE, UPDATE, COPY, and APPEND requests. The secondary access node (SAN) sets up connections to the number of available peers required to create the needed replicas when ROW is enabled.
...