As a follow up.
Eventually the tlog file is disappeared (could not track the time it
took to clear out completely). However, following messages were noticed
in follower's log.
5120638 [recoveryExecutor-14-thread-2] WARN
org.apache.solr.update.UpdateLog – Starting log replay tlog
On
Erick,
Actually, configured autocommit to 15 seconds and openSearcher is set to
false. Neither 2 nor 3 happened. However, softCommit is set to 10 min.
${solr.autoCommit.maxTime:15000}
false
Working on upgrading to 5.3 which will take a bit of time and trying to
get this
right, so the scenario is
1> somehow you didn't do a hard commit (openSearcher=true or false
doesn't matter) for a really long time while indexing.
2> Solr abnormally terminated.
3> When Solr started back up it replayed the entire log.
How <1> happened is the mystery though. With a hard commit
The only way I can account for such a large file off the top of my
head is if, for some reason,
the Solr on the node somehow was failing to index documents and kept
adding them to the
log for a lnnn time. But how that would happen without the
node being in recovery
mode I'm not sure. I
Uhm, that's very weird. Updates are not applied from the tlog. Rather the
raw doc is forwarded to the replica which both indexes the doc and
writes it to the local tlog. So having a 14G tlog on a follower but a small
tlog on the leader is definitely strange, especially if it persists over time.
I
Thanks Erick.
Eventually, followers caught up but the 14G tlog file still persists and
they are healthy. Is there anything to look for? Will monitor and see
how long will it take before it disappears.
Evaluating move to Solr 5.3.
On 10/7/15 7:51 PM, Erick Erickson wrote:
Uhm, that's very
Solr 4.6.1, single shard, 4 node cloud, 3 node zk
Like to understand the behavior better when large number of updates
happen on leader and it generates huge tlog (14G sometimes in my case)
on other nodes. At the same time leader's tlog is few KB. So, what is
the rate at which the changes from
ited a long
> time before it started tlog replay. During that time, we have about 32
> cores doing such tlog relay. The service took over 40 minutes to make whole
> service back.
>
> Some questions we want to know:
> 1. Is tlog replay a single thread activity? Can we configure to
>
> Before tlog replay, the replica will replicate any missing index files
> from the leader. I think that is what is causing the time between the
> two log messages. You have INFO logging turned off so there are no
> messages from the replication handler about it.
I did no
Our environment ran in Solr4.7. Recently hit a core recovery failure and
then it retries to recover from tlog.
We noticed after 20:05:22 said Recovery failed, Solr server waited a long
time before it started tlog replay. During that time, we have about 32
cores doing such tlog relay. The service
Hi Summer,
If you take a look to the CommitUpdateCommand class, you will notice no
Flag is in there.
// this is the toString for example
@Override
public String toString() {
return super.toString() + ,optimize=+optimize
+,openSearcher=+openSearcher
Thanks Alessandro !
Any idea on why I couldn't curl the solr core and pass the flag param ?
On Jul 8, 2015, at 7:12 AM, Alessandro Benedetti benedetti.ale...@gmail.com
wrote:
Hi Summer,
If you take a look to the CommitUpdateCommand class, you will notice no
Flag is in there.
//
On Wed, Jul 8, 2015 at 12:31 PM, Summer Shire shiresum...@gmail.com wrote:
Thanks Alessandro !
Any idea on why I couldn't curl the solr core and pass the flag param ?
These flags are for internal use only. Solr sets them, the client doesn't.
-Yonik
Hi,
When I restart my solr core the log replay starts and just before it finishes I
see the following commit
start
commit{flags=2,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
what does the “flags=2” param do ?
when I try to
14 matches
Mail list logo
