On 10/19/2015 11:56 AM, Jae Joo wrote:
> Found the root cause. I disabled the transaction log.
SolrCloud requires the transaction log for proper operation. Disabling
it might cause all sorts of future problems, including problems with
data replication and recovery. Because it's so critical, there has been
some discussion of detecting a disabled transaction log as a startup
error in cloud mode.
Instead of disabling it, you can take steps to ensure that the
transaction logs do not become enormous. A hard commit will close the
current transaction log and start a new one. You can have this happen
automatically by configuring autoCommit with something like the following:
<!-- the default high-performance update handler -->
<updateHandler class="solr.DirectUpdateHandler2">
<autoCommit>
<maxTime>60000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<updateLog />
</updateHandler>
Setting openSearcher to false ensures that these automatic commits do
not change document visibility -- whatever you are doing for change
visibility, unless it is using autoCommit, will continue to work as it
did before. A maxTime of one minute means that it will probably not
happen frequently enough to cause a major performance issue. You might
want to raise that to as much as five minutes (300000).
A larger discussion of this topic:
http://lucidworks.com/blog/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
I personally think doing hard commits after fifteen seconds as discussed
in the article above is too frequent, but many people use that config
and don't have any problems.
Thanks,
Shawn
