The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.
How to approach record consistency in an active/active XDR topology
Context
In an active/active XDR toplogy it may be desirable to have the same data in the same record between both data centers. This raises a question around what happens when the same record is updated in two different data centers at the same time. In the current Aerospike release (4.5), mechanisms to handle this are not built into the product and the latest version of the record written will persist. Generation cannot be used to manage this in this instance as XDR writes do not forward the generation when shipping the record.
On first reading, it may seem like the xdr-ship-bins parameter could be a partial solution but it is not viable. Although the initial shipment of the record would include only changed bins, if the record is relogged, the subsequent shipment will send the entire record. For this reason, it does not offer a solution even if different bins in the records are changed in each DC.
Method
Here are two potential approaches that can be used with the product in its current form to manage a need for this type of consistency in an active/active XDR topology. Both must be implemented at an application level and are described at a high level here.
Approach 1 - Key affinity
The first approach involves creating an affinity between a key and a particular data center. Clients are configured, for example, to write and update a particular key to the New York datacenter only. This ensures that the New York datacenter will always have the prime copy of that record which it then ships to other data centers. This is a relatively simple approach to implement, however it relies on clients having access to all active data centers, which may not be practical.
Approach 2 - Sets for local and XDR writes
The second approach uses two different sets in each of the data centers. The first set accepts local writes from clients, the second set accepts XDR writes. When a client reads, it attempts to read the record from both sets. If the record is found in both sets then application logic is applied to choose which record wins the conflict or whether records can be merged.
Notes
- On reading the documentation it is apparent that within Aerospike there is a
conflict-resolution-policyparameter. This does not apply to behaviour when XDR ships, it applies only to conflict resolution during migrations (data rebalancing on cluster changes) and so cannot be used here.
Applies To
Server prior to v. 5.0
Keywords
XDR CONSISTENT ACTIVE WRITE
Timestamp
02/13/2018