You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Petersen, Robert (Contr)" <ro...@ftr.com> on 2017/11/01 16:23:17 UTC
Upgrade path from 5.4.1
Hi Guys,
I just took over the care and feeding of three poor neglected solr 5.4.1 cloud clusters at my new position. While spinning up new collections and supporting other business initiatives I am pushing management to give me the green light on migrating to a newer version of solr. The last solr I worked with was 6.6.1 and I was thinking of doing an upgrade to that (er actually 6.6.2) as I was reading an existing index only upgrades one major version number at a time.
Then I realized the existing 5.4.1 cloud clusters here were set up with unmanaged configs, so now I'm starting to lean toward just spinning up clean new 6.6.2 or 7.1 clouds on new machines leaving the existing 5.4.1 machines in place then reindexing everything on to the new machines with the intention of testing and then swapping in the new machines and finally destroying the old ones when the dust settles (they're all virtuals so NP just destroying the old instances and recovering their resources).
Thoughts?
Thanks
Robi
________________________________
This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.
Re: Upgrade path from 5.4.1
Posted by "Petersen, Robert (Contr)" <ro...@ftr.com>.
Thanks guys! I kind of suspected this would be the best route and I'll move forward with a fresh start on 7.x as soon as I can get ops to give me the needed machines! 😊
Best
Robi
________________________________
From: Erick Erickson <er...@gmail.com>
Sent: Thursday, November 2, 2017 8:17:49 AM
To: solr-user
Subject: Re: Upgrade path from 5.4.1
Yonik:
Yeah, I was justparroting what had been reported I have no data to
back it up personally. I just saw the JIRA that Simon indicated and it
looks like the statement "which are faster on all fronts and use less
memory" is just flat wrong when it comes to looking up individual
values.
Ya learn somethin' new every day.
On Thu, Nov 2, 2017 at 6:57 AM, simon <mt...@gmail.com> wrote:
> though see SOLR-11078 , which is reporting significant query slowdowns
> after converting *Trie to *Point fields in 7.1, compared with 6.4.2
>
> On Wed, Nov 1, 2017 at 9:06 PM, Yonik Seeley <ys...@gmail.com> wrote:
>
>> On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <er...@gmail.com>
>> wrote:
>> > I _always_ prefer to reindex if possible. Additionally, as of Solr 7
>> > all the numeric types are deprecated in favor of points-based types
>> > which are faster on all fronts and use less memory.
>>
>> They are a good step forward in genera, and faster for range queries
>> (and multiple-dimensions), but looking at the design I'd guess that
>> they may be slower for exact-match queries?
>> Has anyone tested this?
>>
>> -Yonik
>>
________________________________
This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.
Re: Upgrade path from 5.4.1
Posted by Erick Erickson <er...@gmail.com>.
Yonik:
Yeah, I was justparroting what had been reported I have no data to
back it up personally. I just saw the JIRA that Simon indicated and it
looks like the statement "which are faster on all fronts and use less
memory" is just flat wrong when it comes to looking up individual
values.
Ya learn somethin' new every day.
On Thu, Nov 2, 2017 at 6:57 AM, simon <mt...@gmail.com> wrote:
> though see SOLR-11078 , which is reporting significant query slowdowns
> after converting *Trie to *Point fields in 7.1, compared with 6.4.2
>
> On Wed, Nov 1, 2017 at 9:06 PM, Yonik Seeley <ys...@gmail.com> wrote:
>
>> On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <er...@gmail.com>
>> wrote:
>> > I _always_ prefer to reindex if possible. Additionally, as of Solr 7
>> > all the numeric types are deprecated in favor of points-based types
>> > which are faster on all fronts and use less memory.
>>
>> They are a good step forward in genera, and faster for range queries
>> (and multiple-dimensions), but looking at the design I'd guess that
>> they may be slower for exact-match queries?
>> Has anyone tested this?
>>
>> -Yonik
>>
Re: Upgrade path from 5.4.1
Posted by simon <mt...@gmail.com>.
though see SOLR-11078 , which is reporting significant query slowdowns
after converting *Trie to *Point fields in 7.1, compared with 6.4.2
On Wed, Nov 1, 2017 at 9:06 PM, Yonik Seeley <ys...@gmail.com> wrote:
> On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <er...@gmail.com>
> wrote:
> > I _always_ prefer to reindex if possible. Additionally, as of Solr 7
> > all the numeric types are deprecated in favor of points-based types
> > which are faster on all fronts and use less memory.
>
> They are a good step forward in genera, and faster for range queries
> (and multiple-dimensions), but looking at the design I'd guess that
> they may be slower for exact-match queries?
> Has anyone tested this?
>
> -Yonik
>
Re: Upgrade path from 5.4.1
Posted by Yonik Seeley <ys...@gmail.com>.
On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <er...@gmail.com> wrote:
> I _always_ prefer to reindex if possible. Additionally, as of Solr 7
> all the numeric types are deprecated in favor of points-based types
> which are faster on all fronts and use less memory.
They are a good step forward in genera, and faster for range queries
(and multiple-dimensions), but looking at the design I'd guess that
they may be slower for exact-match queries?
Has anyone tested this?
-Yonik
Re: Upgrade path from 5.4.1
Posted by Erick Erickson <er...@gmail.com>.
I _always_ prefer to reindex if possible. Additionally, as of Solr 7
all the numeric types are deprecated in favor of points-based types
which are faster on all fronts and use less memory. However, to use
this functionality you'll need to re-index anyway.
Solr 7 will still support Trie types, but support for those is not
guaranteed after that, so it's a chance to get ahead of the curve.
I _strongly_ recommend that you start with the default configs in 7x
and apply any changes made (fields, fieldtypes, requesthandlers
whatever) to the 7x rather than copy the old configs. Of course that's
not really a problem if you can't find the configs in the first
place....
You can download your configs from ZooKeeper so at least they aren't
permanently lost....
new (6x+) Solr's let you move things back and forth pretty easily, try
`bin/solr zk -help'
Best,
Erick
On Wed, Nov 1, 2017 at 9:23 AM, Petersen, Robert (Contr)
<ro...@ftr.com> wrote:
> Hi Guys,
>
>
> I just took over the care and feeding of three poor neglected solr 5.4.1 cloud clusters at my new position. While spinning up new collections and supporting other business initiatives I am pushing management to give me the green light on migrating to a newer version of solr. The last solr I worked with was 6.6.1 and I was thinking of doing an upgrade to that (er actually 6.6.2) as I was reading an existing index only upgrades one major version number at a time.
>
>
> Then I realized the existing 5.4.1 cloud clusters here were set up with unmanaged configs, so now I'm starting to lean toward just spinning up clean new 6.6.2 or 7.1 clouds on new machines leaving the existing 5.4.1 machines in place then reindexing everything on to the new machines with the intention of testing and then swapping in the new machines and finally destroying the old ones when the dust settles (they're all virtuals so NP just destroying the old instances and recovering their resources).
>
>
> Thoughts?
>
>
> Thanks
>
> Robi
>
> ________________________________
>
> This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.