: > This is a relatively safe assumption in most cases, but one that couples the
: > master update policy with the performance of the slaves - if the master gets
: > updated (and committed to) frequently, slaves might face a commit on every
: > 1-2 poll's, much more than is feasible given new sear
e snapinstall on each at the same time (+- epsilon
>>>>>>>> seconds),
>>>>>>>> so that way production load balanced query serving will always be
>>>>>>>> consistent.
>>>&g
ms that i have no control over syncing them,
>>>>>>> but
>>>>>>> rather it polls every few minutes and then decides the next cycle based
>>>>>>> on
>>>>>>> last time it *finished* updating, so in any c
On Fri, Aug 14, 2009 at 11:53 AM, Jibo John wrote:
> Slightly off topic one question on the index file transfer mechanism
> used in the new 1.4 Replication scheme.
> Is my understanding correct that the transfer is over http? (vs. rsync in
> the script-based snappuller)
Yes, that's correct.
har Mangar.
--
View this message in context:
http://www.nabble.com/Solr-1.4-Replication-scheme-tp24965590p24968105.html
Sent from the Solr - User mailing list archive at Nabble.com.
--
-
Noble Paul | Principal Engineer| AOL | http
t;>
>>>>> That is true. How did you synchronize them with the script based
>>>>> solution?
>>>>> Assuming network bandwidth is equally distributed and all slaves are
>>>>> equal
>>>>> in hardware/configuration, the
between new searcher
>>>> registration on any slave should not be more then pollInterval, no?
>>>>
>>>>
>>>>>
>>>>> Also, I noticed the default poll interval is 60 seconds. It would seem
>>>>> that
>>>>&
issue,
>>>> however
>>>> i
>>>> am not clear how this works vis-a-vis the new searcher warmup? for a
>>>> considerable index size (20Million docs+) the warmup itself is an
>>>> expensive
>>>> and somewhat lengthy process and if
sive
>>> and somewhat lengthy process and if a new searcher opens and warms up
>>> every
>>> minute, I am not at all sure i'll be able to serve queries with
>>> reasonable
>>> QTimes.
>>>
&g
not mean that a new index is
> fetched every 60 seconds. A new index is downloaded and installed on the
> slave only if a commit happened on the master (i.e. the index was actually
> changed on the master).
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
>
--
View this message in context:
http://www.nabble.com/Solr-1.4-Replication-scheme-tp24965590p24968105.html
Sent from the Solr - User mailing list archive at Nabble.com.
On Fri, Aug 14, 2009 at 8:39 AM, KaktuChakarabati wrote:
>
> In the old replication, I could snappull with multiple slaves
> asynchronously
> but perform the snapinstall on each at the same time (+- epsilon seconds),
> so that way production load balanced query serving will always be
> consistent.
ppreciated!
Thanks,
-Chak
--
View this message in context:
http://www.nabble.com/Solr-1.4-Replication-scheme-tp24965590p24965590.html
Sent from the Solr - User mailing list archive at Nabble.com.
12 matches
Mail list logo
