Upgrade path from 5.4.1

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrade path from 5.4.1

Petersen, Robert (Contr)
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.
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade path from 5.4.1

Erick Erickson
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)
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade path from 5.4.1

Yonik Seeley
On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade path from 5.4.1

simon-2
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 <[hidden email]> wrote:

> On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade path from 5.4.1

Erick Erickson
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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <[hidden email]>
>> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade path from 5.4.1

Petersen, Robert (Contr)
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> On Wed, Nov 1, 2017 at 2:36 PM, Erick Erickson <[hidden email]>
>> 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.