Yuliya just asked me this:

> If "myid" in ZK datadir gets overwritten with different from existing
number (still unique within ensemble) will it create an issue while ZK is
running?

My suggested answer is that it won't hurt anything, but it may cause that
node to discard any snapshots or logs created under the old id.

Anybody have corrections or amplifications to this?

That's interesting, I would say the opposite though.  ZK uses the myid file
when starting to know which node in the config file corresponds to itself.
 If the myid file doesn't match a "server.X" entry in the config file, then
I imagine it would fail to start successfully, not knowing which ip/ports
are for itself.  Maybe someone who isn't guessing should answer though.

~Jared

On Tue, Dec 14, 2010 at 8:25 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> Yuliya just asked me this:
>
> > If "myid" in ZK datadir gets overwritten with different from existing
> number (still unique within ensemble) will it create an issue while ZK is
> running?
>
> My suggested answer is that it won't hurt anything, but it may cause that
> node to discard any snapshots or logs created under the old id.
>
> Anybody have corrections or amplifications to this?
>

We aren't talking about any mismatch between the myid file and server.X
entries in the configuration file.

On Tue, Dec 14, 2010 at 5:35 PM, Jared Cantwell <[EMAIL PROTECTED]>wrote:

> That's interesting, I would say the opposite though.  ZK uses the myid file
> when starting to know which node in the config file corresponds to itself.
>  If the myid file doesn't match a "server.X" entry in the config file, then
> I imagine it would fail to start successfully, not knowing which ip/ports
> are for itself.  Maybe someone who isn't guessing should answer though.
>
> ~Jared
>
> On Tue, Dec 14, 2010 at 8:25 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
>
> > Yuliya just asked me this:
> >
> > > If "myid" in ZK datadir gets overwritten with different from existing
> > number (still unique within ensemble) will it create an issue while ZK is
> > running?
> >
> > My suggested answer is that it won't hurt anything, but it may cause that
> > node to discard any snapshots or logs created under the old id.
> >
> > Anybody have corrections or amplifications to this?
> >
>

Hi Yuliya,
  The masted id is used to resolve conflicts when 2 servers have the latest transaction id during leader election. Also, its used as the first N  bits for the session id to make it unique across zookeeper servers.

Thanks
mahadev
On 12/14/10 5:25 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

Yuliya just asked me this:

> If "myid" in ZK datadir gets overwritten with different from existing
number (still unique within ensemble) will it create an issue while ZK is
running?

My suggested answer is that it won't hurt anything, but it may cause that
node to discard any snapshots or logs created under the old id.

Anybody have corrections or amplifications to this?

So if we change those assignments and restart all servers, we will have a
new leader election and all new sessions, right?

Obviously, we probably can't expect that a rolling restart would work in
this case because the new assignments may conflict with the old assignments
temporarily which would cause some havoc with session id's.  If the new id's
come from a completely different range, I would expect that this would work
reasonably well.

On Tue, Dec 14, 2010 at 6:30 PM, Mahadev Konar <[EMAIL PROTECTED]>wrote:

> Hi Yuliya,
>  The masted id is used to resolve conflicts when 2 servers have the latest
> transaction id during leader election. Also, its used as the first N  bits
> for the session id to make it unique across zookeeper servers.
>
> Thanks
> mahadev
>
>
> On 12/14/10 5:25 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
> Yuliya just asked me this:
>
> > If "myid" in ZK datadir gets overwritten with different from existing
> number (still unique within ensemble) will it create an issue while ZK is
> running?
>
> My suggested answer is that it won't hurt anything, but it may cause that
> node to discard any snapshots or logs created under the old id.
>
> Anybody have corrections or amplifications to this?
>
>