search

tidwall / summitdb

In-memory NoSQL database with ACID transactions, Raft consensus, and Redis API
Other
1.41k stars 78 forks source link

What happend when a command is committed but has errors when apply it? #33

Closed joe-zxh closed 4 years ago

joe-zxh commented 4 years ago

Hi, Tidwall! This is an excellent project, but something confuses me.

Suppose there is a situation: a command is committed, but some errors happen when apply this command to the database.

SummitDB could go normally if all the raft peers have the same errors when apply the same command. But what if some raft peers behave differently to others? For example, some raft peers apply the command correctly, while others encounter some errors.(errors may be different from different peers either)

Is it neccessary to use two-phase commit or three-phase commit to deal with this problem? It seems that SummitDB just ignore this problem. (Am I correct, or I have miss something?)

Thank you, and I look forward to hearing from you.

tidwall commented 4 years ago

Raft requires that the majority of peers apply the commands to the log before the leader commits the update. This is a fundamental property of the Raft Consensus Algorithm.

joe-zxh commented 4 years ago

The majority of peers apply the commands to the log(committed), but they do not run the command in the database yet.

When the peers run the same command in the their own database, raft peers may behave differently to others. For example, a peer may encounter lack of memory(or other problems) when applying the committed command to the database, while other peers run the same command in the database successfully. Then the state of the ill peer will differ from others from now on.

SummitDB didn't consider this problem, right?

Thank you, and I look forward to hearing from you.

joe-zxh commented 4 years ago

I understand now, thanks for your help.

The replicated state machine assumption gurantees this problem would not happen: If the start states of the peers are the same, they will have the same state after executing the same command list.

TiKV also has this assumption in a single Raft group. In TiKV, the 2-phase commit mechanism is used for distributed transaction in different Raft groups. SummitDB only has one Raft group, so it do not need to consider this problem and result in a better performance.