From 5782b4b484ee95d76076043b452438ea5ec3faff Mon Sep 17 00:00:00 2001 From: "abby.huang" <78209557+abby-cyber@users.noreply.github.com> Date: Wed, 15 Mar 2023 14:05:04 +0800 Subject: [PATCH] Update 4.storage-service.md --- .../3.nebula-graph-architecture/4.storage-service.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md b/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md index ca8178aa479..701d838a0e0 100644 --- a/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md +++ b/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md @@ -247,8 +247,8 @@ When a transfer leadership command is committed, the leader will abandon its lea To avoid split-brain, when members in a Raft Group change, an intermediate state is required. In such a state, the quorum of the old group and new group always have an overlap. Thus it prevents the old or new group from making decisions unilaterally. To make it even simpler, in his doctoral thesis Diego Ongaro suggests adding or removing a peer once to ensure the overlap between the quorum of the new group and the old group. NebulaGraph also uses this approach, except that the way to add or remove a member is different. For details, please refer to addPeer/removePeer in the Raft Part class. - +--> ## Differences with HDFS