WRITE with Replicate ROW

The Replicate on Write (ROW) option forces Swarm to write a new object to one or more additional nodes before returning a success status. Using this content protection option, verify two or more object replicas (instances) exist in the cluster before the client write request is completed.

Success conditions for ROW

These are the success conditions for a ROW request:

• A POST on an immutable object creates at least two replicas.

• Any write operation for an alias object, or a POST for a named object.

Implementing ROW

Implement ROW in these ways:

• Globally, set the configuration file to enabling (recommended) or disabling cluster-wide ROW.

  • See Configuring Replicate On Write.

• Programmatically, use a replicate query argument when needing to override the cluster-wide ROW configuration.

• Creating or updating a bucket. The replicate=immediate option quickly invalidates cached bucket versions in the cluster so the latest version is implemented in the cluster. It also prevents subsequent permission errors because out-of-date permissions are used from the prior version.

curl -i 
	--post301 
	--data-binary '' 
	--location-trusted 'http://172.16.0.35/bucket?domain=test.example.com&replicate=immediate' 
	-D create-bucket.log

replicate argument

Add the replicate query argument to control how Swarm implements ROW on a given request.

Use this argument to limit or disable ROW for the request if cluster-wide ROW is enabled (recommended):

• replicate=x (where x is an integer) creates x replicas on write. For example, replicate=1 allows the write to succeed with one instance of the object.

Use these arguments to enable ROW for the request if cluster-wide ROW is disabled:

• replicate=immediate is replicate=2, which verifies two replicas are written.

• replicate=full is replicate={# of reps specified by lifepoint, or else policy.replicas default}

The number of replicas Swarm makes synchronously on the request cannot exceed the number of replicas specified in the lifepoint (or, if none, policy.replicas default) in every case. A request with replicate=3 causes 2 replicas to be synchronously created on the request for an object with no lifepoint specified and a cluster with default=2.

Replica-Count header

Swarm indicates the number of replica created with the request in the Replica-Count header. Check the header value in the response to verify the correct number of replicas is received.

Swarm returns an HTTP 412 Preconditioned Failed response if Swarm cannot locate at least two nodes in the cluster that can replicate the object. Swarm proceeds with the request if Swarm can locate a PAN and one ROW peer node.

A ROW request can return successfully with one replica created, it does not attempt to perform the operation if it cannot find at least two nodes up front.

Responses for replicating objects

Swarm returns an HTTP 412 Preconditioned Failed response if Swarm is replicating an object and the cluster cannot locate at least two nodes to store the replicas initially.

Swarm returns an HTTP 201 Created response if Swarm locates one node to store the replica. Applications that need to verify the requested number of created replicas should check the Replica-Count header value to verify how many replicas are created in the cluster.

Repeat the request if the requested number of replicas does not match the Replica-Count header value. The Health Processor creates the additional replicas at a later time if this condition is not met.

Swarm locates two peer nodes—including the SAN—to perform the write to POST any unnamed object. An immutable POST is considered a success if at least two replicas complete successfully when two nodes are found and the writes are initiated. The write fails and Swarm returns an HTTP 412 Preconditioned Failed response if Swarm cannot locate two peer nodes. All other writes are considered a success if at least one replica completes successfully.