The problem with that approach is that unlike databases, a commit is an expensive operation in Lucene right now. It is not very practical to commit per document, therefore log replication offers very little.
On Tue, Jan 6, 2009 at 12:07 AM, Jacob Singh <jacobsi...@gmail.com> wrote: > Has there been a discussion anywhere about a "binary log" style > replications scheme (ala mysql?) Wherein, every write request goes to > the master, and the the slaves read in a queue of the requests and > update themselves one record at a time instead of wholesale? Or is > this just not worth the development time? > > Best, > Jacob > > On Mon, Jan 5, 2009 at 10:26 AM, Noble Paul നോബിള് नोब्ळ् > <noble.p...@gmail.com> wrote: > > The default IndexDeletionPolicy just keeps the last commit only > > (KeepOnlyLastCommitDeletionPolicy) .Files belonging to older commits > > are removed. If the files are needed longer for replication, they are > > leased . The lease is extended 10 secs at a time. Once all the slaves > > have copied the lease is never extended and the files will be purged. > > > > In the snapshot based system , unless the snapshots are deleted from > > the file system the old files will continue to live on the disk > > --Noble > > > > On Mon, Jan 5, 2009 at 6:59 PM, Mark Miller <markrmil...@gmail.com> > wrote: > >> Noble Paul ??????? ?????? wrote: > >>> > >>> * SolrReplication does not create snapshots . So you have less cleanup > >>> to do. The script based replication results is more disk space > >>> consumption (especially if you do frequent commits) > >>> > >> > >> Doesn't SolrReplication effectively take a snapshot by using a custom > >> IndexDeletionPolicy to keep the right index files around? Isn't that > >> maintaining a snapshot? > >> > >> Could you elaborate on the difference Noble? > >> > >> - Mark > >> > > > > > > > > -- > > --Noble Paul > > > > > > -- > > +1 510 277-0891 (o) > +91 9999 33 7458 (m) > > web: http://pajamadesign.com > > Skype: pajamadesign > Yahoo: jacobsingh > AIM: jacobsingh > gTalk: jacobsi...@gmail.com > -- Regards, Shalin Shekhar Mangar.