Why conflict-resolution-policy is on "generation" by default?


#1

conflict-resolution-policy seems vital for when we have counters on Aerospike and sporadically cold-restarts are required.

Since “generation” mode has a limit of 65k and then it goes back to zero passed that value, when making a cold restart of highly updated records inside Aerospike it is very likely to produce outdated records.

My question is: is there any downside on using TTL conflict-resolution-policy?

One thing I can think is that “generation” works for every namespace configuration but TTL conflict-resolution works only when the namespace has a TTL defined. But we need to change this value in our production environment, so I’d like to know if I’m missing something else.

Thanks a lot!


#2

For data with no TTL, conflict resolution will resolve on generation.

For use cases where individual records are not heavily update enough to cause generation wrap, if the cluster becomes partitioned and recovers you may not resolve the side with the most updates.

Switching to TTL based conflict resolution makes sense for you use case.


#3

Hello kporter, thanks for your quick reply.

I still don’t get my original question: is there any downside on using TTL conflict-resolution-policy?

Do you know if there is a downside of using it by default?

Thanks!


#4

Guess it wasn’t clear:


#5

Hi kporter, thanks again for your fast response!

Yes I read your comment but didn’t understand, I will be more clear now:

When you say “if the cluster becomes partitioned” what do you mean? I understand that the cluster is always partitioned, it has 4096 partitions that help in keeping load balanced the data over all nodes. Maybe what you are saying is when migrations are on?

Also, when you say “you may not resolve the side with the most updates”, specifically the word “resolve” what does it mean?

I’m sorry for asking so much, I just need to understand this so I can safely push to production.

Thanks,


#6

I mean there is a network partition (e.g. split brain) scenario where the clients can still reach all nodes. Part of the responsibility of confilict-resolution-policy is to act as a heuristic to determine which version to keep when recovering from a network partition.