What dual commit is

Dual commit is the system's default functionality when an object is ingested. Dual commit is designed to prevent the loss of object data if an object's initial storage location fails before the object can be evaluated against the active ILM policy.

As soon as an object is ingested, a second copy of that object is created and distributed to a different Storage Node. When the object is matched by an ILM rule in the active policy, StorageGRID Webscale determines if the initial, dual-commit copies satisfy the placement instructions in the rule. If they do not, the object is added to the ILM evaluation queue. When the object is re-evaluated, new object copies might need to be made in different locations, and the initial dual-commit copies might need to be deleted.

If the request to create the dual-commit copies fails (for example, a network issue prevents the second initial copy from being made), the StorageGRID Webscale system does not retry and ingest fails.

Dual commit is enabled by default. If ILM rules are configured to store only one instance of replicated object data, you can specify a single-commit ingest operation to avoid unnecessarily creating and then deleting copies generated by the dual-commit ingest. For configuration information, see the instructions for implementing S3 or Swift client applications.

Note: You cannot specify a single-commit ingest operation (that is, you cannot use REDUCED_REDUNDANCY) for S3 buckets that have compliance enabled. This is to ensure that compliance requirements are satisfied (two copies of each object exist) before the object is evaluated against the active ILM policy.