Thanks Erick and Upayavira! This answers my question.
On Mon, Dec 17, 2012 at 8:05 AM, Erick Erickson wrote:
> See the very last line here:
> http://wiki.apache.org/solr/MergingSolrIndexes
>
> Short answer is that merging will lead to duplicate documents, even with
> uniqueKeys defined.
>
> So y
See the very last line here: http://wiki.apache.org/solr/MergingSolrIndexes
Short answer is that merging will lead to duplicate documents, even with
uniqueKeys defined.
So you're really kind of stuck handling this outside of merge, either by
shipping the
list of overwritten docs and deleting them
I guess without knowing more about the usecase, it is difficult to see
whether it is best to ship pre-prepared indexes or indexable content.
Certainly the latter would be far simpler, and more in-keeping with the
way Solr is typically used, and personally I'd start with that.
Thinking through what
Yes, we have an uniqueId defined but merge adds two documents with the same
id. As per my understanding this is how Solr behaves. Correct me if am
wrong.
On Fri, Dec 14, 2012 at 2:25 AM, Alexandre Rafalovitch
wrote:
> Do you have IDs defined? How do you expect Sold to know they are duplicate
> re
Do you have IDs defined? How do you expect Sold to know they are duplicate
records? Maybe the issue is there somewhere.
Regards,
Alex
On 13 Dec 2012 15:17, "Dikchant Sahi" wrote:
> Hi Alex,
>
> You got my point right. What I see is merge adds duplicate document. Is
> there a way to overwrit
Hi Alex,
You got my point right. What I see is merge adds duplicate document. Is
there a way to overwrite existing document in one core by another. Can
merge operation lead to data corruption, say in case when the core on
client had uncommitted changes.
What would be a better solution for my requ
Not sure I fully understood this and maybe you already cover that by
'merge', but if you know what you gave the client last time, you can just
build a differential as a second core, then on client mount that second
core and merge it into the first one (e.g. with DIH).
Just a thought.
Regards,
Hi Erick,
Sorry for creating the confusion. By slave, I mean the indexes on client
machine will be replica of the master and in not same as the slave in
master-slave model. Below is the detail:
The system is being developed to support search facility on 1000s of
system, a majority of which will b
This is somewhat confusing. You say that box2 is the slave, yet they're not
connected? Then you need to copy the /data index from box 1 to
box 2 manually (I'd have box2 solr shut down at the time) and restart Solr.
Why can't the boxes be connected? That's a much simpler way of going about
it.
Bes
Hi Walter,
Thanks for the response.
Commit will help to reflect changes on Box1. We are able to achieve this.
We want the changes to reflect in Box2.
We have two indexes. Say
Box1: Master & DB has been setup. Data Import runs on this.
Box2: Slave running.
We want all the updates on Box1 to be m
You do not need to manage online and offline indexes. Commit when you are done
with your updates and Solr will take care of it for you. The changes are not
live until you commit.
wunder
On Dec 10, 2012, at 9:46 PM, Dikchant Sahi wrote:
> Hi,
>
> How can we do delta update of offline indexes?
11 matches
Mail list logo
