lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mike st. john" <mstj...@gmail.com>
Subject Re: collections api setting dataDir
Date Mon, 09 Sep 2013 15:13:34 GMT
hi,

i've sorted it all out.  basically a  few replicas had failed and the
counts on the replicas were less than the leader.,  i basically killed the
index on those replicas and let them recover.


Thanks for the  help.

msj


On Mon, Sep 9, 2013 at 11:08 AM, Shawn Heisey <solr@elyograg.org> wrote:

> On 9/7/2013 2:25 PM, mike st. john wrote:
> > yes the collections api ignored it,    what i ended up doing, was just
> > building out some fairness in regards to creating the cores and calling
> > coreadmin to create the cores, seemed to work ok.   Only issue i'm having
> > now, and i'm still investigating is subsequent queries are returning
> > different counts.
>
> Every time I have seen distributed queries return different counts on
> different runs, it is because documents with the same value in the
> UniqueKey field exist in more than one shard.  If you are letting
> SolrCloud route your documents automatically, this shouldn't happen ...
> but if you are using distrib=false or a router that doesn't do it
> automatically, then it could.
>
> The Collections API doesn't do the dataDir parameter.  I suspect this is
> because you could pass an absolute path in, which would break things
> because every core would be trying to use the same dataDir.  If you want
> a directory other than ${instanceDir}/data for dataDir, then you will
> need to create each core individually rather than use the Collections API.
>
> Java does have the capability to determine whether a path is relative or
> absolute, but it is safer to just ignore that parameter, especially
> given the fact that a single cloud is usually on many servers, and
> there's no reason those servers can't be running wildly different
> operating systems.  Half your cloud could be on a Linux/UNIX OS and half
> of it could be on Windows.
>
> I personally find it better to let the Collections API do its thing and
> use the default.
>
> Thanks,
> Shawn
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message