A new epoch timestamp is generated when you either first create a new table, or when you use the &quot;emergency repair&quot; operation to manually recover from a dead Raft cluster (usually one that has lost a majority of servers).<p>The wall-clock time comes from the server that processes that query.<p>Whenever the epoch timestamp changes, replicas will get a fresh set of Raft member IDs, and it&#x27;s expected that they start with an empty Raft log.<p>Where exactly the epoch timestamps come from is not really relevant to this bug. With the bug fixed, any given node will only accept multi_table_manager_t actions that have a strictly larger epoch timestamp than what they have right now. That is enough to guarantee that they never go back to a previous configuration, and never rejoin a Raft cluster with the old member ID, but a wiped Raft log.