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, you can 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 whenever you need 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 that the latest version will be 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 you have cluster-wide ROW enabled (recommended):

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

Use these arguments to enable ROW for the request if you have cluster-wide ROW 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}

In every case, 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). For example, for an object with no lifepoint specified, in a cluster with default=2, making a request with replicate=3 will still only cause 2 replicas to be synchronously created on the request.

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 a 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.

Although sometimes a ROW request can return successfully with only one replica created, it will never attempt to do the operation if it cannot find at least two nodes up front.

Responses for replicating objects

Swarm returns a 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 a 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 were created in the cluster.

If the requested number of replicas does not match the Replica-Count header value, repeat the request. Otherwise, the Health Processor will create the additional replicas at a later time.

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