Prerequisites for Upgrade

This page explains how to back up the database, increase the NameNode timeout value, prepare for an upgrade, and view unsupported components.

Increase the NameNode Timeout Value

To ensure that Ambari requests to start the NameNode and does not timeout during an upgrade, you must configure the Ambari NameNode restart timeout parameter using upgrade.parameter.nn-restart.timeout in the /etc/ambari-server/conf/ambari.properties file on the Ambari Server host.

You may need to add the restart timeout parameter and value to the Ambari server host following a default installation. For a large cluster, you must add 50% to the usual time (in seconds) that is required to restart the NameNode.

For example, on the Ambari server, observe the time (in seconds) required to restart the active NameNode. If the time taken to restart the active NameNode is more than 10 minutes (600 seconds) and the cluster is large, then add the following parameter to the /etc/ambari-server/conf/ambari.properties file on the Ambari Server host.

parameter.upgrade.parameter.nn-restart.timeout=900

After adding or resetting the Ambari NameNode restart parameter, restart the Ambari server before upgrading it to a newer version using the below command.

ambari-server restart

Unsupported components

if the existing cluster has spark2 service running, remove the service as its not supported in 3.3.6.x lines.

If Spark2 cannot be deleted and displays the following error, follow these steps to resolve the issue.

Prepare for Upgrade

Follow these steps to prepare your cluster for the upgrade:

1. Clone or download the repository on the Ambari Server node.

git clone https://github.com/acceldata-io/ce-utils.git

2. Navigate to the upgrade directory.

cd odp-upgrade-to-3_3_6_2_1

3. Run the upgrade preparation script.

bash upgrade_ambari_336.sh

4. Restart Ambari Server.

ambari-server restart

Backup Backend Databases

Before starting the stack upgrade, back up all backend databases for the services in your cluster. This backup ensures that you can restore service configurations and metadata if the upgrade fails or unexpected issues occur.

In this scenario, the backend database is MySQL. These steps have been tested with a MySQL backend database.

mkdir /tmp/ODP-server_db_bckp/ ; cd /tmp/ODP-server_db_bckp/

​

# for ambari

mysqldump --databases ambari >     /tmp/ODP-server_db_bckp/ambari_mysql_bckp.sql

 # for hive

mysqldump --databases hive >      /tmp/ODP-server_db_bckp/hive_mysql_bckp.sql

# for rangerkms    

mysqldump --databases rangerkms > /tmp/ODP-server_db_bckp/rangerkms_mysql_bckp.sql

​

# for ranger

mysqldump --databases ranger >    /tmp/ODP-server_db_bckp/ranger_mysql_bckp.sql

​

# for druid

mysqldump --databases druid >    /tmp/ODP-server_db_bckp/druid_mysql_bckp.sql