Migrate data for replicating log

[Chuyen Luong]

In our system, data is replicated in the serveral servers with a replication factor. We divide log into two parts:

Part 1 includes the term, index, commit index, state. (log)

Part 2 includes the raw data.

The appendEntries request is considered as a success when the majority of nodes in cluster finishes replicating log and migrating data.

When a node is added to the system, the new node can receive the appendEntries message for replicating all log entries from leader. Because the data is replicated in the serveral servers without leader, the follower (new node) needs to be replicated part 1 from leader and migrated data (part 2) from the other follower (old node).

Which way do I need to implement:

Way 1: finish replicating part 1 and migrating part 2 in each log entry.

Way 2: finish replicating part 1 for each log entry and finish migrating data for the last entry.

Many thanks,

ChuyenLT

[yihao yang]

Sorry. I don't understand what do you mean by "Migrating Data". Can you talk more about it?

Thanks,

Yihao

在 2018年1月9日星期二 UTC-8上午4:43:16，Chuyen Luong写道：

[David B Murray]

Traditionally speaking, the “data” in each log entry is an instruction for a replicated state machine. Each node feeds the same list of instructions to its state machine in the same order, ensuring that each node will end up in the same state. If your log is [1: x=0, 2: x++, 3: y=x*2], every node eventually ends up in state {x=1, y=2}.

From this perspective, your new node needs a full copy of the “data” for each entry in the log, so it too can apply each instruction in order. Just applying ‘y=x*2’ on a brand new node isn’t enough to get in sync with the other nodes.

As the log grows, bootstrapping a new node in this way becomes less and less inefficient. To deal with this, implementations typically take periodic “snapshots” of the state machine: as of log entry 12345 the state was {x=67890, y=42, ...}. New nodes can be bootstrapped with a recent snapshot, then only need to replicate/apply log entries from that position forward, rather than replicating/applying every log entry since the beginning of time.

A special case of this, which is maybe what you’re asking about, is if the “data” in every log entry is in fact a complete snapshot of the entire state machine. This is usually much less efficient than logging only changes, so I wouldn’t necessarily recommend it. But it does mean that you should only need to pick up the “data” from the most recent log entry to bootstrap a new node.

-d

--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arthur Wang]

Hi David:

    How to log only changes in an easy-to-handle way? In my opinion, it is much more like to implement a small compiler since you need to parse the change statements which may contain not only arithmatic operations but also logic operations.   This reminds me  of something related to mysql backup strategy:log  by logic(changes only) or log by physic(raw data) , each has its own pros and cons. But for raft, I think it will incur too much complication if you do it that way. Did you know anyone who ever did it like this before？

Thanks a lot.