> >...the differnce between that example and what you are doing here is that >in that example, because both of nodes already had collection1 instance >dirs, they expected to be part of collection1 when they joined the >cluster. >
And that, I think, is my misunderstanding. I had assumed that the link between a node and the collections it belongs to would be the (possibly chroot¹ed) zookeeper reference *itself*, not the node¹s directory structure. Instead, it appears that ZK is simply a repository for the collection configuration, where nodes may look up what they need based on filesystem core references. So assume I have a ZK running separately, and it already has a config uploaded which all my collections will use. I then add two nodes with empty solr home dirs, (no cores found) and use the collections API to create a new collection ³collection1" with numShards=1 and replicationFactor=2. Please check my assertions: WRONG: If I take the second node down, wipe the solr home dir on it, and add it back, the collection will properly replicate back onto the node. RIGHT: If I replace the second node, it must have a $SOLR_HOME/collection1_shard1_replica2/core.properties file in order to properly act as the replacement. RIGHT: If I replace the first node, it must have a $SOLR_HOME/collection1_shard1_replica1/core.properties file in order to properly act as the replacement. If correct, this sounds kinda painful, because you have to know the exact list of directory names for the set of collections/shards/replicas the node was participating in if you want to replace a given node. Worse, if you¹re replacing a node whose disk failed, you need to manually reconstruct the contents of those core.properties files? This also leaves me a bit confused about how to increase the replicationFactor on an existing collection, but I guess that¹s tangential. Thanks.
