Configure the Replication Retry Mechanism

When an object replication fails, a retry mechanism occurs. The number of retries is set to 5 by default and can be modified.

Note

Refer to the Replication Monitoring documentation to get a status on replication failures and retries.

Replication Retry Mechanism

To configure the replication retry mechanism, follow these steps:

1. Edit the Zenko CR.

   [artesca-os@bootstrap ~]$
   

   sudo kubectl --kubeconfig /etc/kubernetes/admin.conf edit zenko artesca-data -n zenko
   

2. In the Spec section, search for backbeat: and edit replicationDataProcessor:.

   [artesca-os@bootstrap ~]$
   

   backbeat:
     replicationDataProcessor:
       retry:
         aws:
           maxRetries: 5
         azure:
           maxRetries: 5
         gcp:
           maxRetries: 5
         scality:
           maxRetries: 5
   

The retry mechanism implements random based exponential backoff for the retries to increase resiliency against intermittent issues such as network losses or backend unavailabilities.

Replication Replay Mechanism

The replication replay mechanism occurs when an object replication has failed and gone through five retries by default.

Each replay implements five retries as described above.

After each replay failure (meaning all five retries failed), the replay mechanism creates a new entry to process with the same information at the end of the queue. Therefore, the timing before the next replay depends on the current load and the object processing.

The number of replays is set to 5 by default. At the sixth failure, the status of the object is marked as FAILED in metadata.

Note

In some cases, a manual trigger is required for existing objects replication. To do so, contact Scality Support.