Correct, do not optimize.
“Optimize” was a bad choice for this action. It is a forced merge.
With master/slave, it means the slaves must always copy the entire
400 GB index. Without optimize, they would only need to copy the
changed segments.
Solr automatically merges segments for you.
wunder
Hi Midas,
Your question will probably attract more useful answers if you provide
better details. What version of solr, How many nodes, and any associated
error messages from the logs. I see you asking questions that nobody can
answer because we don't know the details of your system, or why you are
400GB index is good ?
Are we should shard it .?
When we should start caring about inex size .?
On Tue, Jun 4, 2019 at 3:04 PM Midas A wrote:
> So we should not optimize our index ?
>
> On Tue, Jun 4, 2019 at 2:37 PM Toke Eskildsen wrote:
>
>> On Tue, 2019-06-04 at 11:48 +0530, Midas A wrote:
>
So we should not optimize our index ?
On Tue, Jun 4, 2019 at 2:37 PM Toke Eskildsen wrote:
> On Tue, 2019-06-04 at 11:48 +0530, Midas A wrote:
> > Index size is 400GB. we used master slave architecture .
> >
> > commit is taking time while not able to perform optimize .
>
> Why do you want to o
On Tue, 2019-06-04 at 11:48 +0530, Midas A wrote:
> Index size is 400GB. we used master slave architecture .
>
> commit is taking time while not able to perform optimize .
Why do you want to optimize in the first place? What are you hoping to
achieve?
There should be an error message in your So
Hi ,
Index size is 400GB. we used master slave architecture .
commit is taking time while not able to perform optimize .
what should i do .
