On 10/15/2018 1:30 PM, Dasarathi Minjur wrote:
We have a Hadoop cluster with Solr 6.3 running as service. After an OS
security patching, when the cluster was restarted, Solr Cloud is up
but the shards are down all the time. No specific messages in Solr.log
or console logs. Tried restarting solr
Hello,
We observed this problem too with older Solr versions. Whenever none of the
shard's replica's would come up we would just shut them all down again and
restart just one replica and wait. In some cases it won't come up (still true
for Solr 7.4), but start a second shard a while later and w
If you send explicit commits to the cluster then SOLR-6530 can cause shards
to be put into down state during network partitions. If you rely only on
configured autocommits then you won't be affected by this bug. This is
fixed in 4.10.2
On Wed, Dec 10, 2014 at 5:02 AM, Norgorn wrote:
> The proble
Your shards shouldn't mysteriously go down and stay down.
But tlogs shouldn't be that big either, there's not much point in
having that much info. It's a long story and I have to run, but
here's a discussion of that topic.
https://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-c
The problem is, that hard commit is on, max uncommited docs = 500.000.
And tlog size is just about 200 MB per shard - doesn't seem too big for me.
The reason of my panic is the fact, that one shard in my old collection is
down forever, without any unusual entries in logs. I tried different magic
(
How big is your transaction log? If you don't do a hard commit
(openSearcher = true or false doesn't matter), then the tlog
can grow and upon restart the tlog gets replayed. I've seen
tlogs in the 10s of G range which can take a long time to replay.
In the mean time, new updates are written to, you
* I have created a new RequestHandler and added the list of the shards :
...
localhost:8780/apache-solr/leg0,localhost:8780/apache-solr/leg1,localhost:8780/apache-solr/leg2,localhost:8780/apache-solr/leg3,localhost:8780/apache-solr/leg4,localhost:8780/apache-solr/leg5
...
* In the url, I replac
Create a new RequestHandler config, say /distrib. Requests will be
forwarded to /select, which doesn't have the shards parameter, and
everything will be just fine.
Upayavira
On Tue, Jun 25, 2013, at 02:17 PM, medley wrote:
> Thanks.
>
> It is working now and the QTime has been divided by 10.
>
Thanks.
It is working now and the QTime has been divided by 10.
I would like to put the shard parameters in the requesthandler. I have one
solr-config.xml file by core.
Is it possible to have a common solr-config.xml file and in that case, a
common requesthandler ?
Regards
Medley
--
View thi
On 6/21/2013 3:32 AM, medley wrote:
> I have this kind of url :
>
> "http://remoteserver/solr/leg0/select/?rows=10&version=2&fl=*
> &shards=
> remoteserver:80/solr/core0,
> ...
> remoteserver:80/solr/core5,
> ...
> remoteserver:80/solr/core9
> &..
>
> There is only ONE Solr instance with
If they are running on port 8983, then you just use localhost:8983
instead of remoteserver:80. Those URLs will be used from the solr server
itself, so localhost should work.
Upayavira
On Fri, Jun 21, 2013, at 10:32 AM, medley wrote:
> Hello,
>
> I have this kind of url :
>
> "http://remoteserve
It worked ,i followed steps only difference i erased everything and started
from scratch again
> From: kalyan.ku...@live.com
> To: solr-user@lucene.apache.org
> Subject: Solr Shards and ZooKeeper
> Date: Wed, 12 Jun 2013 14:51:41 -0400
>
> Hi allI am trying to configure external zookeeper with s
On Feb 20, 2013, at 9:47 PM, Rollin.R.Ma (lab.sh04.Newegg) 41099
wrote:
> I also see " Concerning CloudSolrServer, there is a JIRA to make it hash and
> send updates to the "right" leader, but currently it still doesn't - it just
> favors leaders in general over non leaders currently. "
>
>
Can you give some more details? When you look at the cloud tab of the admin UI,
does the cluster visualization look right? Are all the nodes green? Perhaps the
shard is a leader and a replica single shrad and you just think it's 2 shards?
- Mark
On Feb 20, 2013, at 8:26 PM, rulinma wrote:
> H
Aha! See, Kuli, I wasn't making it up! ;)
Otis
Performance Monitoring for Solr / ElasticSearch / HBase -
http://sematext.com/spm
>
> From: Robert Stewart
>To: solr-user@lucene.apache.org
>Sent: Monday, May 14, 2012 11:23 AM
>Subj
t;
> >>> ________
> >>> From: Michael Kuhlmann <[hidden
> >>> email]<http://user/SendEmail.jtp?type=node&node=3983692&i=1>>
>
> >>> To: [hidden email]<http://user/SendEmail.jtp?type=node&node=398369
gt; ____
>>> From: Michael Kuhlmann
>>> To: solr-user@lucene.apache.org
>>> Sent: Monday, May 14, 2012 10:21 AM
>>> Subject: Re: Solr Shards multi core slower then single big core
>>>
>>> Am 14.05.2012 16:18, sch
-
> http://sematext.com/spm
>
>
>
>>
>> From: Michael Kuhlmann
>>To: solr-user@lucene.apache.org
>>Sent: Monday, May 14, 2012 10:21 AM
>>Subject: Re: Solr Shards multi core slower then single big core
>>
>>Am 14.05.2012 16:18, schri
hlmann
>To: solr-user@lucene.apache.org
>Sent: Monday, May 14, 2012 10:21 AM
>Subject: Re: Solr Shards multi core slower then single big core
>
>Am 14.05.2012 16:18, schrieb Otis Gospodnetic:
>> Hi Kuli,
>>
>> In a client engagement, I did see this (N shards on 1
Am 14.05.2012 16:18, schrieb Otis Gospodnetic:
Hi Kuli,
In a client engagement, I did see this (N shards on 1 beefy box with lots of
RAM and CPU cores) be faster than 1 big index.
I want to believe you, but I also want to understand. Can you explain
why? And did this only happen for single
n
>To: solr-user@lucene.apache.org
>Sent: Monday, May 14, 2012 7:56 AM
>Subject: Re: Solr Shards multi core slower then single big core
>
>Am 14.05.2012 13:22, schrieb Sami Siren:
>>> Sharding is (nearly) always slower than using one big index with sufficient
>>>
Am 14.05.2012 13:22, schrieb Sami Siren:
Sharding is (nearly) always slower than using one big index with sufficient
hardware resources. Only use sharding when your index is too huge to fit
into one single machine.
If you're not constrained by CPU or IO, in other words have plenty of
CPU cores
> Sharding is (nearly) always slower than using one big index with sufficient
> hardware resources. Only use sharding when your index is too huge to fit
> into one single machine.
If you're not constrained by CPU or IO, in other words have plenty of
CPU cores available together with for example se
Am 14.05.2012 05:56, schrieb arjit:
Thanks Erick for the reply.
I have 6 cores which doesn't contain duplicated data. every core has some
unique data. What I thought was when I read it would read parallel 6 cores
and join the result and return the query. And this would be efficient then
reading o
Thanks Erick for the reply.
I have 6 cores which doesn't contain duplicated data. every core has some
unique data. What I thought was when I read it would read parallel 6 cores
and join the result and return the query. And this would be efficient then
reading one big core.
My question is wouldn't S
One of the points of sharding is to use more _machines_. Running multiple
shards on a single machine is not magically going to make things faster. In
fact I'd expect your process to consume more resources since the
cores are now not sharing common data (i.e. having a single word
in more than one co
My query is
SolrQuery sQuery = new SolrQuery(query.getQueryStr());
sQuery.setQueryType("dismax");
sQuery.setRows(100);
if (!query.isSearchOnDefaultField()) {
sQuery.setParam("qf", queryFields.toArray(new
String[queryFields.size()]));
}
sQuery.
I think you nailed it, Hoss. What I did is I regenerated the indices and made
sure that they were inline with he schema definitions and it works perfectly
now.
One curious thing is that if there was a mismatch with the schema, why would
a direct query to one of the shards work just fine while the
: Now in my case the indices are being built outside of Solr. So basically I
: create three sets of indices through Lucene API's. And at this point, I
: change the schema.xml and define the fields I have in these new indices. I
do you define a uniqueKey field in your schema.xml? does that field
Sure. So it is really simple. Following the Solr example for setting up two
shards and pushing some xml docs to each one and then doing a distributed
query (http://wiki.apache.org/solr/DistributedSearch), it works perfectly.
Now in my case the indices are being built outside of Solr. So basically I
You need to provide the relevant bits of your configuration
file for anyone to help I think In particular the
sharding-relevant configurations.
Best
Erick
On Thu, Jan 26, 2012 at 11:29 AM, ramin wrote:
> Hello,
>
> I've gone through the list and have not found the answer but if it is a
> rep
31 matches
Mail list logo
