[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097952#comment-14097952
]
Shawn Heisey commented on SOLR-6249:
------------------------------------
I only have one little SolrCloud setup, but right now every one of the
collections that it has is using the same configuration set. I would expect
that if I update my schema, it would apply the changes to all my collections,
because I made the deliberate decision for them to share that configuration.
Can our instructions for SolrCloud easily result in a situation where a user
has multiple collections sharing a configuration, and is unaware of that fact?
The only likely situation that I can imagine where a schema will work on one
server but not another is if it relies on a class that's loaded from a jar in a
local lib directory that doesn't exist on every server. I'm not sure how we
would detect that and roll back changes made up to that point.
> from
> ------
>
> Key: SOLR-6249
> URL: https://issues.apache.org/jira/browse/SOLR-6249
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, SolrCloud
> Reporter: Gregory Chanan
>
> See SOLR-6137 for more details.
> The basic issue is that Schema API changes return success when the first core
> is updated, but other cores asynchronously read the updated schema from
> ZooKeeper.
> So a client application could make a Schema API change and then index some
> documents based on the new schema that may fail on other nodes.
> Possible fixes:
> 1) Make the Schema API calls synchronous
> 2) Give the client some ability to track the state of the schema. They can
> already do this to a certain extent by checking the Schema API on all the
> replicas and verifying that the field has been added, though this is pretty
> cumbersome. Maybe it makes more sense to do this sort of thing on the
> collection level, i.e. Schema API changes return the zk version to the
> client. We add an API to return the current zk version. On a replica, if
> the zk version is >= the version the client has, the client knows that
> replica has at least seen the schema change. We could also provide an API to
> do the distribution and checking across the different replicas of the
> collection so that clients don't need ot do that themselves.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
