Yeah, this all feedbacks into the ZK as Truth mode that we've been talking about. The documentation is misleading because yes, if a node comes back up, then it will add itself to the cluster state. There are plans to change that behaviour once we've thought through more use-cases and are ready to break back-compat. There is a new cluster level property called "legacyCloud" which defaults to "true" but if it is set to "false" then behaviour documented on the reference guide will be used.
On Wed, Sep 3, 2014 at 6:01 PM, Erick Erickson <erickerick...@gmail.com> wrote: > I'm confused, wondering if it's a mismatch between the docs and the > intent or just a bug or whether I'm just not understanding the point: > > The DELETEREPLICA docs say: > > "Delete a replica from a given collection and shard. If the > corresponding core is up and running the core is unloaded and the > entry is removed from the clusterstate. If the node/core is down, the > entry is taken off the clusterstate and if the core comes up later it > is automatically unregistered." > > However, if I do the following: > 1> create a follower on nodeX > 2> shut down nodeX (at this point, the clusterstate has indicates the > follower is down) > 3> issue a DELETEREPLICA for the follower (clusterstate entry for this > follower is removed) > 4> restart nodeX (clusterstate shows this node is back, it's visible > in cloud veiw, gets sync'd etc.). > > Based on the docs, I didn't expect to see the node present in step 4, > what am I missing? > > The core has docs (i.e. it's synched from the leader) etc. So this bit > of the documentation is confusing me: "If the node/core is down, the > entry is taken off the clusterstate and if the core comes up later it > is automatically unregistered." > > That doesn't square with what I'm seeing so either the docs are wrong > or I'm misunderstanding the intent. > > If the node _is_ up, then it's removed from the node and clusterstate > and stays gone. > > Personally, I don't particularly like the idea of queueing up the > DELETEREPLICAS for later execution, seems like it's overly complex. > Having the clusterstate info removed if the node is down seems very > useful though. > > Thanks, > Erick > -- Regards, Shalin Shekhar Mangar.
