On Mon, Dec 19, 2016 at 7:03 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote:
> > : So, the other way this can be made better in my opinion is:::: (if the > : optimization is not already there) > : Is to make the 'delete-query' on ttl-documents operation on translog to > not > : be forced to fsync to disk (so still written to translog, but no fsync). > : The another index/delete happens, it will also fsync the translog of the > : previous 'delete ttl query'. > : If the server crashes, meaning we lost those deletes because the translog > : wasn't fsynced to disk, then a thread can run on startup to recheck > : ttl-deletes. > : This will make it so the delete-query comes "free" in disk-fsync on > : translog. > : Makes sense ? > > All updates in Solr operate on both the in memory IndexWriter and the > (Solr specific) transaction log, and only when a "hard commit" happens is > the IndexWriter closed (causing segment files to fsync) ... the TTL code > only does a "soft commit" which should not do any fsyncs on the index. > I wasn't talking about "commiting" segments, I'm talking about not fsyncing the translog on the delete-by-query-for-ttl. It does function like normals db, meaning you append to log most of the time, and when doing a commit(checkpoint), you write the segment and 'cut' the log (so we don't read old log on restart to go to latest state). But you have to fsync the log to be sure it's on disk. > > > > -Hoss > http://www.lucidworks.com/ >
