In the following issue,
https://issues.apache.org/jira/browse/SOLR-14341
Nazerke (my colleague) is working on moving a collection's "configName"
(configSet) into state.json where it should have been all along. Better
late than never. This is targeting 9.0. This email is largely about
migration / backwards-compatibility.
The current location of a collection's configSet name is read by
ZkStateReader.readConfigSetName(collection) which reads JSON stored at the
ZK path "/collections/<COLNAME>" which is the containing node for
SolrCloud's information about the collection (i.e. it contains state.json
etc.). Example data: {"configName":"_default"}. In case you didn't know,
ZK intermediate nodes can contain data just like leaf nodes, unlike a file
system.
Instead, we want it retrievable by a new method DocCollection.getConfigSet
reflecting the storage of state.json which could have a new name-value pair
at the top: "configSet".
So how do we do this transition? How about this: Whenever SolrCloud reads
state.json, it detects the absence of configSet and it inserts it on the
fly, reading the old location. This will incur a performance overhead but
it's transient during an upgrade to Solr 9. To ensure that all collections
are upgraded (and thus stop incurring a penalty), we can provide a trivial
bash script that reads all existing collections and loops over them to call
MODIFYCOLLECTION to set the configSet to whatever it is currently.
Creating/modifying a collection will ensure that the configSet name is
stored in the old place and new place.
Then we remove writing to the old place in Solr 10. Or maybe Solr 9
doesn't write to the old location, provided that during a live upgrade you
don't create or modify collections or associations with configSets because
that could confuse Solr 8 nodes? If we go with this, a
MODIFYCOLLECTION command could remove the old data if it's present.
AFAICT, SolrJ CloudSolrClient doesn't really care about this matter,
thankfully.
WDYT folks?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
