You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When thinking about how to implement quorum clustering for BonsaiDb, there are a few approaches. One way to achieve higher throughput is by allowing all nodes to act as leaders, not just one. The problem is that if two leaders execute transactions that update the same documents twice to two different values in different orders, chaos ensues.
The fix is to either make transactions always execute in the same order (thus essentially having a single leader), or it's to execute everything in parallel, but place nodes that ended up getting out of the majority-agreed order into a repair-state.
This repair mode will need to roll back the documents tree to a previous transaction ID. In Nebari, this needs to be supported at the Roots level, integrated with the TransactionManager to update the actual transaction log on-disk.
The text was updated successfully, but these errors were encountered:
When thinking about how to implement quorum clustering for BonsaiDb, there are a few approaches. One way to achieve higher throughput is by allowing all nodes to act as leaders, not just one. The problem is that if two leaders execute transactions that update the same documents twice to two different values in different orders, chaos ensues.
The fix is to either make transactions always execute in the same order (thus essentially having a single leader), or it's to execute everything in parallel, but place nodes that ended up getting out of the majority-agreed order into a repair-state.
This repair mode will need to roll back the documents tree to a previous transaction ID. In Nebari, this needs to be supported at the
Roots
level, integrated with theTransactionManager
to update the actual transaction log on-disk.The text was updated successfully, but these errors were encountered: