Comment 4 for bug 1003908

On May 30, 2012, at 9:31 AM, Alex Yurchenko wrote:

> About "offline" nodes: the thing is that the node is either in the
> cluster - and then it has a state like PRIM, JOINED, SYNCED or the like
> (it can be OFFLINE if need be, but we have not implemented that yet for
> lack of purpose), or it is out of the cluster, and then the cluster does
> not know anything about it. In other words, if the node does not
> communicate with the cluster (I believe this is the meaning of "offline"
> here), how can cluster tell it exists at all?

I was assuming that there was some state where a node had joined, but was current disconnected (and the cluster still was aware of them), but maybe that's not the case. I wouldn't expect to know about unjoined nodes.

> The cluster could of
> course remember all the nodes it ever saw, but then how would you remove
> the nodes from the cluster?

When the cluster experienced a node disconnect/timeout event, I would presume it could update this state table, no?

Maybe a better implementation of this is simply a cluster events table in the I_S -- a record of all node joins/disconnects, at least as far as the queried node is aware of. The cluster has a config version #, and I presume all nodes must agree on a new config, so simply a delta of the previous and new config versions would be a better way thing to make available, not sure.

Jay Janssen, MySQL Consultant, Percona Inc.
Telephone: +1 888 401 3401 ext 563 (US/Eastern)
Emergency: +1 888 401 3401 ext 911
Skype: percona.jayj
GTalk/MSN: <email address hidden>
Calendar: http://tungle.me/jayjanssen

Percona Live in NYC Oct 1-2nd: http://www.percona.com/live/nyc-2012/