Consistency level switching has been added to improve data availability #135

wants to merge 1 commit into


None yet
2 participants

It would be good to provide on-the fly consistency level switching on the operation level to improve data availability. Can be helpful when the replication factor 2 is used.

@maxmorozov maxmorozov Consistency level switching has been added to handle cases when amoun…
…t of live hosts is not enough to work with requeired consistency level

elandau commented Oct 31, 2012

Not sure I agree with the concept here. If you are willing at any point to reduce write consistency to 1 then you may as well just write with consistency level 1. Also, the change you propose will break the existing interface. It should be possible to set a separate policy on ConnectionPoolConfiguration and then have the existing methods reference that interface.

I'm not sure that setting consistency level to 1 is good idea in our case. We want to write our data to all available replica servers to make sure that the next read will get the actual data. If we set write consistency level to 1, we cannot reach the goal. We use replication factor 2. We use write consistency level LOCAL_QUORUM (that is equal to TWO in our case) and read consistency level ONE. If one replica server is down, we can switch to write consistency level ONE without any risk, because the next read will get data only from the single alive server. When the downed server is going up, we will get some inconsistency during short period of time but this is acceptably.

Could you please explain your thought about breaking the existing interface? What use cases can be broken? Probably, you mean that in some cases the user can change write consistency level independently from the current read consistency level, don't you?

maxmorozov closed this Nov 2, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment