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
