Re: Zab Failure scenario

[Alexander Shraer]

A reconfiguration is treated similarly to other proposals for recovery
purposes (of course commit is different
in that it changes the configuration). You can see the paper

for details on how recovery works in principle, and if you have a specific
question please feel free to ask.

On Mon, Sep 28, 2015 at 10:54 AM, Ibrahim El-sanosi (PGR) <
i.s.el-san...@newcastle.ac.uk> wrote:

> Yes, I am thinking of mixing an in-flight reconfiguration request with the
> crashing servers example that you gave Not about how proposals, acks,
> commits (i.e.: ZAB proper) work.
>
> Thank you
>
> -Original Message-
> From: Raúl Gutiérrez Segalés [mailto:r...@itevenworks.net]
> Sent: Monday, September 28, 2015 02:56 ص
> To: user@zookeeper.apache.org
> Subject: Re: Zab Failure scenario
>
> On 27 September 2015 at 10:12, Ibrahim El-sanosi (PGR) <
> i.s.el-san...@newcastle.ac.uk> wrote:
>
> > Thank you Flavio for explanation. It really makes sense for me.
> >
> > > I'm not sure why you are assuming 3.4.6,  though. Why is it relevant
> > > for
> > this question?
> >
> > I am assuming 3.4.6 because first I use this version, second I do not
> > know about dynamic configuration 3.5.0 as it may have different
> > solution for mentioned scenario.
> >
>
> I don't think dynamic reconfiguration changes anything about how
> proposals, acks, commits (i.e.: ZAB proper) work. Unless you are thinking
> of mixing an in-flight reconfiguration request with the crashing servers
> example that you gave
>
>
> -rgs
>

Re: [ANNOUNCE] New committer: Chris Nauroth

[Rakesh Radhakrishnan]

Welcome Chris, thanks for all your great work and congrats!

-Rakesh

On Mon, Sep 28, 2015 at 8:11 PM, Flavio Junqueira  wrote:

> The Apache ZooKeeper PMC is pleased to announce that Chris Nauroth has
> accepted to become a committer. Chris has been a great contributor and very
> active in the community.
>
> Congrats, Chris!
>
> -Flavio

Re: [ANNOUNCE] New committer: Chris Nauroth

[Edward Ribeiro]

Congratulations, Chris!!!

Best,
Edward
Em 28/09/2015 14:12, "Alexander Shraer"  escreveu:

> Congrats Chris, and welcome!
>
> On Mon, Sep 28, 2015 at 9:52 AM, Rakesh Radhakrishnan <
> rakeshr.apa...@gmail.com> wrote:
>
> > Welcome Chris, thanks for all your great work and congrats!
> >
> > -Rakesh
> >
> > On Mon, Sep 28, 2015 at 8:11 PM, Flavio Junqueira 
> wrote:
> >
> > > The Apache ZooKeeper PMC is pleased to announce that Chris Nauroth has
> > > accepted to become a committer. Chris has been a great contributor and
> > very
> > > active in the community.
> > >
> > > Congrats, Chris!
> > >
> > > -Flavio
> >
>

Re: 3-server Zab cluster

[Alexander Shraer]

Committing locally when sending an ACK at a server would lead to loss of
consistency - it is possible that this is the only
server that acks, e.g., this server is temporarily disconnected from the
leader, the leader gets re-elected and the operation is truncated from logs
at other servers. Its ok to ACK it but its not ok to commit since this
exposes this to users as a committed operation that they can see.

On Mon, Sep 28, 2015 at 4:19 AM, Ibrahim El-sanosi (PGR) <
i.s.el-san...@newcastle.ac.uk> wrote:

