This is an automated email from the ASF dual-hosted git repository.

alexey pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/kudu.git

commit 7bc5d4e415d44aca6af4acd08aaaf1cf5a6860a1
Author: Andrew Wong <[email protected]>
AuthorDate: Wed Sep 16 23:25:58 2020 -0700

    tablet: add comment to summarize the bootstrap
    
    In the few times I've had to peruse tablet bootstrapping code, I've been
    disappointed there isn't a high-level summary of what the bootstrap
    process entails with regards to WAL replay. So, I took a stab at it in
    hopes it might make the job for future readers a bit easier.
    
    Change-Id: I32d699efd97a3fdf57f47c30eded53f93f4553b7
    Reviewed-on: http://gerrit.cloudera.org:8080/16468
    Reviewed-by: Alexey Serbin <[email protected]>
    Tested-by: Kudu Jenkins
---
 src/kudu/tablet/tablet_bootstrap.cc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/kudu/tablet/tablet_bootstrap.cc 
b/src/kudu/tablet/tablet_bootstrap.cc
index e691191..298c962 100644
--- a/src/kudu/tablet/tablet_bootstrap.cc
+++ b/src/kudu/tablet/tablet_bootstrap.cc
@@ -184,6 +184,23 @@ class FlushedStoresSnapshot {
 // rest of the consensus configuration, or it can start serving the data 
itself, after it
 // has been appointed LEADER of that particular consensus configuration.
 //
+// The high-level steps to replay the WAL are as follows:
+//  for each segment in the WAL:
+//    for each entry in the segment:
+//      - If the entry is a replicate message, keep track of it and write it to
+//        the new WAL, since we may find a corresponding commit message later.
+//      - If the entry is a commit message, determine whether or not we have a
+//        corresponding replicate message in the WAL, and if so, replay the op,
+//        skipping operations whose mem-stores have been persisted to disk. If
+//        no replicate message is found, we can skip replaying the op since its
+//        mutation has been persisted to disk.
+//  for each commit message with no corresponding replicate message:
+//    - Validate that the mutated stores are non-active.
+//  for each replicate message with no corresponding commit message:
+//    - Return the replicate message as an "orphaned replicate".
+//    - When the RaftConsensus instance starts up, orphaned replicates are
+//      initialized as follower ops.
+//
 // NOTE: this does not handle pulling data from other replicas in the cluster. 
That
 // is handled by the 'TabletCopy' classes, which copy blocks and metadata 
locally
 // before invoking this local bootstrap functionality to start the tablet.

Reply via email to