Editing the Cluster Configuration File

The cluster.config file contains critical parameters required to switch to another version of the Big Data Protector. This file is created after executing the configurator script. The cluster.config file is available in the /Installation_Files/ directory.

To edit the cluster.config file:

1. Log in to the Master node.
2. Navigate to the directory where the installation files for the new version of the Big Data Protector is extracted.
3. To view the cluster_config file, using any compatible text editor, run the following command:

   vim cluster.config
   

4. Press ENTER.
   The command displays the contents of the cluster.config file. The parameters in the file are categorized into mandatory and optional sections.

    CM_HOST=                            # Cloudera Manager server hostname or IP address (e.g., 192.168.123.25 or cm.example.com)
    CM_PORT=                            # Cloudera Manager server port (default: 7180 for HTTP, 7183 for HTTPS)
    CM_USER=                            # Cloudera Manager admin username (e.g., admin)
    CM_PASS=                            # Cloudera Manager admin password (e.g., admin)
    CLOUDERA_BASE=                      # Base directory for Cloudera installation (e.g., /opt/cloudera)
    CLUSTER_NAME=                       # Name of the cluster as shown in Cloudera Manager (e.g., Cluster1)
    PREV_INSTALL_FILES_DIR=             # Path to previous install files directory (e.g., "/build/10.1.1/Installation_Files")
   
    # Rolling restart tuning (optional)
    ROLLING_BATCH_SIZE="1"              # Number of nodes to restart in each batch. A value of 1 ensures strict sequential upgrade—only one node is offline at a time. Increasing this (e.g., to 2 or 5) allows parallel upgrades, which speeds up the process but increases risk and potential downtime. This value depends on cluster size and workload characteristics. Please consult your cluster administrator before modifying.
    ROLLING_SLEEP_SECONDS="300"         # Pause duration (in seconds) between batches. This gives time for services to stabilize and avoids overwhelming cluster. Useful for large clusters or when workload is high.
    ROLLING_FAIL_COUNT_THRESHOLD="0"    # Maximum number of node failures allowed before the rolling restart is aborted. 0 means no limit—restart continues regardless of failures. Set this to a small number (e.g., 2) to enforce safety and halt the process if too many nodes fail.
    ROLLING_STALE_CONFIGS_ONLY="true"   # If true, only roles with stale configuration (i.e., config changes not yet applied) will be restarted. This avoids unnecessary restarts and speeds up the process. If false, all roles are restarted regardless of config state.
    ROLLING_UNUPGRADED_ONLY="true"      # Controls whether the rolling restart targets all roles or only outdated ones.  - false: Full rolling restart (all roles restarted, cleanup runs).  - true: Retry mode (only outdated roles restarted, cleanup skipped). Useful for resuming interrupted upgrades.
    ROLLING_TIMEOUT_SECONDS="3600"      # Total time (in seconds) allowed for the rolling restart to complete. If the process exceeds this duration, it will be considered failed. Default is 1 hour. This value should be tuned based on the number of nodes, batch size, and expected restart duration per node. Please check with your cluster administrator.
    ROLLING_EXCLUDE_SERVICES="impala"   # Optional. Space-separated list of CM service names to exclude from the rolling restart. For example, excluding impala avoids restarting Impala daemons, which may be critical for ongoing queries.
    PARCEL_RECOGNITION_TIMEOUT=300      # Seconds to wait after uploading a parcel and restarting Cloudera Manager for it to detect the new parcel. This value depends on CM performance and cluster size. Please confirm with your administrator.
    STAGE_WAIT_TIMEOUT=900              # Time (in seconds) to wait for a parcel to reach a target stage (e.g., DISTRIBUTED, ACTIVATED). The final expected stage is ACTIVATED. This timeout should be adjusted based on network speed, disk I/O, and number of nodes. Please check with your cluster administrator.
    BDP_SSH_USER=root                   # SSH user used for remote commands and safety checks. Defaults to root, but can be changed if CM agents run under a different user.
    REMOVE_OLD_PARCELS_AFTER_RR=true    # If true, old parcels (e.g., 10.1.x) will be removed after a successful rolling restart. Helps free up disk space and avoid confusion. If false, old parcels are retained for rollback.
   

5. Edit the parameters as required.

   Note: If the password for Cloudera Manager is not provided in the cluster.config file, the script will prompt for the password during the upgrade.

   Enter CM_PASS (Cloudera Manager password):
   

6. Save the changes to the cluster.config file.