> In Zab, assume we have a cluster consists of 3-servers. To deliver a write
> request, it must run 3 communication steps proposal, acknowledgement and
> commit.
> As Zab uses reliable FIFO, it is possible to remove commit round. As soon
> as a follower receives a proposal, it logs, sends an ACK and commits
> locally. Upon receiving ACK from any follower, leader commits a proposal
> locally, no COMMIT message need to be sent to followers. In this case, all
> servers commit a proposal in two round-trips, resulting in reducing latency
> particularly in followers.
>
> Note that this optimization can only work in 3-servers cluster (follower
> reaches a majority as soon as it acks).
> Does anyone see any problems with such (small) optimization?
> Ibrahim
>

Re: [ANNOUNCE] New committer: Chris Nauroth

[Alexander Shraer]

Congrats Chris, and welcome!

On Mon, Sep 28, 2015 at 9:52 AM, Rakesh Radhakrishnan <
rakeshr.apa...@gmail.com> wrote:

> Welcome Chris, thanks for all your great work and congrats!
>
> -Rakesh
>
> On Mon, Sep 28, 2015 at 8:11 PM, Flavio Junqueira  wrote:
>
> > The Apache ZooKeeper PMC is pleased to announce that Chris Nauroth has
> > accepted to become a committer. Chris has been a great contributor and
> very
> > active in the community.
> >
> > Congrats, Chris!
> >
> > -Flavio
>

RE: Zab Failure scenario

[Ibrahim El-sanosi (PGR)]

Yes, I am thinking of mixing an in-flight reconfiguration request with the 
crashing servers example that you gave Not about how proposals, acks, 
commits (i.e.: ZAB proper) work.

Thank you

-Original Message-
From: Raúl Gutiérrez Segalés [mailto:r...@itevenworks.net] 
Sent: Monday, September 28, 2015 02:56 ص
To: user@zookeeper.apache.org
Subject: Re: Zab Failure scenario

On 27 September 2015 at 10:12, Ibrahim El-sanosi (PGR) < 
i.s.el-san...@newcastle.ac.uk> wrote:

> Thank you Flavio for explanation. It really makes sense for me.
>
> > I'm not sure why you are assuming 3.4.6,  though. Why is it relevant 
> > for
> this question?
>
> I am assuming 3.4.6 because first I use this version, second I do not 
> know about dynamic configuration 3.5.0 as it may have different 
> solution for mentioned scenario.
>

I don't think dynamic reconfiguration changes anything about how proposals, 
acks, commits (i.e.: ZAB proper) work. Unless you are thinking of mixing an 
in-flight reconfiguration request with the crashing servers example that you 
gave


-rgs

Re: [ANNOUNCE] New committer: Chris Nauroth

[Arshad Mohammad]

Congratulations  Chris Nauroth!  Well deserved

Best Regards
Mohammad Arshad

On Tue, Sep 29, 2015 at 12:56 AM, Edward Ribeiro 
wrote:

> Congratulations, Chris!!!
>
> Best,
> Edward
> Em 28/09/2015 14:12, "Alexander Shraer"  escreveu:
>
> > Congrats Chris, and welcome!
> >
> > On Mon, Sep 28, 2015 at 9:52 AM, Rakesh Radhakrishnan <
> > rakeshr.apa...@gmail.com> wrote:
> >
> > > Welcome Chris, thanks for all your great work and congrats!
> > >
> > > -Rakesh
> > >
> > > On Mon, Sep 28, 2015 at 8:11 PM, Flavio Junqueira 
> > wrote:
> > >
> > > > The Apache ZooKeeper PMC is pleased to announce that Chris Nauroth
> has
> > > > accepted to become a committer. Chris has been a great contributor
> and
> > > very
> > > > active in the community.
> > > >
> > > > Congrats, Chris!
> > > >
> > > > -Flavio
> > >
> >
>

RE: zk will not cluster

[William Hargrove]

Is there a firewall between those two networks (104.236 and 192.241)?

-Original Message-
From: David Montgomery [mailto:davidmontgom...@gmail.com]
Sent: 28 September 2015 15:21
To: user@zookeeper.apache.org
Subject: zk will not cluster

Hi,

I cant cluster three nodes.  They all are standalone.

Here is the zoo.cgf for each

