This is a good question...
I don't know much about how Solr's transaction log works, but, peeking
in the code, I do see it fsync'ing (look in TransactionLog.java, in
the finish method), but only if the SyncLevel is FSYNC.
If the default is really flush, I don't see how the transaction log
helps on recovery...?
Should we change the default ot FSYNC?
Mike McCandless
http://blog.mikemccandless.com
On Sat, Apr 28, 2012 at 7:11 AM, Li Li fancye...@gmail.com wrote:
hi
I checked out the trunk and played with its new soft commit
feature. it's cool. But I've got a few questions about it.
By reading some introductory articles and wiki, and hasted code
reading, my understand of it's implementation is:
For normal commit(hard commit), we should flush all into disk and
commit it. flush is not very time consuming because of
os level cache. the most time consuming one is sync in commit process.
Soft commit just flush postings and pending deletions into disk
and generating new segments. Then solr can use a
new searcher to read the latest indexes and warm up and then register itself.
if there is no hard commit and the jvm crashes, then new data may lose.
if my understanding is correct, then why we need transaction log?
I found in DirectUpdateHandler2, every time a command is executed,
TransactionLog will record a line in log. But the default
sync level in RunUpdateProcessorFactory is flush, which means it will
not sync the log file. does this make sense?
in database implementation, we usually write log and modify data
in memory because log is smaller than real data. if crashes.
we can redo the unfinished log and make data correct. will Solr
leverage this log like this? if it is, why it's not synced?
