Hi,
In 7.1, how does solr determine the numbers that are assigned to the
replicas? I'm familiar with the earlier naming conventions from 6.3, but I
wanted to know if there was supposed to be any connection between the
"_n##" suffix and the number assigned to the "core_node##" name since they
don't seem to follow the old convention. As an example node from
clusterstatus for a testcollection with replication factor 2.
"core_node91":{
"core":"testcollection_shard22_replica_n84",
"base_url":"http://host:8080/solr";,
"node_name":"host:8080_solr",
"state":"active",
"type":"NRT",
"leader":"true"}
Along the same lines, when creating the testcollection with 200 shards and
replication factor of 2, I am also getting nodes that have negative numbers
assigned to them which looks a lot like an int overflow issue. From the
cluster status:
"shard157":{
"range":"47ae0000-48f4ffff",
"state":"active",
"replicas":{
"core_node1675945628":{
"core":"testcollection _shard157_replica_n-1174535610",
"base_url":"http://host1:8080/solr";,
"node_name":"host1:8080_solr",
"state":"active",
"type":"NRT"},
"core_node1642259614":{
"core":"testcollection _shard157_replica_n-1208090040",
"base_url":"http://host2:8080/solr";,
"node_name":"host2:8080_solr",
"state":"active",
"type":"NRT",
"leader":"true"}}}
This keeps happening even when the collection is successfully deleted (no
directories or files left on disk), the entire cluster is shutdown, and the
zookeeper chroot path cleared out of all content. The only thing that
happened prior to this cycle was a single failed collection creation which
seemed to clean itself up properly, after which everything was shutdown and
cleaned from zookeeper as well.
Is there something else that is keeping track of those values that wasn't
cleared out? Or is this now the expected behavior for the numerical
assignments to replicas?
Thanks,
Chris
