Just for the first part: There's no problem here, the write lock
is to keep simultaneous *writes* from occurring, the slave reading
the index doesn't enter in to it. Note that in Solr, when segments
are created in an index, they are write-once. So basically what
happens when a slave replicates is that the current segments that have
had commits against them are replicated (they won't be written to
after a commit) and Solr merrily continues writing to new segments.
So the slave gets its snapshot of the index as of the last commit that
happened before it polled the master.
The trunk has something called NRT (near real time) that attempts to
decrease the latency, but I don't know how that plays with replication.
Best
Erick
On Thu, Feb 10, 2011 at 1:37 PM, Erick Erickson <erickerick...@gmail.com> wrote:
>
> Just for the first part: There's no problem here, the write lock
> is to keep simultaneous *writes* from occurring, the slave reading
> the index doesn't enter in to it. Note that in Solr, when segments
> are created in an index, they are write-once. So basically what
> happens when a slave replicates is that the current segments that have
> had commits against them are replicated (they won't be written to
> after a commit) and Solr merrily continues writing to new segments.
> So the slave gets its snapshot of the index as of the last commit that
> happened before it polled the master.
> The trunk has something called NRT (near real time) that attempts to
> decrease the latency, but I don't know how that plays with replication.
> Best
> Erick
> On Thu, Feb 10, 2011 at 10:33 AM, Shane Perry <thry...@gmail.com> wrote:
>>
>> Hi,
>>
>> When a slave is replicating from the master instance, it appears a
>> write lock is created. Will this lock cause issues with writing to the
>> master while the replication is occurring or does SOLR have some
>> queuing that occurs to prevent the actual write until the replication
>> is complete? I've been looking around but can't seem to find anything
>> definitive.
>>
>> My application's data is user centric and as a result the application
>> does a lot of updates and commits. Additionally, we want to provide
>> near real-time searching and so replication would have to occur
>> aggressively. Does anybody have any strategies for handling such an
>> application which they would be willing to share?
>>
>> Thanks,
>>
>> Shane
>
