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 didn't change between phases.
-Yonik http://www.lucidimagination.com 2009/8/14 Noble Paul നോബിള് नोब्ळ् <noble.p...@corp.aol.com>: > On Fri, Aug 14, 2009 at 2:28 PM, KaktuChakarabati<jimmoe...@gmail.com> 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 >> actual commit. ) >> 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 searcher warmup times.. >> In effect what this comes down to it seems is that i must make the master >> commit frequency the same as i'd want the slaves to use - and this is >> markedly different than previous behaviour with which i could have the >> master get updated(+committed to) at one rate and slaves committing those >> updates at a different rate. > I see , the argument. But , isn't it better to keep both the mster and > slave as consistent as possible? There is no use in committing in > master, if you do not plan to search on those docs. So the best thing > to do is do a commit only as frequently as you wish to commit in a > slave. > > On a different track, if we can have an option of disabling commit > after replication, is it worth it? So the user can trigger a commit > explicitly > >> >> >> Noble Paul നോബിള് नोब्ळ्-2 wrote: >>> >>> 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<jimmoe...@gmail.com> >>> wrote: >>>> >>>> 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 a few >>>> seconds to run on each iteration. >>>> I then have a crontab on all slaves that runs snapinstall on a fixed >>>> time, >>>> lets say every 15 minutes from start of a round hour, inclusive. (slave >>>> machine times are synced e.g via ntp) so that essentially all slaves will >>>> begin a snapinstall exactly at the same time - assuming uniform load and >>>> the >>>> fact they all have at this point in time the same snapshot since I >>>> snappull >>>> frequently - this leads to a fairly synchronized replication across the >>>> board. >>>> >>>> With the new replication however, it seems that by binding the pulling >>>> and >>>> installing as well specifying the timing in delta's only (as opposed to >>>> "absolute-time" based like in crontab) we've essentially made it >>>> impossible >>>> to effectively keep multiple slaves up to date and synchronized; e.g if >>>> we >>>> set poll interval to 15 minutes, a slight offset in the startup times of >>>> the >>>> slaves (that can very much be the case for arbitrary resets/maintenance >>>> operations) can lead to deviations in snappull(+install) times. this in >>>> turn >>>> is further made worse by the fact that the pollInterval is then computed >>>> based on the offset of when the last commit *finished* - and this number >>>> seems to have a higher variance, e.g due to warmup which might be >>>> different >>>> across machines based on the queries they've handled previously. >>>> >>>> To summarize, It seems to me like it might be beneficial to introduce a >>>> second parameter that acts more like a crontab time-based tableau, in so >>>> far >>>> that it can enable a user to specify when an actual commit should occur - >>>> so >>>> then we can have the pollInterval set to a low value (e.g 60 seconds) but >>>> then specify to only perform a commit on the 0,15,30,45-minutes of every >>>> hour. this makes the commit times on the slaves fairly deterministic. >>>> >>>> Does this make sense or am i missing something with current in-process >>>> replication? >>>> >>>> Thanks, >>>> -Chak >>>> >>>> >>>> Shalin Shekhar Mangar wrote: >>>>> >>>>> On Fri, Aug 14, 2009 at 8:39 AM, KaktuChakarabati >>>>> <jimmoe...@gmail.com>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. >>>>>> >>>>>> With the new system it seems 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 case I lose control over >>>>>> the >>>>>> synchronization of snap installation across multiple slaves. >>>>>> >>>>> >>>>> 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 time difference 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 >>>>>> for such a rapid interval, what i mentioned above is a non 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 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. >>>>>> >>>>> >>>>> If the pollInterval is 60 seconds, it does 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. >>>> >>>> >>> >>> >>> >>> -- >>> ----------------------------------------------------- >>> Noble Paul | Principal Engineer| AOL | http://aol.com >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Solr-1.4-Replication-scheme-tp24965590p24968460.html >> Sent from the Solr - User mailing list archive at Nabble.com. >> >> > > > > -- > ----------------------------------------------------- > Noble Paul | Principal Engineer| AOL | http://aol.com >
