XDCR Replica Write Policy Transition in Aerospike 7.3: Unresolved Consistency Trade‑offs

Goal

Diagnose deployment failures that surface in the Aerospike logs as xdcr: replica write failed entries, focusing on the impact of the use-async-write setting introduced in Aerospike 7.3.

Constraints

Logs provide timestamps for primary acknowledgments and for the completion of asynchronous replica writes but do not directly expose ordering guarantees or consistency levels. The xdcr-replica-write-policy can be set to sync or async, and the default for new namespaces is async, yet the exact durability semantics for each namespace type remain undocumented.

Uncertainty

It is unclear how enabling use-async-write interacts with namespace configuration, retry limits, and the overall consistency contract that applications can rely on when replicas are temporarily unavailable.

Questions

• How does enabling use-async-write affect the ordering guarantees between primary acknowledgments and replica updates across different namespace types?
• What consistency level can be claimed when using async mode for XDCR, and does it differ between memory‑only and persistent namespaces?
• Are there recommended thresholds for the retry limit to prevent throttling during sustained replica failures while still ensuring eventual consistency?