Uing XDR replication for ingestion (writes)

Hello XDR experts.

Let us take a simple XDR configurtion

DC1 and DC2

We have read and writes on both the DCs

The writes are replicated to the other DC

During the ingestion (writes) its possible that the writes may slow down the reads in that DC1

Let us take an alternative XDR configurtion

DC1 and DC2 and DC3

We have only reads from DC1 and DC2

and writes only from DC3

Replication is turned ON only for a short duration after data in written / ingested into DC3 in a small time window

Would the alternative XDR configuration help in avoiding slower reads during writes? I can compare this alternative configuration which only generates fast to merge and replicate deltas from DC3

Kind attention experts!

The XDR experts suggest it is not a good idea to turn replication on only for a short duration as that would lead to stale reads at other DCs. Moreover if there are a large volume of writes and the window to replicate is small, the system may fall back to recovery mode which is inefficient and should be avoided.

The suggestion is to confirm if the read performance is a real problem by running your workload in the 2-DC configuration.

If read performance is an issue, you may want to consider increasing the capacity of the two DCs and see if that solves the problem.

A third dedicated DC for writes may have some advantages at the cost of additional complexity of configuration and management. It may collapse some writes (depending on your workload if same keys are updated multiple times) before replicating and therefore could result in fewer overall writes to the “read” clusters.

In summary, since your workload and acceptable read performance would govern the best solution, test the potential configurations in the order of their complexity and cost.

1 Like

Thanks Neelp for the inputs, will get back on this topic as I drill down

This topic was automatically closed 84 days after the last reply. New replies are no longer allowed.

© 2021 Copyright Aerospike, Inc. | All rights reserved. Creators of the Aerospike Database.