Rolling upgrade from HDP 2.3.0 to 2.5.3 ?

[#1]

I am planning to do a rolling upgrade of the cluster from 2.3.0 to 2.5.3. Is this option available? I need to do this with least downtime, so I cannot use Express upgrade.

If it is available, can someone provide a link to it please

[#2 · Accepted solution]

@hello hadoop

I would check here to determine if option is available

http://docs.hortonworks.com/HDPDocuments/Ambari-2.4.2.0/bk_ambari-upgrade/content/upgrading_hdp_stac...

From the docs above the option is available on 2.3.

Also please check the pre reqs prior to upgrading

http://docs.hortonworks.com/HDPDocuments/Ambari-2.4.2.0/bk_ambari-upgrade/content/upgrading_HDP_prer...

[#3]

Perfect. This is exactly what I needed. Thank you @Sunile Manjee

[#4]

Hi ,

We are planning rolling upgrade from HDP 2.3 to HDP 2.5 , want to understand you experience using RU.

Did you see any issues or downtime during RU.

Also some of the specific concerns I have -

1) HDP 2.5 has hive metastore schema upgrade , does this results into any down time / degradation , HS2/Hive queuing queries until schema upgrade.

2) There is a preparation step listed in upgrade documentation to stop Yarn queues , essentially meaning no new jobs can be submitted to Yarn, does this mean downtime. Does Ambari takes care of resuming queues post upgrade.

3) We also use Spark Thrift Server in our HDP stack, which does not have any redundancy built in for RU. Does this mean down time for STS.

It would be helpful to know your experience/opinion.

Thanks

PJ

,

Hi,

I am also planning to upgrade 2.3 to 2.5 using RU. It would be really helpful to know if RU worked smoothly for you without down time.

I have specific concerns like -

1) Hive metastore schema upgrade in 2.5, does it results in downtime or degraded response (queries queued until upgrade completes) . Do we need to handle client side retries etc.

2) I see as a preparation step, all Yarn queues to be stopped , meaning new jobs cannot be submitted. Does this results into downtime or Ambari orchestration resumes queue as part of the RU without any perceived down time to client applications/users.

3) We also use Spark Thrift Server which does not have any redundancy built in for RU,

It would be really helpful to know your experiences and any mitigations.

Thanks

PJ