You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Harald Kirsch <Ha...@raytion.com> on 2014/07/29 10:39:44 UTC
SolrCloud without NRT and indexing only on the master
Hi all,
from the Solr documentation I find two options how replication of an
indexing is handled:
a) SolrCloud indexes on master and all slaves in parallel to support NRT
(near realtime search)
b) Legacy replication where only the master does the indexing and slave
receive index copies once in a while.
What if I don't need NRT and in particular want the slave to use all
resources for query answering, i.e. only the master shall index. But at
the same time I want all the other benefits of SolrCloud.
Is this setup possible? Is it somewhere described in the docs?
Thanks,
Harald.
Re: SolrCloud without NRT and indexing only on the master
Posted by Erick Erickson <er...@gmail.com>.
Sorry for the confusion between "legacy" and "traditional", it's just
sloppy terminology. There's no sense of "don't use this" with traditional
M/R replication. In fact, when SolrCloud nodes need to catch up with their
indexes if they're very out of sync, this is still used. So it's definitely
supported/maintained, feel free to use it as you see fit.
In (b) above, do note that you're right, copying the segments down is a
background, I/O task. That said, opening a new searcher is as intensive in
that case, perhaps even more so since I don't think that "soft commits"
happen. Note that soft commits are cheaper than hard commits, still not
free though. So you'll gain back some of what you lose in CPU cycles by
indexing through cheaper commit operations.
Under any circumstances, you're right that indexing on each node will add
some load.
You haven't outlined what the indexing load will be, and in (bI) you say
"i) Indexing will draw more than 20% CPU. Thereby it would start competing
with query answering"
I urge you to measure that. If your indexing rate isn't great, this may be
a false assumption. That said,
measuring is the only way to be sure.
And an alternative: Rack a couple more pieces of hardware in the mix and
just use SolrCloud, thus distributing the
query load across a couple of more machines.
But before you even do that, I'd try it and see. Indexing isn't necessarily
that expensive, but it depends of course.
Best,
Erick
On Wed, Jul 30, 2014 at 3:53 AM, Harald Kirsch <Ha...@raytion.com>
wrote:
> Hi Daniel,
>
> well, I assume there is a performance difference on host B between
>
> a) getting some ready-made segments from host A (master, taking care of
> indexing) to host B (slave, taking care of answering queries)
>
> and
>
> b) host B (along with host A) doing all the work necessary to prepare
> incoming SolrDocument objects into a segment and make it searchable.
>
> I am talking here about a setup where during peak loads the CPUs on host B
> are sweating at >80% and I assume the following:
>
> i) Indexing will draw more than 20% CPU. Thereby it would start competing
> with query answering
>
> ii) Merely copying finished segments to the query-answering node will not
> draw more than 20% CPU and will thereby not compete with query answering.
>
> Index consistency is not an issue, because the number of documents and the
> number of different, hard-to-get-at source we will be indexing will always
> be out-of-sync with the index. Adding and hour or two here is the least of
> my problems.
>
> Harald.
>
>
> On 30.07.2014 11:58, Daniel Collins wrote:
>
>> Working backwards slightly, what do you think SolrCloud is going to give
>> you, apart from the consistency of the index (which you want to turn off)?
>> What are "all the other benefits of SolrCloud", if you are querying
>> separate instances that aren't guaranteed to be in sync (since you want to
>> use the traditional-style master-slave for indexing.
>>
>> And secondly, why don't you want to use SolrCloud for indexing everywhere?
>> Again, what do you think master-slave methodology gains you? You have
>> said you want all the resources of the slaves to be for querying, which
>> makes sense, but the slaves have to get the new updates somehow, surely?
>> Whether that is from SolrCloud directly, or via a master-slave
>> replication,
>> the work has to be done at some point?
>>
>> If you don't have NRT, and you set your commit frequency to something
>> reasonably large, then I don't see the "cost" of SolrCloud, but I guess it
>> depends on the frequency of your updates.
>>
>>
>> On 30 July 2014 08:22, Harald Kirsch <Ha...@raytion.com> wrote:
>>
>> Thanks Erick,
>>>
>>> for the confirmation.
>>>
>>> You say "traditional" but the docs call it "legacy". Not a native speaker
>>> I might misinterpret the meaning slightly but to me it conveys the notion
>>> of "don't use this stuff if you don't have to".
>>>
>>>
>>> "SolrCloud indexes to all nodes all the time, there's no real way to turn
>>> that off."
>>>
>>> which is really a pity when only query-load must be scaled and NRT is not
>>> necessary. :-/
>>>
>>> Harald.
>>>
>>>
>>> On 29.07.2014 18:16, Erick Erickson wrote:
>>>
>>> bq: What if I don't need NRT and in particular want the slave to use all
>>>> resources for query answering, i.e. only the master shall index. But at
>>>> the
>>>> same time I want all the other benefits of SolrCloud.
>>>>
>>>> You want all the benefits of SolrCloud without... using SolrCloud?
>>>>
>>>> Your only two choices are traditional master/slave or SolrCloud.
>>>> SolrCloud
>>>> indexes to all nodes all the time, there's no real way to turn that off.
>>>> You _can_ control the frequency of commits but you can't turn off the
>>>> indexing to all the nodes.
>>>>
>>>> FWIW,
>>>> Erick
>>>>
>>>>
>>>> On Tue, Jul 29, 2014 at 5:41 AM, Mikhail Khludnev <
>>>> mkhludnev@griddynamics.com> wrote:
>>>>
>>>> I never did it, but always like.
>>>>
>>>>>
>>>>> http://lucene.472066.n3.nabble.com/Best-practice-for-
>>>>> rebuild-index-in-SolrCloud-td4054574.html
>>>>> From time to time such recipes are mentioned in the list.
>>>>>
>>>>>
>>>>> On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <
>>>>> Harald.Kirsch@raytion.com
>>>>>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>>
>>>>>> from the Solr documentation I find two options how replication of an
>>>>>> indexing is handled:
>>>>>>
>>>>>> a) SolrCloud indexes on master and all slaves in parallel to support
>>>>>> NRT
>>>>>> (near realtime search)
>>>>>>
>>>>>> b) Legacy replication where only the master does the indexing and
>>>>>> slave
>>>>>> receive index copies once in a while.
>>>>>>
>>>>>> What if I don't need NRT and in particular want the slave to use all
>>>>>> resources for query answering, i.e. only the master shall index. But
>>>>>> at
>>>>>>
>>>>>> the
>>>>>
>>>>> same time I want all the other benefits of SolrCloud.
>>>>>>
>>>>>> Is this setup possible? Is it somewhere described in the docs?
>>>>>>
>>>>>> Thanks,
>>>>>> Harald.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sincerely yours
>>>>> Mikhail Khludnev
>>>>> Principal Engineer,
>>>>> Grid Dynamics
>>>>>
>>>>> <http://www.griddynamics.com>
>>>>> <mk...@griddynamics.com>
>>>>>
>>>>>
>>>>>
>>>>
Re: SolrCloud without NRT and indexing only on the master
Posted by "Ramkumar R. Aiyengar" <an...@gmail.com>.
I agree with Erick that this gain you are looking at might not be worth, so
do measure and see if there's a difference.
Also, the next release of Solr is to have some significant improvements
when it comes to CPU usage under heavy indexing load, and we have had at
least one anecdote so far where the throughput has increased by an order of
magnitude, so one option might be to try that out as well and see. See
SOLR-6136 and potentially SOLR-6259 (probably lesser so, depends on your
schema) if you want to try out before the release.
An another option is to use the HDFS directory support in Solr. That way
you can build indices offline and make them available for all your Solr
replicas for search. See batch indexing at
http://www.cloudera.com/content/cloudera-content/cloudera-docs/Search/latest/Cloudera-Search-User-Guide/csug_introducing.html
On 30 Jul 2014 11:54, "Harald Kirsch" <Ha...@raytion.com> wrote:
> Hi Daniel,
>
> well, I assume there is a performance difference on host B between
>
> a) getting some ready-made segments from host A (master, taking care of
> indexing) to host B (slave, taking care of answering queries)
>
> and
>
> b) host B (along with host A) doing all the work necessary to prepare
> incoming SolrDocument objects into a segment and make it searchable.
>
> I am talking here about a setup where during peak loads the CPUs on host B
> are sweating at >80% and I assume the following:
>
> i) Indexing will draw more than 20% CPU. Thereby it would start competing
> with query answering
>
> ii) Merely copying finished segments to the query-answering node will not
> draw more than 20% CPU and will thereby not compete with query answering.
>
> Index consistency is not an issue, because the number of documents and the
> number of different, hard-to-get-at source we will be indexing will always
> be out-of-sync with the index. Adding and hour or two here is the least of
> my problems.
>
> Harald.
>
> On 30.07.2014 11:58, Daniel Collins wrote:
>
>> Working backwards slightly, what do you think SolrCloud is going to give
>> you, apart from the consistency of the index (which you want to turn off)?
>> What are "all the other benefits of SolrCloud", if you are querying
>> separate instances that aren't guaranteed to be in sync (since you want to
>> use the traditional-style master-slave for indexing.
>>
>> And secondly, why don't you want to use SolrCloud for indexing everywhere?
>> Again, what do you think master-slave methodology gains you? You have
>> said you want all the resources of the slaves to be for querying, which
>> makes sense, but the slaves have to get the new updates somehow, surely?
>> Whether that is from SolrCloud directly, or via a master-slave
>> replication,
>> the work has to be done at some point?
>>
>> If you don't have NRT, and you set your commit frequency to something
>> reasonably large, then I don't see the "cost" of SolrCloud, but I guess it
>> depends on the frequency of your updates.
>>
>>
>> On 30 July 2014 08:22, Harald Kirsch <Ha...@raytion.com> wrote:
>>
>> Thanks Erick,
>>>
>>> for the confirmation.
>>>
>>> You say "traditional" but the docs call it "legacy". Not a native speaker
>>> I might misinterpret the meaning slightly but to me it conveys the notion
>>> of "don't use this stuff if you don't have to".
>>>
>>>
>>> "SolrCloud indexes to all nodes all the time, there's no real way to turn
>>> that off."
>>>
>>> which is really a pity when only query-load must be scaled and NRT is not
>>> necessary. :-/
>>>
>>> Harald.
>>>
>>>
>>> On 29.07.2014 18:16, Erick Erickson wrote:
>>>
>>> bq: What if I don't need NRT and in particular want the slave to use all
>>>> resources for query answering, i.e. only the master shall index. But at
>>>> the
>>>> same time I want all the other benefits of SolrCloud.
>>>>
>>>> You want all the benefits of SolrCloud without... using SolrCloud?
>>>>
>>>> Your only two choices are traditional master/slave or SolrCloud.
>>>> SolrCloud
>>>> indexes to all nodes all the time, there's no real way to turn that off.
>>>> You _can_ control the frequency of commits but you can't turn off the
>>>> indexing to all the nodes.
>>>>
>>>> FWIW,
>>>> Erick
>>>>
>>>>
>>>> On Tue, Jul 29, 2014 at 5:41 AM, Mikhail Khludnev <
>>>> mkhludnev@griddynamics.com> wrote:
>>>>
>>>> I never did it, but always like.
>>>>
>>>>>
>>>>> http://lucene.472066.n3.nabble.com/Best-practice-for-
>>>>> rebuild-index-in-SolrCloud-td4054574.html
>>>>> From time to time such recipes are mentioned in the list.
>>>>>
>>>>>
>>>>> On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <
>>>>> Harald.Kirsch@raytion.com
>>>>>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>>
>>>>>> from the Solr documentation I find two options how replication of an
>>>>>> indexing is handled:
>>>>>>
>>>>>> a) SolrCloud indexes on master and all slaves in parallel to support
>>>>>> NRT
>>>>>> (near realtime search)
>>>>>>
>>>>>> b) Legacy replication where only the master does the indexing and
>>>>>> slave
>>>>>> receive index copies once in a while.
>>>>>>
>>>>>> What if I don't need NRT and in particular want the slave to use all
>>>>>> resources for query answering, i.e. only the master shall index. But
>>>>>> at
>>>>>>
>>>>>> the
>>>>>
>>>>> same time I want all the other benefits of SolrCloud.
>>>>>>
>>>>>> Is this setup possible? Is it somewhere described in the docs?
>>>>>>
>>>>>> Thanks,
>>>>>> Harald.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sincerely yours
>>>>> Mikhail Khludnev
>>>>> Principal Engineer,
>>>>> Grid Dynamics
>>>>>
>>>>> <http://www.griddynamics.com>
>>>>> <mk...@griddynamics.com>
>>>>>
>>>>>
>>>>>
>>>>
Re: SolrCloud without NRT and indexing only on the master
Posted by Harald Kirsch <Ha...@raytion.com>.
Hi Daniel,
well, I assume there is a performance difference on host B between
a) getting some ready-made segments from host A (master, taking care of
indexing) to host B (slave, taking care of answering queries)
and
b) host B (along with host A) doing all the work necessary to prepare
incoming SolrDocument objects into a segment and make it searchable.
I am talking here about a setup where during peak loads the CPUs on host
B are sweating at >80% and I assume the following:
i) Indexing will draw more than 20% CPU. Thereby it would start
competing with query answering
ii) Merely copying finished segments to the query-answering node will
not draw more than 20% CPU and will thereby not compete with query
answering.
Index consistency is not an issue, because the number of documents and
the number of different, hard-to-get-at source we will be indexing will
always be out-of-sync with the index. Adding and hour or two here is the
least of my problems.
Harald.
On 30.07.2014 11:58, Daniel Collins wrote:
> Working backwards slightly, what do you think SolrCloud is going to give
> you, apart from the consistency of the index (which you want to turn off)?
> What are "all the other benefits of SolrCloud", if you are querying
> separate instances that aren't guaranteed to be in sync (since you want to
> use the traditional-style master-slave for indexing.
>
> And secondly, why don't you want to use SolrCloud for indexing everywhere?
> Again, what do you think master-slave methodology gains you? You have
> said you want all the resources of the slaves to be for querying, which
> makes sense, but the slaves have to get the new updates somehow, surely?
> Whether that is from SolrCloud directly, or via a master-slave replication,
> the work has to be done at some point?
>
> If you don't have NRT, and you set your commit frequency to something
> reasonably large, then I don't see the "cost" of SolrCloud, but I guess it
> depends on the frequency of your updates.
>
>
> On 30 July 2014 08:22, Harald Kirsch <Ha...@raytion.com> wrote:
>
>> Thanks Erick,
>>
>> for the confirmation.
>>
>> You say "traditional" but the docs call it "legacy". Not a native speaker
>> I might misinterpret the meaning slightly but to me it conveys the notion
>> of "don't use this stuff if you don't have to".
>>
>>
>> "SolrCloud indexes to all nodes all the time, there's no real way to turn
>> that off."
>>
>> which is really a pity when only query-load must be scaled and NRT is not
>> necessary. :-/
>>
>> Harald.
>>
>>
>> On 29.07.2014 18:16, Erick Erickson wrote:
>>
>>> bq: What if I don't need NRT and in particular want the slave to use all
>>> resources for query answering, i.e. only the master shall index. But at
>>> the
>>> same time I want all the other benefits of SolrCloud.
>>>
>>> You want all the benefits of SolrCloud without... using SolrCloud?
>>>
>>> Your only two choices are traditional master/slave or SolrCloud. SolrCloud
>>> indexes to all nodes all the time, there's no real way to turn that off.
>>> You _can_ control the frequency of commits but you can't turn off the
>>> indexing to all the nodes.
>>>
>>> FWIW,
>>> Erick
>>>
>>>
>>> On Tue, Jul 29, 2014 at 5:41 AM, Mikhail Khludnev <
>>> mkhludnev@griddynamics.com> wrote:
>>>
>>> I never did it, but always like.
>>>>
>>>> http://lucene.472066.n3.nabble.com/Best-practice-for-
>>>> rebuild-index-in-SolrCloud-td4054574.html
>>>> From time to time such recipes are mentioned in the list.
>>>>
>>>>
>>>> On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <
>>>> Harald.Kirsch@raytion.com
>>>>
>>>>>
>>>>> wrote:
>>>>
>>>> Hi all,
>>>>>
>>>>> from the Solr documentation I find two options how replication of an
>>>>> indexing is handled:
>>>>>
>>>>> a) SolrCloud indexes on master and all slaves in parallel to support NRT
>>>>> (near realtime search)
>>>>>
>>>>> b) Legacy replication where only the master does the indexing and slave
>>>>> receive index copies once in a while.
>>>>>
>>>>> What if I don't need NRT and in particular want the slave to use all
>>>>> resources for query answering, i.e. only the master shall index. But at
>>>>>
>>>> the
>>>>
>>>>> same time I want all the other benefits of SolrCloud.
>>>>>
>>>>> Is this setup possible? Is it somewhere described in the docs?
>>>>>
>>>>> Thanks,
>>>>> Harald.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sincerely yours
>>>> Mikhail Khludnev
>>>> Principal Engineer,
>>>> Grid Dynamics
>>>>
>>>> <http://www.griddynamics.com>
>>>> <mk...@griddynamics.com>
>>>>
>>>>
>>>
Re: SolrCloud without NRT and indexing only on the master
Posted by Daniel Collins <da...@gmail.com>.
Working backwards slightly, what do you think SolrCloud is going to give
you, apart from the consistency of the index (which you want to turn off)?
What are "all the other benefits of SolrCloud", if you are querying
separate instances that aren't guaranteed to be in sync (since you want to
use the traditional-style master-slave for indexing.
And secondly, why don't you want to use SolrCloud for indexing everywhere?
Again, what do you think master-slave methodology gains you? You have
said you want all the resources of the slaves to be for querying, which
makes sense, but the slaves have to get the new updates somehow, surely?
Whether that is from SolrCloud directly, or via a master-slave replication,
the work has to be done at some point?
If you don't have NRT, and you set your commit frequency to something
reasonably large, then I don't see the "cost" of SolrCloud, but I guess it
depends on the frequency of your updates.
On 30 July 2014 08:22, Harald Kirsch <Ha...@raytion.com> wrote:
> Thanks Erick,
>
> for the confirmation.
>
> You say "traditional" but the docs call it "legacy". Not a native speaker
> I might misinterpret the meaning slightly but to me it conveys the notion
> of "don't use this stuff if you don't have to".
>
>
> "SolrCloud indexes to all nodes all the time, there's no real way to turn
> that off."
>
> which is really a pity when only query-load must be scaled and NRT is not
> necessary. :-/
>
> Harald.
>
>
> On 29.07.2014 18:16, Erick Erickson wrote:
>
>> bq: What if I don't need NRT and in particular want the slave to use all
>> resources for query answering, i.e. only the master shall index. But at
>> the
>> same time I want all the other benefits of SolrCloud.
>>
>> You want all the benefits of SolrCloud without... using SolrCloud?
>>
>> Your only two choices are traditional master/slave or SolrCloud. SolrCloud
>> indexes to all nodes all the time, there's no real way to turn that off.
>> You _can_ control the frequency of commits but you can't turn off the
>> indexing to all the nodes.
>>
>> FWIW,
>> Erick
>>
>>
>> On Tue, Jul 29, 2014 at 5:41 AM, Mikhail Khludnev <
>> mkhludnev@griddynamics.com> wrote:
>>
>> I never did it, but always like.
>>>
>>> http://lucene.472066.n3.nabble.com/Best-practice-for-
>>> rebuild-index-in-SolrCloud-td4054574.html
>>> From time to time such recipes are mentioned in the list.
>>>
>>>
>>> On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <
>>> Harald.Kirsch@raytion.com
>>>
>>>>
>>>> wrote:
>>>
>>> Hi all,
>>>>
>>>> from the Solr documentation I find two options how replication of an
>>>> indexing is handled:
>>>>
>>>> a) SolrCloud indexes on master and all slaves in parallel to support NRT
>>>> (near realtime search)
>>>>
>>>> b) Legacy replication where only the master does the indexing and slave
>>>> receive index copies once in a while.
>>>>
>>>> What if I don't need NRT and in particular want the slave to use all
>>>> resources for query answering, i.e. only the master shall index. But at
>>>>
>>> the
>>>
>>>> same time I want all the other benefits of SolrCloud.
>>>>
>>>> Is this setup possible? Is it somewhere described in the docs?
>>>>
>>>> Thanks,
>>>> Harald.
>>>>
>>>>
>>>
>>>
>>> --
>>> Sincerely yours
>>> Mikhail Khludnev
>>> Principal Engineer,
>>> Grid Dynamics
>>>
>>> <http://www.griddynamics.com>
>>> <mk...@griddynamics.com>
>>>
>>>
>>
> --
> Harald Kirsch
> Raytion GmbH
> Kaiser-Friedrich-Ring 74
> 40547 Duesseldorf
> Fon +49 211 53883-216
> Fax +49-211-550266-19
> http://www.raytion.com
>
Re: SolrCloud without NRT and indexing only on the master
Posted by Harald Kirsch <Ha...@raytion.com>.
Thanks Erick,
for the confirmation.
You say "traditional" but the docs call it "legacy". Not a native
speaker I might misinterpret the meaning slightly but to me it conveys
the notion of "don't use this stuff if you don't have to".
"SolrCloud indexes to all nodes all the time, there's no real way to
turn that off."
which is really a pity when only query-load must be scaled and NRT is
not necessary. :-/
Harald.
On 29.07.2014 18:16, Erick Erickson wrote:
> bq: What if I don't need NRT and in particular want the slave to use all
> resources for query answering, i.e. only the master shall index. But at the
> same time I want all the other benefits of SolrCloud.
>
> You want all the benefits of SolrCloud without... using SolrCloud?
>
> Your only two choices are traditional master/slave or SolrCloud. SolrCloud
> indexes to all nodes all the time, there's no real way to turn that off.
> You _can_ control the frequency of commits but you can't turn off the
> indexing to all the nodes.
>
> FWIW,
> Erick
>
>
> On Tue, Jul 29, 2014 at 5:41 AM, Mikhail Khludnev <
> mkhludnev@griddynamics.com> wrote:
>
>> I never did it, but always like.
>>
>> http://lucene.472066.n3.nabble.com/Best-practice-for-rebuild-index-in-SolrCloud-td4054574.html
>> From time to time such recipes are mentioned in the list.
>>
>>
>> On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <Harald.Kirsch@raytion.com
>>>
>> wrote:
>>
>>> Hi all,
>>>
>>> from the Solr documentation I find two options how replication of an
>>> indexing is handled:
>>>
>>> a) SolrCloud indexes on master and all slaves in parallel to support NRT
>>> (near realtime search)
>>>
>>> b) Legacy replication where only the master does the indexing and slave
>>> receive index copies once in a while.
>>>
>>> What if I don't need NRT and in particular want the slave to use all
>>> resources for query answering, i.e. only the master shall index. But at
>> the
>>> same time I want all the other benefits of SolrCloud.
>>>
>>> Is this setup possible? Is it somewhere described in the docs?
>>>
>>> Thanks,
>>> Harald.
>>>
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>>
>> <http://www.griddynamics.com>
>> <mk...@griddynamics.com>
>>
>
--
Harald Kirsch
Raytion GmbH
Kaiser-Friedrich-Ring 74
40547 Duesseldorf
Fon +49 211 53883-216
Fax +49-211-550266-19
http://www.raytion.com
Re: SolrCloud without NRT and indexing only on the master
Posted by Erick Erickson <er...@gmail.com>.
bq: What if I don't need NRT and in particular want the slave to use all
resources for query answering, i.e. only the master shall index. But at the
same time I want all the other benefits of SolrCloud.
You want all the benefits of SolrCloud without... using SolrCloud?
Your only two choices are traditional master/slave or SolrCloud. SolrCloud
indexes to all nodes all the time, there's no real way to turn that off.
You _can_ control the frequency of commits but you can't turn off the
indexing to all the nodes.
FWIW,
Erick
On Tue, Jul 29, 2014 at 5:41 AM, Mikhail Khludnev <
mkhludnev@griddynamics.com> wrote:
> I never did it, but always like.
>
> http://lucene.472066.n3.nabble.com/Best-practice-for-rebuild-index-in-SolrCloud-td4054574.html
> From time to time such recipes are mentioned in the list.
>
>
> On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <Harald.Kirsch@raytion.com
> >
> wrote:
>
> > Hi all,
> >
> > from the Solr documentation I find two options how replication of an
> > indexing is handled:
> >
> > a) SolrCloud indexes on master and all slaves in parallel to support NRT
> > (near realtime search)
> >
> > b) Legacy replication where only the master does the indexing and slave
> > receive index copies once in a while.
> >
> > What if I don't need NRT and in particular want the slave to use all
> > resources for query answering, i.e. only the master shall index. But at
> the
> > same time I want all the other benefits of SolrCloud.
> >
> > Is this setup possible? Is it somewhere described in the docs?
> >
> > Thanks,
> > Harald.
> >
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> <http://www.griddynamics.com>
> <mk...@griddynamics.com>
>
Re: SolrCloud without NRT and indexing only on the master
Posted by Mikhail Khludnev <mk...@griddynamics.com>.
I never did it, but always like.
http://lucene.472066.n3.nabble.com/Best-practice-for-rebuild-index-in-SolrCloud-td4054574.html
>From time to time such recipes are mentioned in the list.
On Tue, Jul 29, 2014 at 12:39 PM, Harald Kirsch <Ha...@raytion.com>
wrote:
> Hi all,
>
> from the Solr documentation I find two options how replication of an
> indexing is handled:
>
> a) SolrCloud indexes on master and all slaves in parallel to support NRT
> (near realtime search)
>
> b) Legacy replication where only the master does the indexing and slave
> receive index copies once in a while.
>
> What if I don't need NRT and in particular want the slave to use all
> resources for query answering, i.e. only the master shall index. But at the
> same time I want all the other benefits of SolrCloud.
>
> Is this setup possible? Is it somewhere described in the docs?
>
> Thanks,
> Harald.
>
--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics
<http://www.griddynamics.com>
<mk...@griddynamics.com>