Replication-triggering user operations

Edit online

When user configures replication on their bucket, creating new object versions / modifying existing object versions may trigger replication operations to be queued, which will then be processed asynchronously.

When that happens, an additional log field replication is populated on the HTTP access log entry for the operation that triggered the replication.

Request types

The following user-initiated requests can trigger replication:

REST.PUT.OBJECT REST.POST.OBJECT REST.POST.COMPLETE_UPLOAD REST.DELETE.OBJECT REST.PUT.OBJECT_TAGGING REST.PUT.OBJECT_TAGGING_VERSION REST.PUT.OBJECT_LOCK_RETENTION REST.PUT.OBJECT_LOCK_RETENTION_VERSION REST.PUT.OBJECT_LOCK_LEGAL_HOLD REST.PUT.OBJECT_LOCK_LEGAL_HOLD_VERSION

Table 1. Replication-triggering user operations log entry fields
Field name	Type	Required	Description
`replication.num_sync_remote_buckets`	Integer	yes	Number of destination buckets where this operation will be replicated to.
`replication.per_account_delay`	Long	yes	A potential delay applied to the triggered replication. A non-zero value implies that this replication was de-prioritized (relative to replications triggered by other accounts) as a result of having too many replications triggered by this account. Note that this delay does not translate to a delay in terms of absolute time.

Sample log

{
  ... (common access.log fields omitted)
 
  "request_type" : "REST.PUT.OBJECT",
  "replication" : {
    "num_sync_remote_buckets" : 1,
    "per_account_delay" : "0"
  },
 
  ...
}