On 6/18/13 2:15 PM, Mark Miller wrote:
I don't know what the best method to use now is, but the slightly longer term
plan is to:
* Have a new mode where you cannot preconfigure cores, only use the
collection's API.
* ZK becomes the cluster state truth.
* The Overseer takes actions to ensure cores live/die in different places based
on the truth in ZK.
Not that we have to decide on this now, but I guess in "my scenario" I
do not see why the Overseer should be involved. The replica is already
assigned to run on the "replaced" machine with a specific IP/hostname
(actually a specific Solr node-name), so I guess that the Solr node
itself on this new/replaced machine should just go look in ZK when it
starts up and realize that it ought to run this and that replica and
start loading them itself. I recognize that the Overseer should/could be
involved in relocating replica for different reasons - loadbalancing,
rack-awareness etc. But in cases where a replica is already assigned to
a certain node-name according to ZK state, but the node is not
preconfigured (in solr.xml) to run this replica, the node itself should
just realize that it ought to run it anyway and load it. But it probably
have to be thought through well. Just my immediate thoughts.
- Mark
Regards, Per Steffensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
