On 5/3/2018 12:55 PM, Satya Marivada wrote:
> We have a solr (6.3.0) index which is being re-indexed every night, it
> takes about 6-7 hours for the indexing to complete. During the time of
> re-indexing, the index becomes flaky and would serve inconsistent count of
> documents 70,000 at times and
Yes, we are doing clean and full import. Is it not supposed to serve
old(existing) index till the new index is built and then do a cleanup,
replace old index after new index is built?
Would a full import without clean not give this problem?
Thanks Erick, this would be useful.
On Thu, May 3, 2018
The short for is that different replicas in a shard have different
commit point if you go by wall-clock time. So during heavy indexing,
you can happen to catch the different counts. That really shouldn't
happen, though, unless you're clearing the index first on the
assumption that you're replacing
Hi there,
We have a solr (6.3.0) index which is being re-indexed every night, it
takes about 6-7 hours for the indexing to complete. During the time of
re-indexing, the index becomes flaky and would serve inconsistent count of
documents 70,000 at times and 80,000 at times. After the indexing is
co
I'm not sure if that method is viable for reindexing and fetching the whole
collection at once for us, but unless there is something inherent in that
process which happens at the collection level, we could do it a few shards
at a time since it is a multi-tenant setup.
I'll see if we can setup a sm
(1) It doesn't matter whether it "affect only segments being merged".
You can't get accurate information if different segments have
different expectations.
(2) I strongly doubt it. The problem is that the "tainted" segments'
meta-data is still read when merging. If the segment consisted of
_only_
We tested the query on all replicas for the given shard, and they all have
the same issue. So deleting and adding another replica won't fix the
problem since the leader is exhibiting the behavior as well. I believe the
second replica was moved (new one added, old one deleted) between nodes and
so w
Never mind. Anything that didn't merge old segments, just threw them
away when empty (which was my idea) would possibly require as much
disk space as the index currently occupied, so doesn't help your
disk-constrained situation.
Best,
Erick
On Thu, Oct 12, 2017 at 8:06 AM, Erick Erickson wrote:
If it's _only_ on a particular replica, here's what you could do:
Just DELETEREPLICA on it, then ADDREPLICA to bring it back. You can
define the "node" parameter on ADDREPLICA to get it back on the same
node. Then the normal replication process would pull the entire index
down from the leader.
My
I thought that decision would come back to bite us somehow. At the time, we
didn't have enough space available to do a fresh reindex alongside the old
collection, so the only course of action available was to index over the
old one, and the vast majority of its use worked as expected.
We're planni
bq: ...but the collection wasn't emptied first
This is what I'd suspect is the problem. Here's the issue: Segments
aren't merged identically on all replicas. So at some point you had
this field indexed without docValues, changed that and re-indexed. But
the segment merging could "read" the fir
Hi,
We've run into a strange issue with our deployment of solrcloud 6.3.0.
Essentially, a standard facet query on a string field usually comes back
empty when it shouldn't. However, every now and again the query actually
returns the correct values. This is only affecting a single shard in our
setu
t;>
>>> d.) I dont find any errors in the logs. All warnings only.
>>>
>>> On 14/08/16 02:56, Jan Høydahl wrote:
>>>> Could it be that your cluster is not in sync, so that when Solr picks
>>>> three nodes, results will vary depending on what r
re any errors in the logs?
If possible, please share some queries, responses, config, screenshots etc.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
13. aug. 2016 kl. 12.10 skrev Pranaya Behera :
Hi,
I am running solr 6.1.0 with solrcloud. We have 3 instance of
only one
>> query and sorting?
>> d) Are there any errors in the logs?
>>
>> If possible, please share some queries, responses, config, screenshots etc.
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>
at are you querying on and sorting by? Does it happen with only one query
and sorting?
d) Are there any errors in the logs?
If possible, please share some queries, responses, config, screenshots etc.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
13. aug. 2016 kl.
; collection has 3 shards, each shard has 2 replicas.
>
> Everytime query whether from solrj or admin ui, getting inconsistent results.
> e.g.
> 1. numFound is always fluctuating.
> 2. facet count shows the count for a field, filter query on that field gets 0
> results.
> 3. lu
has 3 shards, each shard has 2 replicas.
>
> Everytime query whether from solrj or admin ui, getting inconsistent
> results. e.g.
> 1. numFound is always fluctuating.
> 2. facet count shows the count for a field, filter query on that field gets
> 0 results.
> 3. luke req
nstance of solrcloud. All three of them are active and up. One
collection has 3 shards, each shard has 2 replicas.
Everytime query whether from solrj or admin ui, getting inconsistent
results. e.g.
1. numFound is always fluctuating.
2. facet count shows the count for a field, filter query on that fi
6.1.0 with solrcloud. We have 3 instance of zookeeper
and 3 instance of solrcloud. All three of them are active and up. One
collection has 3 shards, each shard has 2 replicas.
Everytime query whether from solrj or admin ui, getting inconsistent
results. e.g.
1. numFound is always fluctuating.
2. f
has 3 shards, each shard has 2 replicas.
Everytime query whether from solrj or admin ui, getting inconsistent
results. e.g.
1. numFound is always fluctuating.
2. facet count shows the count for a field, filter query on that field
gets 0 results.
3. luke requests work(not sure whether gives correct
time query whether from solrj or admin ui, getting inconsistent
> results. e.g.
> 1. numFound is always fluctuating.
> 2. facet count shows the count for a field, filter query on that field
> gets 0 results.
> 3. luke requests work(not sure whether gives correct info of all the
>
Hi,
I am running solr 6.1.0 with solrcloud. We have 3 instance of
zookeeper and 3 instance of solrcloud. All three of them are active and
up. One collection has 3 shards, each shard has 2 replicas.
Everytime query whether from solrj or admin ui, getting inconsistent
results. e.g.
1
Hi Mary,
Yes the field used for grouping is stored=true.
Thanks
Preeti
On Wed, May 25, 2016 at 7:04 PM, Mary White wrote:
> Hi Preeti,
>
> Do you have stored=true on the field you are trying to query?
>
> Sent from my iPhone
>
> > On May 25, 2016, at 8:30 AM, preeti kumari
> wrote:
> >
> > Th
Hi Preeti,
Do you have stored=true on the field you are trying to query?
Sent from my iPhone
> On May 25, 2016, at 8:30 AM, preeti kumari wrote:
>
> Thanks Jeff. Let me try this .I was actually looking for a way without doc
> routing.
> Do let me know if I can handle grouping through queries.
Thanks Jeff. Let me try this .I was actually looking for a way without doc
routing.
Do let me know if I can handle grouping through queries.
Thanks
Preeti
On Tue, May 24, 2016 at 2:08 AM, Jeff Wartes wrote:
> My first thought is that you haven’t indexed such that all values of the
> field you’
My first thought is that you haven’t indexed such that all values of the field
you’re grouping on are found in the same cores.
See the end of the article here: (Distributed Result Grouping Caveats)
https://cwiki.apache.org/confluence/display/solr/Result+Grouping
And the “Document Routing” sectio
Hi All,
I am using grouping query with solr cloud version 5.2.1 .
Parameters added in my query is
&q=SIM*group=true&group.field=amid&group.limit=1&group.main=true. But each
time I hit the query i get different results i.e top 10 results are
different each time.
Why is it so ? Please help me with
Hi,
I am new to the solr community and I am sorry if this is not the right medium
to bring the issue to notice. I have found following issue :
https://issues.apache.org/jira/browse/SOLR-7452 as mentioned in the subject and
raised a ticket for the same.
Any help is appreciated!
Sent from my
I´m getting inconsistent results in a distributed configuration.
Using stats command over a single core containing about 3 milion docs I´ve
got 452660794509326.7 (a double type field).
On the other hand, when partitioning the data into 2 or 4 cores I am getting
a different result
changes detected
in the source data - a relational database.
Could anyone provide some insight on this inconsistent behavior? Why would
solr produce two different results for the same query?
--
View this message in context:
http://lucene.472066.n3.nabble.com/SOLR-inconsistent-results-tp4035888
That idea was short lived. I excluded the document. The cluster isn't
syncing even after shutting everything down and restarting.
On Sun, Mar 18, 2012 at 2:58 PM, Matthew Parker <
mpar...@apogeeintegration.com> wrote:
> I had tried importing data from Manifold, and one document threw a Tika
> Exc
I had tried importing data from Manifold, and one document threw a Tika
Exception.
If I shut everything down and restart SOLR cloud, the system sync'd on
startup.
Could extraction errors be the issue?
On Sun, Mar 18, 2012 at 2:50 PM, Matthew Parker <
mpar...@apogeeintegration.com> wrote:
> I h
I have nodes running on ports: 8081-8084
A couple of the other SOLR cloud nodes we complaining about not being talk
with 8081, which is the first node brought up in the cluster.
The startup process is:
1. start 3 zookeeper nodes
2. wait until complete
3. start first solr node.
4. wait until c
I think he's asking if all the nodes (same machine or not) return a
response. Presumably you have different ports for each node since they
are on the same machine.
On Sun, 2012-03-18 at 14:44 -0400, Matthew Parker wrote:
> The cluster is running on one machine.
>
> On Sun, Mar 18, 2012 at 2:07 PM
The cluster is running on one machine.
On Sun, Mar 18, 2012 at 2:07 PM, Mark Miller wrote:
> From every node in your cluster you can hit http://MACHINE1:8084/solr in
> your browser and get a response?
>
> On Mar 18, 2012, at 1:46 PM, Matthew Parker wrote:
>
> > My cloud instance finally tried to
From every node in your cluster you can hit http://MACHINE1:8084/solr in your
browser and get a response?
On Mar 18, 2012, at 1:46 PM, Matthew Parker wrote:
> My cloud instance finally tried to sync. It looks like it's having connection
> issues, but I can bring the SOLR instance up in the brow
This might explain another thing I'm seeing. If I take a node down,
clusterstate.json still shows it as active. Also if I'm running 4 nodes,
take one down and assign it a new port, clusterstate.json will show 5 nodes
running.
On Sat, Mar 17, 2012 at 10:10 PM, Mark Miller wrote:
> Nodes talk to Z
Nodes talk to ZooKeeper as well as to each other. You can see the addresses
they are trying to use to communicate with each other in the 'cloud' view of
the Solr Admin UI. Sometimes you have to override these, as the detected
default may not be an address that other nodes can reach. As a limited
I'm still having issues replicating in my work environment. Can anyone
explain how the replication mechanism works? Is it communicating across
ports or through zookeeper to manager the process?
On Thu, Mar 8, 2012 at 10:57 PM, Matthew Parker <
mpar...@apogeeintegration.com> wrote:
> All,
>
> I
All,
I recreated the cluster on my machine at home (Windows 7, Java 1.6.0.23,
apache-solr-4.0-2012-02-29_09-07-30) , sent some document through Manifold
using its crawler, and it looks like it's replicating fine once the
documents are committed.
This must be related to my environment somehow. Tha
I've ensured the SOLR data subdirectories and files were completed cleaned
out, but the issue still occurs.
On Fri, Mar 2, 2012 at 9:06 AM, Erick Erickson wrote:
> Matt:
>
> Just for paranoia's sake, when I was playing around with this (the
> _version_ thing was one of my problems too) I removed
Matt:
Just for paranoia's sake, when I was playing around with this (the
_version_ thing was one of my problems too) I removed the entire data
directory as well as the zoo_data directory between experiments (and
recreated just the data dir). This included various index.2012
files and the tlog
> I assuming the windows configuration looked correct?
Yeah, so far I can not spot any smoking gun...I'm confounded at the moment.
I'll re read through everything once more...
- Mark
he zookeeper instances:
> >>>>>>
> >>>>>> start .\zookeeper1\bin\zkServer.cmd
> >>>>>> start .\zookeeper2\bin\zkServer.cmd
> >>>>>> start .\zookeeper3\bin\zkServer.cmd
> >>>>>>
> >>>>>> St
localhost:2183 -jar
> start.jar
> > > >>>
> > > >>> Starts up fine.
> > > >>>
> > > >>> Step 5 - Start the Remaining 3 SOLR Instances
> > > >>> ==
> > > >&g
t;> I ran the following command to start the main SOLR instance
>>>>>>
>>>>>> java -Djetty.port=8081 -Dhostport=8081
>>>>>> -Dbootstrap_configdir=[DATA_DIRECTORY]/solr/conf -Dnumshards=2
>>>>>> -Dzkhost=localhost
> > >>> I ran the following commands to start the other 3 instances from their
> > >>> home directories:
> > >>>
> > >>> java -Djetty.port=8082 -Dhostport=8082
> > >>> -Dzkhost=localhost:2181,localhost:2182,localhost:
heir
> > >>> home directories:
> > >>>
> > >>> java -Djetty.port=8082 -Dhostport=8082
> > >>> -Dzkhost=localhost:2181,localhost:2182,localhost:2183 -jar start.jar
> > >>>
> > >>> java -Djetty.port=8083 -Dhostpor
ocalhost:2182,localhost:2183 -jar start.jar
> >>>
> >>> java -Djetty.port=8084 -Dhostport=8084
> >>> -Dzkhost=localhost:2181,localhost:2182,localhost:2183 -jar start.jar
> >>>
> >>> All startup without issue.
> >>>
&g
-Dzkhost=localhost:2181,localhost:2182,localhost:2183 -jar start.jar
>>>
>>> All startup without issue.
>>>
>>> Step 6 - Modified solrconfig.xml to have a custom request handler
>>> =======
>>>
>>&g
Sami,
I have the latest as of the 26th. My system is running on a standalone
network so it's not easy to get code updates without a wave of paperwork.
I installed as per the detailed instructions I laid out a couple of
messages ago from today (2/29/2012).
I'm running the following query:
http:/
On Wed, Feb 29, 2012 at 7:03 PM, Matthew Parker
wrote:
> I also took out my requestHandler and used the standard /update/extract
> handler. Same result.
How did you install/start the system this time? The same way as
earlier? What kind of queries do you run?
Would it be possible for you to check
sharepoint-pipeline
>> text
>> true
>> ignored
>> true
>> links
>> ignored
>>
>>
>>
>>
>>
>> true
>> id
>> true
>> url
>> solr.proces
; Thanks for your help.
>
> Matt
>
>
>
> On Tue, Feb 28, 2012 at 8:29 PM, Mark Miller wrote:
>
>> Hmm...this is very strange - there is nothing interesting in any of the
>> logs?
>>
>> In clusterstate.json, all of the shards have an active state?
>>
something we are missing here...
>
> Any info you can offer might help.
>
> - Mark
>
> On Feb 28, 2012, at 1:00 PM, Matthew Parker wrote:
>
> > Mark,
> >
> > I got the codebase from the 2/26/2012, and I got the same inconsistent
> > results.
> >
>
.
- Mark
On Feb 28, 2012, at 1:00 PM, Matthew Parker wrote:
> Mark,
>
> I got the codebase from the 2/26/2012, and I got the same inconsistent
> results.
>
> I have solr running on four ports 8081-8084
>
> 8081 and 8082 are the leaders for shard 1, and shard 2, respectively
&g
Mark,
I got the codebase from the 2/26/2012, and I got the same inconsistent
results.
I have solr running on four ports 8081-8084
8081 and 8082 are the leaders for shard 1, and shard 2, respectively
8083 - is assigned to shard 1
8084 - is assigned to shard 2
queries come in and sometime it
I'll have to check on the commit situation. We have been pushing data from
SharePoint the last week or so. Would that somehow block the documents
moving between the solr instances?
I'll try another version tomorrow. Thanks for the suggestions.
On Mon, Feb 27, 2012 at 5:34 PM, Mark Miller wrote:
Hmmm...all of that looks pretty normal...
Did a commit somehow fail on the other machine? When you view the stats for the
update handler, are there a lot of pending adds for on of the nodes? Do the
commit counts match across nodes?
You can also query an individual node with distrib=false to che
Here is most of the cluster state:
Connected to Zookeeper
localhost:2181, localhost: 2182, localhost:2183
/(v=0 children=7) ""
/CONFIGS(v=0, children=1)
/CONFIGURATION(v=0 children=25)
< all the configuration files, velocity info, xslt, etc.
/NODE_STATES(v=0 child
I was trying to use the new interface. I see it using the old admin page.
Is there a piece of it you're interested in? I don't have access to the
Internet where it exists so it would mean transcribing it.
On Mon, Feb 27, 2012 at 2:47 PM, Mark Miller wrote:
>
> On Feb 27, 2012, at 2:22 PM, Matth
On Feb 27, 2012, at 2:22 PM, Matthew Parker wrote:
> Thanks for your reply Mark.
>
> I believe the build was towards the begining of the month. The
> solr.spec.version is 4.0.0.2012.01.10.38.09
>
> I cannot access the clusterstate.json contents. I clicked on it a couple of
> times, but nothing
Thanks for your reply Mark.
I believe the build was towards the begining of the month. The
solr.spec.version is 4.0.0.2012.01.10.38.09
I cannot access the clusterstate.json contents. I clicked on it a couple of
times, but nothing happens. Is that stored on disk somewhere?
I configured a custom r
Hey Matt - is your build recent?
Can you visit the cloud/zookeeper page in the admin and send the contents of
the clusterstate.json node?
Are you using a custom index chain or anything out of the ordinary?
- Mark
On Feb 27, 2012, at 12:26 PM, Matthew Parker wrote:
> TWIMC:
>
> Environment
>
TWIMC:
Environment
=
Apache SOLR rev-1236154
Apache Zookeeper 3.3.4
Windows 7
JDK 1.6.0_23.b05
I have built a SOLR Cloud instance with 4 nodes using the embeded Jetty
servers.
I created a 3 node zookeeper ensemble to manage the solr configuration data.
All the instances run on one serve
>>>
>>> This this would fetch for documents where qua_code fields contains either
>>> the terms 1234567 OR both terms (1234567& 9384738.and others terms).
>>> This would be since its a multivalued field and hence if you see the
>>> facet,
&g
ocuments which have term 1234567 only (facet.query
would apply to the facets,so as to which facet to be picked/shown)
Regds
Pravesh
--
View this message in context:
http://lucene.472066.n3.nabble.com/inconsistent-results-when-faceting-on-multivalued-field-tp3438991p3440128.html
Sent from the Solr - User mailing list archive at Nabble.com.
1234567 only (facet.query
> would apply to the facets,so as to which facet to be picked/shown)
>
> Regds
> Pravesh
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/inconsistent-results-when-faceting-on-multivalued-field-tp3438991p3440128.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
ich have term 1234567 only (facet.query
would apply to the facets,so as to which facet to be picked/shown)
Regds
Pravesh
--
View this message in context:
http://lucene.472066.n3.nabble.com/inconsistent-results-when-faceting-on-multivalued-field-tp3438991p3440128.html
Sent from the Solr - Us
I am surprised by the results I am getting from a search in a Solr 3.4
index.
My schema has a multivalued field of type 'string' :
The field values are 7-digit or 9-digit integer numbers; this corresponds to
a hierarchy. I could have used a numeric type instead of string but no
numerical operat
Yes, it seems to be a bug, at least with the code you and I are using. If
you don't need to search across the whole globe, try translating your
longitudes as I suggested.
On Fri, Feb 12, 2010 at 3:04 PM, Emad Mushtaq
wrote:
> Hello Mauricio,
>
> Do you know why such a problem occurs. Has it to do
Hello Mauricio,
Do you know why such a problem occurs. Has it to do with certain latitudes,
longitudes. If so why is it happening. Is it a bug in local solr?
On Fri, Feb 12, 2010 at 5:50 PM, Mauricio Scheffer <
mauricioschef...@gmail.com> wrote:
> Hi Emad,
>
> I had the same issue (
> http://old
Hi Emad,
I had the same issue (
http://old.nabble.com/Spatial---Local-Solr-radius-td26943608.html ), it
seems that this happens only on eastern areas of the world. Try inverting
the sign of all your longitudes, or translate all your longitudes to the
west.
Cheers,
Mauricio
On Fri, Feb 12, 2010 a
Hello,
I have a question related to local solr. For certain locations (latitude,
longitude), the spatial search does not work. Here is the query I try to
make which gives me no results:
q=*&qt=geo&sort=geo_distance asc&lat=33.718151&long=73.
060547&radius=450
However if I make the same query wit
s d wrote:
Hi,I use SOLR with standard handler and when i send the same exact query to
solr i get different results every time (i.e. refresh the page with the
query and get different results).
Any ideas?
Thx,
what is the query? are there any changes to the index in between?
Check the logs to
Hi,I use SOLR with standard handler and when i send the same exact query to
solr i get different results every time (i.e. refresh the page with the
query and get different results).
Any ideas?
Thx,
I fixed that problem with reconfiguring schema.xml.
Thanks for your help.
Jak
Grant Ingersoll yazmış:
Have you setup your Analyzers, etc. so they correspond to the exact
ones that you were using in Lucene? Under the Solr Admin you can try
the analysis tool to see how your index and queries are
Have you setup your Analyzers, etc. so they correspond to the exact
ones that you were using in Lucene? Under the Solr Admin you can try
the analysis tool to see how your index and queries are treated. What
happens if you do a *:* query from the Admin query screen?
If your index is reason
79 matches
Mail list logo
