Commits on Sep 5, 2022

1. fix the potential data loss for clusters with only one member …

   For a cluster with only one member, the raft always send identical
   unstable entries and committed entries to etcdserver, and etcd
   responds to the client once it finishes (actually partially) the
   applying workflow.
   
   When the client receives the response, it doesn't mean etcd has already
   successfully saved the data, including BoltDB and WAL, because:
      1. etcd commits the boltDB transaction periodically instead of on each request;
      2. etcd saves WAL entries in parallel with applying the committed entries.
   Accordingly, it may run into a situation of data loss when the etcd crashes
   immediately after responding to the client and before the boltDB and WAL
   successfully save the data to disk.
   Note that this issue can only happen for clusters with only one member.
   
   For clusters with multiple members, it isn't an issue, because etcd will
   not commit & apply the data before it being replicated to majority members.
   When the client receives the response, it means the data must have been applied.
   It further means the data must have been committed.
   Note: for clusters with multiple members, the raft will never send identical
   unstable entries and committed entries to etcdserver.
   
   Signed-off-by: Benjamin Wang <wachao@vmware.com>

   

   ahrtr authored and serathius committed Sep 5, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 7eb696d
   • Browse repository at this point

   Copy the full SHA

   7eb696d View commit details

   Browse the repository at this point in the history