THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Ambari provides the ability to upgrade your cluster from a lower stack-version to a higher stack-version.
Each stack-version defines can define upgrade-packs, which are XML files describing the upgrade process. These upgrade-pack XML files are placed in the stack-version's upgrades/ folder.
Example: HDP-2.3, HDP-2.4
Each stack-version should have an upgrade-pack for the next stack-version a cluster can upgrade to.
Ex: Upgrade-pack from HDP-2.3 to HDP-2.4
There are two kinds types of upgrades:
| Upgrade Type | Pros | Cons |
|---|---|---|
| Rolling Upgrade (RU) | Minimal cluster downtime - services available throughout upgrade process | Takes a long time time (sometimes days depending on cluster size) due to incremental upgrade approach - sometimes days |
| Express Upgrade (EU) | Cluster unavailable - services are stopped during upgrade process | Much faster - clusters can be upgraded in a couple of hours |
Rolling Upgrades
In Rolling Upgrade each service is upgraded with minimal downtime in mind. The general approach is to quickly upgrade the master components, followed by upgrading of workers in batches.
The service will not be available when masters are restarting. However when master components are in High Availability (HA), the service continues to be available through restart of each master.
...
You can read more about the Rolling Upgrade process via this blog post and documentation.
Examples
Express Upgrades
In Express Upgrade the goal is to upgrade entire cluster as fast as possible - even if it means cluster downtime. It is generally much faster than Rolling Upgrade.
For each service the components are first stopped, upgraded and then started.
You can read about Express Upgrade steps in this documentation.
Examples