I was reading
this thread here where the persistence of commitIndex was discussed. As far as I understand, an event is considered committed if and only if it is replicated to at least a majority of the servers.
However, this is discovered by the current leader only when it receives all the acknowledgements from the followers. This means that once an entry is committed, it can't vanish. As this is the case, shouldn't the committed index be persisted.
Not persisting it doesn't cause any problems because an `AppendEntries` RPC by the leader would settle it and if no client request does happen, then the leader can commit a no-op (as I read in the paper and here).
However, if we did persist it then a node could start up and apply up to what was globally agreed as the highest committed index as far as it knows. Now, even if this node had crashed, it's commit index is still correct because the current global commit index is >= this crashed node's commit index.
In such a case, the node wouldn't have to wait for a message from the leader to know how far it has to commit. Otherwise it has to remain idle for that period.
What do you think? Or am I missing something?