[memcachedb] If only one instance out of replication group survive, it becomes read only.

[Kevin]

Hi,

I have setup 3 instances in a replication group, it works well. And
the fail over is great, but if i bring down two instances, the one
left there become read only and have the something like "Not enough
votes to elect: recvd ".

I think the 3rd instance just couldn't elect him self as master. When
i bring any other instance back, the replication resumed. Everything
looks good then.

Is anything i can adjust to make the 3rd instance become master
itself ?

The command i am using looks like :

sudo memcachedb -u memcachedb -p 21203 -d -P /home/kzhou/tmp/KVS/
21203.pid -f kvs.db -H /home/kzhou/tmp/KVS/data_slave2/ -R
127.0.1.1:31203 -O 127.0.1.1:31201 -O 127.0.1.1:31202 -n 3

- Kevin

--
You received this message because you are subscribed to the Google Groups "memcachedb" group.
To post to this group, send email to memca...@googlegroups.com.
To unsubscribe from this group, send email to memcachedb+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/memcachedb?hl=en.

[Steve Chu]

Hi, Kevin,

The election votes of master is "n/2+1 (n>2)", so according to your
case, one node becomes master until it get 2 votes. While there is
only one node here, so no one can get enough votes, and the result is
the left node became readonly. The current version memcachedb supports
failover from one node fail. So if you want change the situation, fire
a node, at lease keep the group node number 2.

The current version of BerkeleyDB HA can not change the replication
group size dynamically, so here if you want to failover from two node
failure, you should set -n 2, but you know, you should restart the
whole group. This is the limitation, I hope next version of BerkeleyDB
can resolve this.

The current memcachedb replication is based on BerkeleyDB HA.
You may refer to BerkeleyDB HA document for more info:
http://www.oracle.com/technology/documentation/berkeley-db/db/gsg_db_rep/C/index.html
http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/rep.html

Regards,

Steve

--
Best Regards,

Steve Chu
http://stvchu.org

[Kevin]

Hi Steve,

Thanks for the quick response, it's clear now. We are going to deploy
with 2 instances replication for now. Maybe will add more instance
later.

-Kevin

On Apr 19, 10:24 pm, Steve Chu <stv...@gmail.com> wrote:
> Hi, Kevin,
>
> The election votes of master is "n/2+1 (n>2)", so according to your
> case, one node becomes master until it get 2 votes. While there is
> only one node here, so no one can get enough votes, and the result is
> the left node became readonly. The current version memcachedb supports
> failover from one node fail. So if you want change the situation, fire
> a node, at lease keep the group node number 2.
>
> The current version of BerkeleyDB HA can not change the replication
> group size dynamically, so here if you want to failover from two node
> failure, you should set -n 2, but you know, you should restart the
> whole group. This is the limitation, I hope next version of BerkeleyDB
> can resolve this.
>
> The current memcachedb replication is based on BerkeleyDB HA.

> You may refer to BerkeleyDB HA document for more info:http://www.oracle.com/technology/documentation/berkeley-db/db/gsg_db_...http://www.oracle.com/technology/documentation/berkeley-db/db/program...

>
> Regards,
>
> Steve
>
>
>
>
>
> On Tue, Apr 20, 2010 at 7:42 AM, Kevin <zhouk...@gmail.com> wrote:
> > Hi,
>
> > I have setup 3 instances in a replication group, it works well. And
> > the fail over is great, but if i bring down two instances, the one
> > left there become read only and have the something like "Not enough
> > votes to elect: recvd ".
>
> > I think the 3rd instance just couldn't elect him self as master. When
> > i bring any other instance back, the replication resumed. Everything
> > looks good then.
>
> > Is anything i can adjust to make the 3rd instance become master
> > itself ?
>
> > The command i am using looks like :
>
> > sudo memcachedb -u memcachedb -p 21203 -d -P /home/kzhou/tmp/KVS/
> > 21203.pid -f kvs.db -H /home/kzhou/tmp/KVS/data_slave2/ -R
> > 127.0.1.1:31203 -O 127.0.1.1:31201 -O 127.0.1.1:31202 -n 3
>
> > - Kevin
>
> > --
> > You received this message because you are subscribed to the Google Groups "memcachedb" group.
> > To post to this group, send email to memca...@googlegroups.com.
> > To unsubscribe from this group, send email to memcachedb+...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/memcachedb?hl=en.
>
> --
> Best Regards,
>
> Steve Chuhttp://stvchu.org

>
> --
> You received this message because you are subscribed to the Google Groups "memcachedb" group.
> To post to this group, send email to memca...@googlegroups.com.
> To unsubscribe from this group, send email to memcachedb+...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/memcachedb?hl=en.