Solr Backup

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Solr Backup

Jayadevan Maymala
Hello all,

We have a 3-node Solr cluster running on google cloud platform. I would
like to schedule a backup and have been trying the backup API and getting
java.nio.file.NoSuchFileException:java.nio.file.NoSuchFileException error.
I suspect it is because a shared drive is necessary. Google VM instances
don't have this feature, unless I go for Cloud Filestore.
Is there a work-around? Some way in which I can have the cluster back up
taken on the node on which I am executing the backup command? Solr Version
is 7.3

Regards,
Jayadevan
Reply | Threaded
Open this post in threaded view
|

Re: Solr Backup

Shawn Heisey-2
On 7/30/2019 5:41 AM, Jayadevan Maymala wrote:
> We have a 3-node Solr cluster running on google cloud platform. I would
> like to schedule a backup and have been trying the backup API and getting
> java.nio.file.NoSuchFileException:java.nio.file.NoSuchFileException error.
> I suspect it is because a shared drive is necessary. Google VM instances
> don't have this feature, unless I go for Cloud Filestore.
> Is there a work-around? Some way in which I can have the cluster back up
> taken on the node on which I am executing the backup command? Solr Version
> is 7.3

We will need the *FULL* error message.  It is probably dozens of lines
long and MIGHT contain multiple "Caused by" sections.  We will also need
the complete Solr version to be able to interpret the error -- 7.3 is
not specific enough.

Thanks,
Shawn
Reply | Threaded
Open this post in threaded view
|

Re: Solr Backup

Jayadevan Maymala
On Tue, Jul 30, 2019 at 5:56 PM Shawn Heisey <[hidden email]> wrote:

> On 7/30/2019 5:41 AM, Jayadevan Maymala wrote:
> > We have a 3-node Solr cluster running on google cloud platform. I would
> > like to schedule a backup and have been trying the backup API and getting
> > java.nio.file.NoSuchFileException:java.nio.file.NoSuchFileException
> error.
> > I suspect it is because a shared drive is necessary. Google VM instances
> > don't have this feature, unless I go for Cloud Filestore.
> > Is there a work-around? Some way in which I can have the cluster back up
> > taken on the node on which I am executing the backup command? Solr
> Version
> > is 7.3
>
> We will need the *FULL* error message.  It is probably dozens of lines
> long and MIGHT contain multiple "Caused by" sections.


{
  "responseHeader":{
    "status":500,
    "QTime":22},
  "Operation backup caused
exception:":"java.nio.file.NoSuchFileException:java.nio.file.NoSuchFileException:
/backups/coupon",
  "exception":{
    "msg":"/backups/coupon",
    "rspCode":-1},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"/backups/coupon",
    "trace":"org.apache.solr.common.SolrException: /backups/coupon\n\tat
org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:258)\n\tat
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:230)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)\n\tat
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)\n\tat
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)\n\tat
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:530)\n\tat
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)\n\tat
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)\n\tat
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)\n\tat
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)\n\tat
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)\n\tat
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)\n\tat
java.lang.Thread.run(Thread.java:748)\n",
    "code":500}}

> We will also need
> the complete Solr version to be able to interpret the error -- 7.3 is
> not specific enough.
>

I am new to Solr. I could see this in the admin panel and hope that is that
you are looking for.
solr-spec - 7.3.0
solr-impl - 7.3.0 98a6b3d642928b1ac9076c6c5a369472581f7633 - woody
Initially I created the directory under / . I also tried creating the
backups directory under /opt/solr-7.3.0/server/

Thanks,
Jayadevan
Reply | Threaded
Open this post in threaded view
|

Re: Solr Backup

Shawn Heisey-2
On 7/30/2019 7:11 AM, Jayadevan Maymala wrote:

>> We will need the *FULL* error message.  It is probably dozens of lines
>> long and MIGHT contain multiple "Caused by" sections.
>
> {
>    "responseHeader":{
>      "status":500,
>      "QTime":22},
>    "Operation backup caused
> exception:":"java.nio.file.NoSuchFileException:java.nio.file.NoSuchFileException:
> /backups/coupon",

That is the response, and it doesn't have the information I was hoping
to see.  It doesn't show what happened ... basically it says there was
an error, but doesn't have any real detail about what the error was.
Analyzing what stacktrace data is available doesn't reveal anything useful.

I was hoping for actual logfile data.  The solr.log file from the server
side may contain a more complete error.  If you can use a file sharing
website or paste website to share the whole logfile, we might be able to
find more information.

Thanks,
Shawn
Reply | Threaded
Open this post in threaded view
|

Re: Solr Backup

Jan Høydahl / Cominvent
In reply to this post by Jayadevan Maymala
The FS backup feature requires a shared drive as you say, and this is clearly documented. No way around it. Cloud Filestore would likely fix it.

Or you could write a new backup repo plugin for backup directly to Google Cloud Storage?

Jan Høydahl

> 30. jul. 2019 kl. 13:41 skrev Jayadevan Maymala <[hidden email]>:
>
> Hello all,
>
> We have a 3-node Solr cluster running on google cloud platform. I would
> like to schedule a backup and have been trying the backup API and getting
> java.nio.file.NoSuchFileException:java.nio.file.NoSuchFileException error.
> I suspect it is because a shared drive is necessary. Google VM instances
> don't have this feature, unless I go for Cloud Filestore.
> Is there a work-around? Some way in which I can have the cluster back up
> taken on the node on which I am executing the backup command? Solr Version
> is 7.3
>
> Regards,
> Jayadevan
Reply | Threaded
Open this post in threaded view
|

Re: Solr Backup

Jayadevan Maymala
On Tue, Jul 30, 2019 at 7:54 PM Jan Høydahl <[hidden email]> wrote:

> The FS backup feature requires a shared drive as you say, and this is
> clearly documented. No way around it. Cloud Filestore would likely fix it.
>
> Or you could write a new backup repo plugin for backup directly to Google
> Cloud Storage?
>
I created a filtestore, mounted it on all the 3 nodes and the backup
worked. The minimum size of a Google Cloud Filestore is 1 TB, while our
backup would be well under 100 GB. I was just checking to see if there is a
way to avoid paying for 1 TB, especially since we do have spare local
storage. Anyway, guess this is the only way.
Thanks,
Jayadevan