the myid for each is 1,2,3

myid is located in /var/lib/zookeeper/myid


  tickTime=3000
  initLimit=10
  syncLimit=5
  dataDir=/var/lib/zookeeper
  clientPort=2181
  server.1=104.236.xxx:2888:3888
  server.2=104.236.xxx:2888:3888
  server.3=192.241.xxx:2888:3888

Here is how I start

/var/zookeeper-3.4.6/bin/zkServer.sh start-foreground

So why will zk not cluster?

Thanks
The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44(020 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusion (etc) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG is a trading name of IG Markets Limited (a company registered in England 
and Wales, company number 04008957) and IG Index Limited (a company registered 
in England and Wales, company number 01190902). Registered address at Cannon 
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets Limited 
(register number 195355) and IG Index Limited (register number 114059) are 
authorised and regulated by the Financial Conduct Authority.

zk will not cluster

[David Montgomery]

Hi,

I cant cluster three nodes.  They all are standalone.

Here is the zoo.cgf for each

the myid for each is 1,2,3

myid is located in /var/lib/zookeeper/myid


  tickTime=3000
  initLimit=10
  syncLimit=5
  dataDir=/var/lib/zookeeper
  clientPort=2181
  server.1=104.236.xxx:2888:3888
  server.2=104.236.xxx:2888:3888
  server.3=192.241.xxx:2888:3888

Here is how I start

/var/zookeeper-3.4.6/bin/zkServer.sh start-foreground

So why will zk not cluster?

Thanks

Re: Can not setAcl a znode

[Tao Xiao]

Thanks to Raúl Gutiérrez Segalés
, it really
works.
By the way, do you know how to solve this ZooKeeper-and-Kerberos-related
problem

?

Thanks very much.

2015-09-28 11:23 GMT+08:00 Raúl Gutiérrez Segalés :

> On 27 September 2015 at 19:37, Tao Xiao  wrote:
>
> > I'm using CDH 5.3, which has ZooKeeper 3.4.5 in it. I configured Kerberos
> > for the CDH cluster and later disabled Kerberos because of some problems.
> >
> > After disabling Kerberos I tried restarting the cluster but the HBase
> > Master failed to start. I checked the log and found it reported the
> > following exception:
> >
> > baseZNode=/hbase Unable to get data of znode
> >
> >
> /hbase/splitWAL/WALs%2Fhadoop3.com%2C60020%2C1442886930815-splitting%2Fhadoop3.com%252C60020%252C1442886930815.1442886937853.meta
> >
> >
> > org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode
> > = NoAuth for
> >
> /hbase/splitWAL/WALs%2Fhadoop3.com%2C60020%2C1442886930815-splitting%2Fhadoop3.com%252C60020%252C1442886930815.1442886937853.meta
> >
> >
> > I checked the ACL of the znode above using the following command:
> >
> > getACl 
> >
> >
> > The result is:
> >'sasl,'hbase
> >
> > : cdrwa
> >
> > I tried to setAcl that znode and use the following command:
> >
> > setAcl world:anyone:cdrwa
> >
> > but failed with the message of "Authentication is not valid" .
> >
> >
> > So it must be a permission related problem.
> > How can I authenticate myself and then change the permission of that
> znode
> > so that HBase master can get data of it ?
> > Or how can I remove its current privilege and make it accessible by
> anyone
> > in the world?
> >
> > Thanks.
> >
>
> You can enable the super user (i.e.: admin). If you start the servers with
> zookeeper.DigestAuthenticationProvider.superDigest, see:
>
> http://zookeeper.apache.org/doc/r3.4.5/zookeeperAdmin.html
>
> Once that's enabled, you can do something like (the example is for
> zk-shell: https://github.com/rgs1/zk_shell):
>
> $ zk-shell server:2181
> (CONNECTED) /> add_auth digest super:s3cr3t
> (CONNECTED) /> set_acls /the/path 'world:anyone:crdwa'
>
>
> -rgs
>

Re: zk will not cluster

[David Montgomery]

No all have full access using ufw.

Thanks

On Mon, Sep 28, 2015 at 10:23 PM, William Hargrove 
wrote:

> Is there a firewall between those two networks (104.236 and 192.241)?
>
> -Original Message-
> From: David Montgomery [mailto:davidmontgom...@gmail.com]
> Sent: 28 September 2015 15:21
> To: user@zookeeper.apache.org
> Subject: zk will not cluster
>
> Hi,
>
> I cant cluster three nodes.  They all are standalone.
>
> Here is the zoo.cgf for each
>
> the myid for each is 1,2,3
>
> myid is located in /var/lib/zookeeper/myid
>
>
>   tickTime=3000
>   initLimit=10
>   syncLimit=5
>   dataDir=/var/lib/zookeeper
>   clientPort=2181
>   server.1=104.236.xxx:2888:3888
>   server.2=104.236.xxx:2888:3888
>   server.3=192.241.xxx:2888:3888
>
> Here is how I start
>
> /var/zookeeper-3.4.6/bin/zkServer.sh start-foreground
>
> So why will zk not cluster?
>
> Thanks
> The information contained in this email is strictly confidential and for
> the use of the addressee only, unless otherwise indicated. If you are not
> the intended recipient, please do not read, copy, use or disclose to others
> this message or any attachment. Please also notify the sender by replying
> to this email or by telephone (+44(020 7896 0011) and then delete the email
> and any copies of it. Opinions, conclusion (etc) that do not relate to the
> official business of this company shall be understood as neither given nor
> endorsed by it. IG is a trading name of IG Markets Limited (a company
> registered in England and Wales, company number 04008957) and IG Index
> Limited (a company registered in England and Wales, company number
> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> Index Limited (register number 114059) are authorised and regulated by the
> Financial Conduct Authority.
>

[ANNOUNCE] New committer: Chris Nauroth

[Flavio Junqueira]

The Apache ZooKeeper PMC is pleased to announce that Chris Nauroth has accepted 
to become a committer. Chris has been a great contributor and very active in 
the community.

Congrats, Chris!

-Flavio

3-server Zab cluster

[Ibrahim El-sanosi (PGR)]

In Zab, assume we have a cluster consists of 3-servers. To deliver a write 
request, it must run 3 communication steps proposal, acknowledgement and commit.
As Zab uses reliable FIFO, it is possible to remove commit round. As soon as a 
follower receives a proposal, it logs, sends an ACK and commits locally. Upon 
receiving ACK from any follower, leader commits a proposal locally, no COMMIT 
message need to be sent to followers. In this case, all servers commit a 
proposal in two round-trips, resulting in reducing latency particularly in 
followers.

Note that this optimization can only work in 3-servers cluster (follower 
reaches a majority as soon as it acks).
Does anyone see any problems with such (small) optimization?
Ibrahim

RE: 3-server Zab cluster

[Ibrahim El-sanosi (PGR)]

Thank you Alex for replaying.

When you said " the leader gets re-elected and the operation is truncated from 
logs at other servers". I though the new leader will sync the its logs with 
other followers (synchronization phase), resulting in the operation will commit 
by new quorum.  Let me make the scenarios as steps:

1. leader  (L)  sends a proposal p with zxid =10 to F1 and F2.
2. F1 logs, sends an ACK, commits, replays to clients and crashes. F2 crashes 
before receiving P10. L has not received any ACKs

Possible solution  (1) 
The leader will move to LOOKING phase as there is no quorum supporting its 
leadership. Now Assume F2 wakes up. F2 forms a quorum with the L (pervious 
leader), L becomes new leader again as it has latest zxid (10) in its log. L 
syncs its state with F2, as a result L, F1 (before crashing) and F2 commit P10. 
 Is that correct?

Possible solution  (2)
The leader will move to LOOKING phase as there is no quorum supporting its 
leadership. Now Assume F1 (with Zxid =10  committed) wakes up. I am not sure 
who should be a leader (F1 with Zxid =10 committed or L (pervious leader) with 
Zxid = 10 logged), I think F1 become a new leader as it has Zxid = 10 
committed. F1 forms a quorum with the L (pervious leader), F1  becomes new 
leader as it has latest zxid (10) . L (new leader) syncs its state with L 
(pervious leader now become a follower), as a result Zxid10 commits by new 
quorum.  Is that correct?

What do you think? 

Ibrahim





-Original Message-
From: Alexander Shraer [mailto:shra...@gmail.com] 
Sent: Monday, September 28, 2015 07:27 م
To: user@zookeeper.apache.org
Cc: d...@zookeeper.apache.org
Subject: Re: 3-server Zab cluster

Committing locally when sending an ACK at a server would lead to loss of 
consistency - it is possible that this is the only server that acks, e.g., this 
server is temporarily disconnected from the leader, the leader gets re-elected 
and the operation is truncated from logs at other servers. Its ok to ACK it but 
its not ok to commit since this exposes this to users as a committed operation 
that they can see.

On Mon, Sep 28, 2015 at 4:19 AM, Ibrahim El-sanosi (PGR) < 
i.s.el-san...@newcastle.ac.uk> wrote:

> In Zab, assume we have a cluster consists of 3-servers. To deliver a 
> write request, it must run 3 communication steps proposal, 
> acknowledgement and commit.
> As Zab uses reliable FIFO, it is possible to remove commit round. As 
> soon as a follower receives a proposal, it logs, sends an ACK and 
> commits locally. Upon receiving ACK from any follower, leader commits 
> a proposal locally, no COMMIT message need to be sent to followers. In 
> this case, all servers commit a proposal in two round-trips, resulting 
> in reducing latency particularly in followers.
>
> Note that this optimization can only work in 3-servers cluster 
> (follower reaches a majority as soon as it acks).
> Does anyone see any problems with such (small) optimization?
> Ibrahim
>

Re: 3-server Zab cluster

[Alexander Shraer]

I'm not 100% sure whether operations that were pending on the leader are
sent out during sync when this leader looses quorum and re-elected. If so,
then maybe you're right. But in any case, this would not work for 5 or more
servers...

On Mon, Sep 28, 2015 at 3:51 PM, Ibrahim El-sanosi (PGR) <
i.s.el-san...@newcastle.ac.uk> wrote:

> Thank you Alex for replaying.
>
> When you said " the leader gets re-elected and the operation is truncated
> from logs at other servers". I though the new leader will sync the its logs
> with other followers (synchronization phase), resulting in the operation
> will commit by new quorum.  Let me make the scenarios as steps:
>
> 1. leader  (L)  sends a proposal p with zxid =10 to F1 and F2.
> 2. F1 logs, sends an ACK, commits, replays to clients and crashes. F2
> crashes before receiving P10. L has not received any ACKs
>
> Possible solution  (1)
> The leader will move to LOOKING phase as there is no quorum supporting its
> leadership. Now Assume F2 wakes up. F2 forms a quorum with the L (pervious
> leader), L becomes new leader again as it has latest zxid (10) in its log.
> L syncs its state with F2, as a result L, F1 (before crashing) and F2
> commit P10.  Is that correct?
>
> Possible solution  (2)
> The leader will move to LOOKING phase as there is no quorum supporting its
> leadership. Now Assume F1 (with Zxid =10  committed) wakes up. I am not
> sure who should be a leader (F1 with Zxid =10 committed or L (pervious
> leader) with Zxid = 10 logged), I think F1 become a new leader as it has
> Zxid = 10 committed. F1 forms a quorum with the L (pervious leader), F1
> becomes new leader as it has latest zxid (10) . L (new leader) syncs its
> state with L (pervious leader now become a follower), as a result Zxid10
> commits by new quorum.  Is that correct?
>
> What do you think?
>
> Ibrahim
>
>
>
>
>
> -Original Message-
> From: Alexander Shraer [mailto:shra...@gmail.com]
> Sent: Monday, September 28, 2015 07:27 م
> To: user@zookeeper.apache.org
> Cc: d...@zookeeper.apache.org
> Subject: Re: 3-server Zab cluster
>
> Committing locally when sending an ACK at a server would lead to loss of
> consistency - it is possible that this is the only server that acks, e.g.,
> this server is temporarily disconnected from the leader, the leader gets
> re-elected and the operation is truncated from logs at other servers. Its
> ok to ACK it but its not ok to commit since this exposes this to users as a
> committed operation that they can see.
>
> On Mon, Sep 28, 2015 at 4:19 AM, Ibrahim El-sanosi (PGR) <
> i.s.el-san...@newcastle.ac.uk> wrote:
>
> > In Zab, assume we have a cluster consists of 3-servers. To deliver a
> > write request, it must run 3 communication steps proposal,
> > acknowledgement and commit.
> > As Zab uses reliable FIFO, it is possible to remove commit round. As
> > soon as a follower receives a proposal, it logs, sends an ACK and
> > commits locally. Upon receiving ACK from any follower, leader commits
> > a proposal locally, no COMMIT message need to be sent to followers. In
> > this case, all servers commit a proposal in two round-trips, resulting
> > in reducing latency particularly in followers.
> >
> > Note that this optimization can only work in 3-servers cluster
> > (follower reaches a majority as soon as it acks).
> > Does anyone see any problems with such (small) optimization?
> > Ibrahim
> >
>

Re: zk will not cluster

[Anirudha Jadhav]

server.1=104.236.xxx:2888:3888
  server.2=104.236.xxx:2888:3888
  server.3=192.241.xxx:2888:3888

is this the same zoo.cfg on all machine? double check

On Mon, Sep 28, 2015 at 10:39 AM, David Montgomery <
davidmontgom...@gmail.com> wrote:

> No all have full access using ufw.
>
> Thanks
>
> On Mon, Sep 28, 2015 at 10:23 PM, William Hargrove <
> william.hargr...@ig.com>
> wrote:
>
> > Is there a firewall between those two networks (104.236 and 192.241)?
> >
> > -Original Message-
> > From: David Montgomery [mailto:davidmontgom...@gmail.com]
> > Sent: 28 September 2015 15:21
> > To: user@zookeeper.apache.org
> > Subject: zk will not cluster
> >
> > Hi,
> >
> > I cant cluster three nodes.  They all are standalone.
> >
> > Here is the zoo.cgf for each
> >
> > the myid for each is 1,2,3
> >
> > myid is located in /var/lib/zookeeper/myid
> >
> >
> >   tickTime=3000
> >   initLimit=10
> >   syncLimit=5
> >   dataDir=/var/lib/zookeeper
> >   clientPort=2181
> >   server.1=104.236.xxx:2888:3888
> >   server.2=104.236.xxx:2888:3888
> >   server.3=192.241.xxx:2888:3888
> >
> > Here is how I start
> >
> > /var/zookeeper-3.4.6/bin/zkServer.sh start-foreground
> >
> > So why will zk not cluster?
> >
> > Thanks
> > The information contained in this email is strictly confidential and for
> > the use of the addressee only, unless otherwise indicated. If you are not
> > the intended recipient, please do not read, copy, use or disclose to
> others
> > this message or any attachment. Please also notify the sender by replying
> > to this email or by telephone (+44(020 7896 0011) and then delete the
> email
> > and any copies of it. Opinions, conclusion (etc) that do not relate to
> the
> > official business of this company shall be understood as neither given
> nor
> > endorsed by it. IG is a trading name of IG Markets Limited (a company
> > registered in England and Wales, company number 04008957) and IG Index
> > Limited (a company registered in England and Wales, company number
> > 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> > London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> > Index Limited (register number 114059) are authorised and regulated by
> the
> > Financial Conduct Authority.
> >
>



-- 
Anirudha P. Jadhav