Please see my previous thread. I have to disable buffer on source cluster
>>> and a scheduled hard commit with scheduled logscheduler to make it work.
>>>
>>>
>>> -- Thank you
>>> Sean
>>>
>>> From: jmyatt mailto:jmy...@wayfair.com>>
>
;> and a scheduled hard commit with scheduled logscheduler to make it work.
>>
>>
>> -- Thank you
>> Sean
>>
>> From: jmyatt mailto:jmy...@wayfair.com>>
>> Date: Tuesday, Jul 11, 2017, 1:56 PM
>> To: solr-user@lucene.apache.org > solr-user@l
ter
> and a scheduled hard commit with scheduled logscheduler to make it work.
>
>
> -- Thank you
> Sean
>
> From: jmyatt mailto:jmy...@wayfair.com>>
> Date: Tuesday, Jul 11, 2017, 1:56 PM
> To: solr-user@lucene.apache.org solr-user@lucene.apache.org>>
> Su
r-user@lucene.apache.org>>
Subject: [EXTERNAL] Re: Tlogs not being deleted/truncated
another interesting clue in my case (different from what WebsterHomer is
seeing): the response from /cdcr?action=QUEUES reflects what I would expect
to see in the tlog directory but it's not accurate
another interesting clue in my case (different from what WebsterHomer is
seeing): the response from /cdcr?action=QUEUES reflects what I would expect
to see in the tlog directory but it's not accurate. By that I mean
tlogTotalSize shows 1500271 (bytes) and tlogTotalCount shows 2. This
changes as m
Have you found a solution to this? I'm seeing the same behavior (running
solr v6.5.0):
- source data center replicates to target just fine
- autocommit on Source with openSearcher=false causes tlogs to rollover at a
reasonable size
- a post-import explicit commit (with the default openSearcher=tr
I don't think that this is part of the problem, but it's bad practice.
Looking at the source code for TransactionLog I noticed this, it's very bad
form:
if (deleteOnClose) {
try {
Files.deleteIfExists(tlogFile.toPath());
} catch (IOException e) {
// TODO: s
Sometimes there are subdirectories of tlog files for example this is a
directory name tlog.20170624124859032 Why do these come into existence? The
sum of the file sizes in the folders seem close to the value returned by
the CDCR action=QUEUES
On Tue, Jun 27, 2017 at 4:05 PM, Webster Homer
wrote:
We also have the same collections in our development and QA environments.
In our Dev environment which is not using CDCR replication, but does have
autoCommit set, we have 440 tlog files. The only difference in the
configuration is that dev doesn't have the cdcr request handler configured.
It does
It appears right how that we are not seeing an issue with the target
collections, we definitely see a problem with the source collection.
numRecordsToKeep and maxNumLogsToKeep are set to the default values of 100
and 10 respectively. We probably don't need 10 tlog files around.
On Tue, Jun 27, 2
Commits were definitely not happening. We ran out of filesystem space. The
admins deleted old tlogs and restartd. The collection in question was
missing a lot of data. We reloaded it, and then we saw some commits. In
Solrcloud they look like this:
2017-06-23 17:28:06.441 INFO (commitScheduler-56-t
bq: Neither in our source collection nor in our target collections.
Hmmm. You should see messages similar to the following which I just
generated on Solr 6.2 (stand-alone I admit but that code should be the
same):
INFO - 2017-06-20 21:11:55.424; [ x:techproducts]
org.apache.solr.update.DirectU
Yes, soft commits are irrelevant for this. What is relevant about soft
commits is that we can search the data.
We have autoCommit set to 10 minutes and never see tlogs truncated.
Apparently autoCommit doesn't fire, ever.
Neither in our source collection nor in our target collections. The more I
lo
Maybe irrelevant, but soft commits don't truncate transaction logs,
only hard commits do (openSearcher true|false doesn't matter).
Full background here:
https://lucidworks.com/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
Not entirely sure how that interacts with C
:Looking at our cdcr source collection, it too doesn't look like a commit
occurred, so I sent one manually.
>From this I believe that autoCommit isn't working in Solr 6.2
Our ETL doesn't send commits, we rely upon autoCommit, and for CDCR you
have to have autoCommit. We also have autoSoftCommit se
15 matches
Mail list logo
