Hi Shawn,
Thanks for the info.
Regards,
Edwin
On 9 March 2017 at 23:09, Shawn Heisey wrote:
> On 3/8/2017 10:46 PM, Zheng Lin Edwin Yeo wrote:
> > Just to check, are the index that was indexed in Solr 6.4.1 affected
> > by the bug? Do we have to re-index those records when we move to Solr
> >
On 3/8/2017 10:46 PM, Zheng Lin Edwin Yeo wrote:
> Just to check, are the index that was indexed in Solr 6.4.1 affected
> by the bug? Do we have to re-index those records when we move to Solr
> 6.4.2?
None of the bugs fixed between 6.4.1 and 6.4.2 should affect your index
contents at all. That's
Hi Ishan,
yes you are right!
Left over from previous version during replace :-(
Thanks for your help,
Bernd
Am 09.03.2017 um 06:49 schrieb Ishan Chattopadhyaya:
> Hi Bernd,
> Can you please double check?
>
> I downloaded the 6.4.2 tarball and see that they have 6.4.2:
>
> [ishan@ishanvps sol
Hi Bernd,
Can you please double check?
I downloaded the 6.4.2 tarball and see that they have 6.4.2:
[ishan@ishanvps solr-6.4.2]$ grep -rn "luceneMatchVersion" *|grep
solrconfig.xml
CHANGES.txt:1474: or
your luceneMatchVersion in the solrconfig.xml is less than 6.0
docs/changes/Changes.html:1694
Hi,
Just to check, are the index that was indexed in Solr 6.4.1 affected by the
bug? Do we have to re-index those records when we move to Solr 6.4.2?
Regards,
Edwin
On 9 March 2017 at 12:49, Shawn Heisey wrote:
> On 3/8/2017 2:36 AM, Bernd Fehling wrote:
> > Shouldn't in server/solr/configset
On 3/8/2017 2:36 AM, Bernd Fehling wrote:
> Shouldn't in server/solr/configsets/.../solrconfig.xml
> 6.4.1
> really read
> 6.4.2
>
> May be something for package builder for future releases?
That does look like it got overlooked, and is generally something that
SHOULD be changed with each new vers
Hi Shawn,
These are the facts:
With Solr 6.4.1, we started the optimisation of a 200gb index with 67 segments.
This did not trigger replication. It took a few days. We confirmed that the
bottleneck was the CPU (optimisation is not parallelised).
We manually triggered replication of the optimis
During the replication, check the disk, network, and CPU utilization. One of
them is the bottleneck.
If the disk is at 100%, you are OK. If the network is at 100%, you are OK. If
neither of them is at 100% and there is lots of CPU used (up to 100% of one
core), then Solr is the bottleneck and i
On 3/8/2017 5:30 AM, Caruana, Matthew wrote:
> After upgrading to 6.4.2 from 6.4.1, we’ve seen replication time for a
> 200gb index decrease from 45 hours to 1.5 hours.
Just to check how long it takes to move a large amount of data over a
network, I started a copy of a 32GB directory over a 100Mb
Caruana:
Thanks for that info.
Do you know offhand how that 1.5 hours compares to earlier versions?
I'm wondering if there is further work to be done here or are we back
to previous speeds.
Thanks
Erick
On Wed, Mar 8, 2017 at 4:30 AM, Caruana, Matthew wrote:
> After upgrading to 6.4.2 from 6.4
After upgrading to 6.4.2 from 6.4.1, we’ve seen replication time for a 200gb
index decrease from 45 hours to 1.5 hours.
> On 7 Mar 2017, at 20:32, Ishan Chattopadhyaya wrote:
>
> 7 March 2017, Apache Solr 6.4.2 available
>
> Solr is the popular, blazing fast, open source NoSQL search platform
Shouldn't in server/solr/configsets/.../solrconfig.xml
6.4.1
really read
6.4.2
May be something for package builder for future releases?
Regards
Bernd
Am 07.03.2017 um 20:32 schrieb Ishan Chattopadhyaya:
> 7 March 2017, Apache Solr 6.4.2 available
>
> Solr is the popular, blazing fast, open sou
12 matches
Mail list logo
