Hi, we use foundationDB as our storage server for multiple clients.
In our system, each client access a private range of keys. If one
client failed, system may create a new client for that range, or
choose an idle client for that range.
If the failed client accidentally access fdb again, it may overwrite
changes made by the new client, then cause data consistency problem
(knows as split-brain).
To prevent this happens, we want to implement some kind of fencing
in fdb. After search and learn, we came up with 2 options:
Make a fencing key, and check if it’value has changed in every write txn.
Once replaced a client, update that fencing key to disable the failed client.
This will work, but it may reduce write performance (maybe not so much?)
because there is no server side value check in fdb, have to read it’s
value to the client to check it.
Also make a fencing key, then, in the write txn:
- set txn’s read version to the “right version” of the fencing key
- add fencing key as read conflict key
- do write…
The “right version” is the read version that make sure the fencing key’s
value is unchanged.
To use conflict key, it may have very little performance impact. But to
fix transaction_too_old error, we have to refresh the “right version” often enough.
(Learn from Block device layer, thanks a lot.)
Are there any problems with either method? Are there other, better ways to do it?