Why are you doing this? It seems like you're making it
_much_ more difficult than necessary. Sure, automate
all the non-solr stuff, but why not make your scripts use
the ZK upload/download process that's well established
and tested for maintaining the Solr specific data?

Best,
Erick

On Mon, Jul 27, 2015 at 9:48 AM, Modassar Ather <modather1...@gmail.com> wrote:
> Thanks for your response Erick and Shawn.
>
> We had automated the solr/zookeeper future upgrades using scripts. So for
> any new version of solr/zookeeper we use those script.
> While upgrading zookeeper we do stop it to install it as a service and then
> apply the new distribution(which is currently 3.4.6) and restart. Content
> of zoo_data is not deleted.
> After that the solr configs are uploaded. In this process of zookeeper
> upgrade solr nodes are not restarted.
> After this upgrade process I have seen all the nodes active. There are
> connection related exception in solr log for the time the zookeeper was
> stopped.
>
> Our indexer again uploads the configs to accommodate any possible changes
> in schema or solrconfig which passes every time and then during reload of
> collection we are getting following exception intermittently.
>
> {"responseHeader":{"status":500,"QTime":180028},"error":{"msg":"reload the
> collection time out:180s","trace":"org.apache.solr.common.SolrException:
> reload the collection time out:180s\n\tat
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:237)\n\tat
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:168)\n\tat
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)\n\tat
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)\n\tat
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
> java.lang.Thread.run(Thread.java:745)\n","code":500}}
>
> Regards,
> Modassar
>
>
>
> On Mon, Jul 27, 2015 at 8:45 PM, Shawn Heisey <apa...@elyograg.org> wrote:
>
>> On 7/27/2015 6:17 AM, Modassar Ather wrote:
>> > Kindly help me understand following with respect to Solr version 5.2.1.
>> >
>> > 1. What happens to the solr cluster if the standalone external zookeeper
>> is
>> > stopped/restarted with some changes done in zoo_data during the restart?
>> >     E.g After restarting the zookeeper the solr configs are reloaded with
>> > changes. Please note that solr cluster is not restarted.
>> > 2. In what conditions of zookeeper restart the solr nodes are required to
>> > be restarted?
>>
>> If zookeeper loses quorum, SolrCloud goes read-only.  Updates won't be
>> possible until zookeeper has quorum again.  If zookeeper goes away
>> completely, I think the result might be the same, but I do not know.
>>
>> For changes in zookeeper related to core configuration, simply reloading
>> affected collections with the Collections API is enough.  For more
>> extensive changes, especially to things like the clusterstate,
>> restarting all Solr nodes might be required.  If you give us specifics
>> about what you want to change, we can figure out exactly what actions
>> are needed.
>>
>> Thanks,
>> Shawn
>>
>>

Reply via email to