> I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can
> read a 5.0 (or 6.0) Solr.
Agree. A lack of promise for major version back compat gives us the freedom to
do crazy breaking changes - but it does not prevent us from doing best effort
attempts of a smooth transition for those that want to attempt.
To contribute constructively to the discussion, here is the current 6.0 upgrade
instructions from CHANGES.txt, which may give some hints on possible hurdles:
Upgrading from Solr 5.x
----------------------
* The deprecated SolrServer and subclasses have been removed, use SolrClient
instead.
* The deprecated <nrtMode> configuration in solrconfig.xml has been removed.
Please remove it from solrconfig.xml.
* SolrClient.shutdown() has been removed, use SolrClient.close() instead.
* The deprecated zkCredientialsProvider element in solrcloud section of solr.xml
is now removed. Use the correct spelling (zkCredentialsProvider) instead.
* SOLR-7957: internal/expert - ResultContext was significantly changed and
expanded
to allow for multiple full query results (DocLists) per Solr request.
TransformContext was rendered redundant and was removed. (yonik)
* Several changes have been made regarding the "Similarity" used in Solr, in
order to provide
better default behavior for new users. There are 3 key impacts of these
changes on existing
users who upgrade:
* DefaultSimilarityFactory has been removed. If you currently have
DefaultSimilarityFactory explicitly
referenced in your schema.xml, edit your config to use the functionally
identical
ClassicSimilarityFactory. See SOLR-8239 for more details.
* The implicit default Similarity used when no <similarity/> is configured in
schema.xml has
been changed to SchemaSimilarityFactory. Users who wish to preserve
back-compatible behavior should
either explicitly configure ClassicSimilarityFactory, or ensure that the
luceneMatchVersion
for the collection is less then 6.0. See SOLR-8270 + SOLR-8271 for details.
* SchemaSimilarityFactory has been modified to use BM25Similarity as the
default for fieldTypes that
do not explicitly declare a Similarity. The legacy behavior of using
ClassicSimilarity as the
default will occur if the luceneMatchVersion for the collection is less
then 6.0, or the
'defaultSimFromFieldType' configuration option may be used to specify any
default of your choosing.
See SOLR-8261 + SOLR-8329 for more details.
* If your solrconfig.xml file doesn't explicitly mention the schemaFactory to
use then Solr will choose
the ManagedIndexSchemaFactory by default. Previously it would have chosen
ClassicIndexSchemaFactory.
This means that the Schema APIs ( /<collection>/schema ) are enabled and the
schema is mutable.
When Solr starts your schema.xml file will be renamed to managed-schema. If
you want to retain the old behaviour
then please ensure that the solrconfig.xml explicitly uses the
ClassicIndexSchemaFactory :
<schemaFactory class="ClassicIndexSchemaFactory"/> or your luceneMatchVersion
in the solrconfig.xml is less than 6.0
* SolrIndexSearcher.QueryCommand and QueryResult were moved to their own
classes. If you reference them
in your code, you should import them under o.a.s.search (or use your IDE's
"Organize Imports").
* SOLR-8698: 'useParams' attribute specified in request handler cannot be
overridden from request params
Looks like many of these changes would be possible to prepare for by modifying
5.x config before upgrading, e.g. the schema factory etc.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 23. feb. 2016 kl. 19.54 skrev Shai Erera <ser...@gmail.com>:
>
> Mark, I understand that we currently don't have any other promises :). I
> asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to
> refer to /solr_collections instead of /collections" (I wish it would be
> *that* trivial :)).
>
> If you don't have a list that's fine. You just sounded really confident that
> 5.x -> 6.0 won't work, so I hoped you also can tell why.
>
> I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can
> read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as a
> thing we want to support. That's just my opinion though.
>
> Shai
>
> On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta <ans...@anshumgupta.net
> <mailto:ans...@anshumgupta.net>> wrote:
> For that, we provide an index upgrade tool with 6.0, like we did in 5.0.
>
> On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob <md...@apache.org
> <mailto:md...@apache.org>> wrote:
> A 5.x Solr could have indices that are still in a 4.x format, right? That
> would be one point where it's not "fully back compatible."
>
> On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <ser...@gmail.com
> <mailto:ser...@gmail.com>> wrote:
> Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will
> be able to read Lucene 5.0 indexes. The only thing that we don't guarantee
> support for is API, which isn't the case here.
>
> So what's in 6.0 that can't read a 5.x Solr. It can't be the index format
> since that's supported by Lucene. Is it the ZK format? If so, should we try
> to "version" it so that a 6.0 code can read a 5.x version? Is it something
> else / additionally?
>
> Shai
>
> On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <markrmil...@gmail.com
> <mailto:markrmil...@gmail.com>> wrote:
> Yes, we are allowed wide berth to break backcompat across major versions and
> we cannot support rolling updates for the same reason Lucene stopped trying
> to do full back compat across major versions. Without, we can't properly
> innovate in the code or fix past mistakes and would also burn lots of cycles
> we don't have on crazy, "sophisticated" back compat layers.
>
> We don't even really support rolling updates between major versions. We make
> a simple best effort. Until we have tests, it's going to be a shaky affair.
> There is a JIRA open now working on some testing I believe.
>
> - Mark
>
> On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <ser...@gmail.com
> <mailto:ser...@gmail.com>> wrote:
> Hi
>
> I read in few emails/issue comments that rolling upgrades from 5.x to 6.0
> isn't supported. Is it really the case? Does it mean that anyone who has a
> 5.x Solr cluster *must* incur down time when upgrading to 6.0?
>
> If this is really the case, can someone list the known issues/reasons for
> that?Can we do something about it, e.g. in a subsequent 5.6 release that will
> allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from
> pre-5.4 to 5.4)?
>
> I feel it's odd (and may not be taken well) if we force users to take down
> their entire cluster if they want to upgrade to 6.0. Definitely feels like it
> will also slow down 6.0 adoption.
>
> And if nothing can be done, what's the recommended way then to upgrade to 6.0?
>
> Shai
> --
> - Mark
> about.me/markrmiller <http://about.me/markrmiller>
>
>
>
> --
> Anshum Gupta
