Normally when an object is written to a node, the replication constraints are checked during the normal course of health checking all objects on the node. While this behavior should be acceptable for most installations, you may employ business requirements that immediately duplicate the object to another node as quickly as possible. The
ROW) option forces a second immediate copy of an object to another node. If the object includes a constraint for creating more than two copies, the additional copies are made during the normal health checking process.
During normal operations, the Health Processor automatically creates two object replicas in the background on a regular basis. Using
scsp.replicateOnWrite, all object replicas are created during the initial write. While this process may temporarily restrict client responsiveness as objects are created and replicated at the same time, your objects are protected from a single volume failure right away.
To implement Replicate On Write in your storage cluster, enable the
replicateOnWrite parameter to your configuration file. This option will replicate each object that is saved to Netmail Store. Following are are the
[SCSP] parameters that configure replication for your storage cluster.
To enable replication in your storage cluster, enable
scsp.replicateOnWrite, which is Boolean. When set to
True, Netmail Store withholds sending the write verification to the client until the number of replicas specified by the
scsp.defaultROWAction parameter (default 2) have been created successfully.
scsp.replicateOnWrite option lets you specify any explicit number of synchronous writes as part of a single request. You can enable this in the node configuration and/or as part of the request.
Note: The query arguments in the request override the node configuration.
To prevent unnecessary cleanup work for the health processor, the cluster will limit the number of synchronous replicas created for a replicate on write request to the minimum of the cluster's
scsp.maxReplicas parameter, the replica count sent with the request and any replica counts in lifepoint. This prevents the health processor from having to later trim excess replicas when all factors are considered.
scsp.defaultROWAction is a positive integer or
full (a special keyword).
Full indicates that the number of replicas is the number determined by the greater of the objects reps lifepoint or the
scsp.defaultReplicas setting for that object. The limits defined by the cluster
scsp.maxReplicas settings are enforced on the number of replicas created in a
ROW request as well. The
?replicate query argument can be used for the same purpose with the similar acceptable values.