: > 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
On Fri, Aug 14, 2009 at 1:48 PM, Jason
Rutherglen wrote:
> This would be good! Especially for NRT where this problem is
> somewhat harder. I think we may need to look at caching readers
> per corresponding http session.
For something like distributed search I was thinking of a simple
reservation m
This would be good! Especially for NRT where this problem is
somewhat harder. I think we may need to look at caching readers
per corresponding http session. The pitfall is expiring them
before running out of RAM.
On Fri, Aug 14, 2009 at 6:34 AM, Yonik Seeley wrote:
> Longer term, it might be nice
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.
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)
Thanks,
-Jibo
On Aug 14, 2009, at 6:34 AM, Yonik Seeley wrote:
Longer te
Longer term, it might be nice to enable clients to specify what
version of the index they were searching against. This could be used
to prevent consistency issues across different slaves, even if they
commit at different times. It could also be used in distributed
search to make sure the index di
On Fri, Aug 14, 2009 at 2:28 PM, KaktuChakarabati wrote:
>
> Hey Noble,
> you are right in that this will solve the problem, however it implicitly
> assumes that commits to the master are infrequent enough ( so that most
> polling operations yield no update and only every few polls lead to an
> act
Hey Noble,
you are right in that this will solve the problem, however it implicitly
assumes that commits to the master are infrequent enough ( so that most
polling operations yield no update and only every few polls lead to an
actual commit. )
This is a relatively safe assumption in most cases, bu
usually the pollInterval is kept to a small value like 10secs. there
is no harm in polling more frequently. This can ensure that the
replication happens at almost same time
On Fri, Aug 14, 2009 at 1:58 PM, KaktuChakarabati wrote:
>
> Hey Shalin,
> thanks for your prompt reply.
> To clarity:
> W
Hey Shalin,
thanks for your prompt reply.
To clarity:
With the old script-based replication, I would snappull every x minutes
(say, on the order of 5 minutes).
Assuming no index optimize occured ( I optimize 1-2 times a day so we can
disregard it for the sake of argument), the snappull would take
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.
11 matches
Mail list logo
