Re: Raft Notary


Hi Thomas,
With some minor twist of the commit command and the snapshot install, I am able to reach sync for this use case:
all 3 workers (W0, W1, W2) up -> 1 tx -> check all in sync -> stop W2 -> 1 more tx -> start W2 -> W2 got in sync

Here by "in sync", I mean all three notary tables for all three workers have the same transaction data.

I also tested the use case of adding a new worker to the cluster:
2 workers (W0, W1) up -> 1 tx -> start W2 -> Is W2 in sync?
The answer depends on clusterAddresses. If clusterAddresses include all three workers, W2 will be in sync.

So it looks like for a static cluster, we can start and stop workers and the cluster will reach sync as long as N/2 + 1 workers are always up at any given time. Of course, more tests are needed to confirm that.

But, if we just add a new worker to an existing cluster which does not know anything about the new worker, the new worker would not catch any of the previous transactions by the cluster. That is probably because the cluster already had cleaned the commit log due to FULL compaction.

To anticipate future dynamic addition of workers, it seems the cluster should not clean the commit log at all. Then what would be the implication of keeping a permanent log in terms of storage and performance?

In some deploy scenarios, the cluster size is known at the beginning by design, so we can use the static cluster configuration to ensure consistence and still enable log compaction. That again, is pending more tests.

Those are just my very preliminary observations. I am sure I have missed something important. So please advise.




Join to automatically receive all group messages.