Ok??so the rpc flip-member-voting-states-for-all-shards is carried out by
shards leader automatically?
I'm not clear about that the case there is no shards leader and the rpc request
will be sent to non-voting nodes memtioned in the doc , is it means the shards
leader is down or all voting nodes are down? If only the shards leader is down,
then another voting node will be selected to leader by raft , isn't it?
another question is about how and when the shards data will be replicated to
the non-voting nodes?
Best regards,
Simpler
------------------ ???????? ------------------
??????: "Tom Pantelis";<tompante...@gmail.com>;
????????: 2017??4??19??(??????) ????9:52
??????: "????????"<609790...@qq.com>;
????: "odl"<controller-dev@lists.opendaylight.org>;
????: Re: [controller-dev] Question about Geo-distributedActive/BackupSetup in
Carbon
On Wed, Apr 19, 2017 at 6:43 AM, ???????? <609790...@qq.com> wrote:
Thanks for your reply.
"I'm not exactly sure of what you mean by "the cluster always run in only one
datacenter". You're actually setting up a 6-node cluster with 3 of them as
non-voting and acting as a backup - they are replicated to but are not needed
for consensus. "
--I'm not sure how many datacenter the 6 nodes distribute. One or two?
I'm just referring to controller nodes. The use case where we've deployed
geo-clustering is 2 3-node clusters brought together into a single 6-node
cluster with one 3-node serving as a DR backup.
--Can you tell me the difference between voting node and non-voting node?
A non-voting node is replicated to but doesn't participate in raft consensus,
ie it's not needed nor counted for consensus. It also doesn't participate in
leader elections and thus cannot become the leader. Thus a a non-voting node
is strictly a backup.
Best regards,
Simpler
------------------ ???????? ------------------
??????: "Tom Pantelis";<tompante...@gmail.com>;
????????: 2017??4??19??(??????) ????5:01
??????: "????????"<609790...@qq.com>;
????: "odl"<controller-dev@lists.opendaylight.org>;
????: Re: [controller-dev] Question about Geo-distributed Active/BackupSetup in
Carbon
On Wed, Apr 19, 2017 at 4:04 AM, ???????? <609790...@qq.com> wrote:
Hi,everyone,
I have two question about Geo-distributed Active/Backup Setup in Carbon.
1.It is said that the cluster can be expanded with nodes in a different
datacenter, but in a way that doesn??t affect latency of the primary nodes,
which I think means I can setup a backup cluster for a cluster running in
another datacenter and actully the cluster always run in only one datacenter?
I'm not exactly sure of what you mean by "the cluster always run in only one
datacenter". You're actually setting up a 6-node cluster with 3 of them as
non-voting and acting as a backup - they are replicated to but are not needed
for consensus.
2.It is mentioned that the voting state change is sent to any single
cluster node by rpc request. But after that it is said that the leader persists
the voting changes and replicates them to the remaining nodes, so the voting
state change rpc is only carried out once on any cluster node or all cluster
nodes?
You only need to send the RPC once to one node - if it's not the leader, it
will forward to the leader.
Best regards,
Simpler
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
