Hi all, Two issues, first, when I issue an ADDREPLICA call like so:
http://localhost:8983/solr/admin/collections?action=ADDREPLICA&shard=myshard&collection=mycollection&createNodeSet=solr18.mycorp.com:8983_solr It does not seem to respect the 8983_solr designation in the createNodeSet parameter and instead places the shard on any JVM on the node. First attempt I got a replica on 8994_solr and second attempt to place a replica on 8983 got a replica on 8992_solr instead. As an aside, is there any particular reason why DELETEREPLICA asks for the ZK "shard id" (node_###) instead of the same syntax as createNodeSet? I can't recall any other instance in which the ZK "shard id" is exposed via query parameter and I've only ever seen it in clusterstate.json / CLUSTERSTATUS calls. The 2nd issues is as follows: I am running Solr built off branch_4x, and thanks to some help from IRC we've determined that we have an incompatible index situation where we have indexes built with 4.9 that we can read but not index into further or update. Understandable, and going forward we don't intend to run off of master. In this situation, if I try to add a replica, this also fails, however, the only log ouput (at WARN threshold) is: 16:21:58.156 [RecoveryThread] WARN org.apache.solr.update.PeerSync - no frame of reference to tell if we've missed updates ...and the replica comes up green. I think this might indicate a missing integrity check on replication but certainly IMO a replica should report as green/active if it is not on the same revision as the leader, or at least if it has never been on the same revision as the leader. Thanks for any assistance/validation/advice, --Ralph
