サーバーに格納されているエントリ、コミットされているエントリ、および適用されているエントリの違いに注意することが重要です。コミットメントは実質的に理論的な概念です。ほとんどの場合、サーバーはエントリをコミットするために何もしません。大多数のサーバーに保存されているため、失われないことが保証されています。エントリは、サーバーが順番に適用する限り、コミット時または後で適用できます。
分散システムの性質上、すべてのサーバーが同時にエントリをコミットすることは不可能です。代わりに、Raftは、リーダーがエントリをステート マシンに適用するまでに、大多数のサーバーでエントリが永続化されることのみを保証します。ほとんどの Raft 実装は、他のサーバーがコマンドをステート マシンに適用する前に、リーダーがコマンドをステート マシンに適用し、クライアントに応答できるようにするために、アプローチ #1 を採用しています。
リーダーがコマンドを適用して失敗した場合は、次のようになります。
* We know that the command has been stored on a majority of servers therefore...
* Raft's election algorithm guarantees that the next server that's elected has that entry
* When the next leader is elected, it will append a no-op entry to its log and commit it
* Once the no-op entry is committed, the leader will increase its commitIndex to that of the no-op entry and thereby commit all entries remaining from the previous term (including the original leader's last commit)
* On the next heartbeat, the leader will send the index of the no-op as the `commitIndex`
* Remaining followers will be replicated entries up to the leader's no-op and commit entries from the previous leader's term
それは理にかなっていますか?
したがって、注目すべき重要なことは、エントリーがコミットされたことをリーダーがフォロワーに通知する機会がなくても、Raft は次のリーダーが最初のリーダーのコミットされたエントリーを持つことを保証し、そのリーダーは最終的にそれらのエントリーを複製するということです。まだそれらを持っていないフォロワーに送信し、コミット インデックスは前のリーダーの最後のインデックスを超えて継続します。
参考文献:以前の条件からのエントリのコミットに関する情報については、Raft ペーパー ( https://ramcloud.atlassian.net/wiki/download/attachments/6586375/raft.pdf ) のセクション 5.4.2 を参照してください。