Apigee supports upgrading Edge for Private Cloud directly from version 4.52.02 to version 4.53.00. This page describes how to perform such upgrades.
For an overview of compatible upgrade paths, see the [upgrade compatibility matrix for Edge for Private Cloud releases](https://docs.apigee.com/release/apigee-edge-release-process#upgrade-compatibility-matrix-for-edge-for-private-cloud-releases).
> [!WARNING]
> **Caution:** Edge for Private Cloud 4.53.00 includes a major version upgrade of Cassandra. Exercise caution when upgrading Cassandra, as the database stores critical data essential for Apigee's functioning. Thoroughly test this upgrade in lower environments before applying it to production. Additionally, follow all steps exactly to ensure a non-disruptive upgrade.
> [!WARNING]
> **Caution:** Do not upgrade the Apigee version and perform a major version upgrade of the operating system at the same time. If you need to upgrade both the Apigee version and the operating system, perform the processes sequentially. Either fully upgrade Apigee first and then upgrade the operating system, or vice versa.
> [!WARNING]
> **Caution:** Since Edge for Private Cloud 4.53.00 includes a major upgrade to the Cassandra version, it is not recommended to perform this upgrade one data center at a time. The upgrade steps listed in this document and assertions made (such as no impact to runtime proxy traffic) are based on the assumption that the upgrade steps are followed as documented: complete the Cassandra cluster upgrade in all data centers first, followed by the upgrade of application nodes like edge-management-server, edge-message-processor, etc.
## Who can perform the update
The person running the update should be the same as the person who originally installed Edge, or a person running as root.
After you install the Edge RPMs, anyone can configure them.
## Which components must you update
You must update all Edge components. Edge does not support a setup that contains components from multiple versions.
> [!NOTE]
> **Note:** If you installed Edge for Private Cloud 4.52.02 on Red Hat Enterprise Linux (RHEL) 7.X, CentOS 7.X, Oracle Enterprise Linux (OEL 7.X), or Amazon Linux AMI 2.X, first upgrade the operating system of your 4.52.02 installation to an 8.X series OS (such as RHEL, OEL, or Rocky Linux). After completing this, follow the steps in this article to upgrade to Edge for Private Cloud 4.53.00. See [Upgrading Red Hat Enterprise Linux](https://docs.apigee.com/how-to-guides/upgrade-rhel).
## Update prerequisites
Make sure of the following prerequisites before upgrading Apigee Edge:
- **Backup all nodes**
Before you update, we recommend that you perform a complete backup of all nodes for safety reasons. Use the procedure for your current version of Edge to perform the backup.
This allows you to have a backup plan, in case the update to a new version doesn't function properly. For more information on backup, see [Backup and Restore](https://docs.apigee.com/private-cloud/v4.53.00/backup-and-restore).
- **Ensure Edge is running**
Ensure that Edge is up and running during the update process by using the command:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
- **Verify Cassandra prerequisites**
If you previously upgraded from an older version of Edge for Private Cloud to version 4.52.02 and are now planning to upgrade to version 4.53.00, make sure you have completed the required post-upgrade steps for Cassandra. These steps are outlined in the version 4.52.02 upgrade documentation and also, mentioned under [Prerequisites for Cassandra upgrade](https://docs.apigee.com/private-cloud/v4.53.00/update-apigee-edge-45202-45300#prerequisites-for-cassandra-upgrade). If you are unsure whether these steps were completed during the previous upgrade, complete them again before proceeding with the upgrade to version 4.53.00.
- **Configuring IDP keys and certificates in Edge for Private Cloud 4.53.00**
In Edge for Private Cloud 4.53.00, IDP keys and certificates used in the `apigee-sso` component are now configured via a keystore. You will need to export the key and certificate you previously used into a keystore. Follow the steps in the [Steps for updating Apigee SSO from older versions](https://docs.apigee.com/private-cloud/v4.53.00/update-apigee-edge-45202-45300#steps-for-updating-apigee-sso-from-older-versions) section for detailed steps before updating the SSO component.
- **Python requirements**
Ensure that all nodes, including Cassandra nodes, have Python 3 installed before attempting the upgrade.
## Automatic propagation of property settings
If you have set any properties by editing `.properties` files in `/opt/apigee/customer/application`, then these values are retained by the update.
## Nginx 1.26 upgrade in Edge-Router
Upgrading to Edge for Private Cloud 4.53.00 from previous versions does not automatically upgrade Nginx software to the latest version (1.26.x). This is to prevent any accidental runtime side-effects as a result of the changes documented in [Nginx 1.26 changes in Apigee Edge 4.53.00](https://docs.apigee.com/private-cloud/v4.53.00/nginx-45300). You can manually upgrade Nginx from 1.20.x to 1.26.x after verification in lower environments. To manually upgrade:
1. Ensure edge-router node has the latest 4.53.00 software
```
/opt/apigee/apigee-service/bin/apigee-service edge-router version
```
2. Check and verify the Nginx version you're currently running
```
/opt/nginx/sbin/nginx -V
```
If you're operating an older version of Nginx, you can follow the steps below to upgrade Nginx to version 1.26.X on the router node.
3. Stop edge-router process on the router node
```
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
```
4. Upgrade nginx software on the router node
```
dnf update apigee-nginx-1.26.3
```
5. Verify that the Nginx version has been updated
```
/opt/nginx/sbin/nginx -V
```
6. Start router process on the node
```
/opt/apigee/apigee-service/bin/apigee-service edge-router start
```
7. Repeat the process on each router node, one at a time
> [!NOTE]
> **Note:** For fresh installations of Edge for Private Cloud 4.53.00, Nginx 1.26.X will be installed by default on router nodes.
> [!NOTE]
> **Note:** Nginx 1.26 is automatically installed if you are using 9 series operating system (RHEL 9.X, Rocky 9.X or Oracle Linux 9.X)
## Required upgrade to Cassandra 4.0.13
Apigee Edge for Private Cloud 4.53.00 includes an upgrade of Cassandra to version 4.0.13.
> [!WARNING]
> **Caution:** While Apigee has certified the Cassandra upgrade, it is strongly advised that you thoroughly test the upgrade in your lower environments before applying it in production to ensure you are familiar with the upgrade steps and that the upgrade is not disruptive.
### Upgrades and rollback
- Upgrading from Cassandra 3.11.X to Cassandra 4.0.X is a smooth process. Cassandra 4.0.X, released with Edge for Private Cloud 4.53.00, is compatible with the runtime and management components of Private Cloud 4.52.02.
- Direct in-place rollback from Cassandra 4.0.X to 3.11.X is not possible. Rolling back using replicas or backups is a complex procedure and may involve downtime and/or data loss. Troubleshooting issues and upgrading to Cassandra 4.0.X is preferable to rolling back.
- It is important to familiarize yourself with rollback procedures before attempting the upgrade. Considering the nuances of rollback during the upgrade is critical to ensure appropriate rollback paths are available.
> [!NOTE]
> **Important:** There is no direct in-place rollback option available after upgrading Cassandra.
#### Single data center
Upgrading Cassandra from 3.11.X to 4.0.X within a single data center is seamless, but rollback is complex and may result in downtime and data loss. For production workloads, it's strongly advised to [add a new data center](https://docs.apigee.com/private-cloud/v4.53.00/adding-data-center) with at least Cassandra nodes available in the new data center before initiating the upgrade. This will enable rollback of Cassandra without incurring data loss or disruption to your API traffic. This additional data center can be decommissioned once the upgrade is finished or Checkpoint 2 is reached.
If adding a new data center isn't feasible but rollback capability is still desired, backups will be necessary for restoring Cassandra 3.11.X. However, this method is likely to involve both downtime and data loss.
#### Multiple data centers
Operating multiple data centers with Edge for Private Cloud 4.52.02 offers more flexibility for rollbacks during the upgrade to Edge for Private Cloud 4.53.00.
- Rollbacks depend on having at least one data center running the older Cassandra version (3.11.X).
- **If your entire Cassandra cluster is upgraded to 4.0.X, you must not roll back to Cassandra 3.11.X.** You must continue using the newer Cassandra version with the other components of Private Cloud 4.53.00 or 4.52.02.
##### Recommended upgrade methodology
1. **Upgrade one Cassandra data center at a time:** Start by upgrading Cassandra nodes individually within a single data center. Complete upgrades of all Cassandra nodes in one data center before proceeding to the next.
2. **Pause and validate:** After upgrading one data center, pause to ensure your Private Cloud cluster, especially the upgraded data center, is functioning correctly.
3. **Remember:** You can only roll back to the previous Cassandra version if you have at least one data center still running the older version.
4. **Time-sensitive:** While you can pause for a short period (a few hours is recommended) to validate functionality, you cannot remain in a mixed-version state indefinitely. This is because a non-uniform Cassandra cluster (with nodes on different versions) has operational limitations.
5. **Thorough testing:** Apigee strongly recommends comprehensive testing of performance and functionality before upgrading the next data center. Once all data centers are upgraded, rollback to the earlier version is impossible.
##### Rollback as a two-checkpoint process
1. **Checkpoint 1:** The initial state, with all components on version 4.52.02. Full rollback is possible as long as at least one Cassandra data center remains on the older version.
2. **Checkpoint 2:** After all Cassandra nodes in all data centers are updated. You can roll back to this state, but you cannot revert to Checkpoint 1.
##### Example
Consider a two-data-center (DC) cluster:
1. **Start state:** Cassandra nodes in both DCs are on version 3.11.X. All other nodes are on Edge for Private Cloud version 4.52.02. Assume three Cassandra nodes per DC.
2. **Upgrade DC-1:** Upgrade the three Cassandra nodes in DC-1 one by one.
3. **Pause and validate:** Pause to ensure the cluster, particularly DC-1, is working correctly (check performance, functionality). You can roll back to the initial state using the Cassandra nodes in DC-2. Remember, this pause must be temporary due to the limitations of a mixed-version Cassandra cluster.
4. **Upgrade DC-2:** Upgrade the remaining three Cassandra nodes in DC-2. This becomes your new rollback checkpoint.
5. **Upgrade other components:** Upgrade management, runtime, and analytics nodes as usual across all data centers, one node and one data center at a time. If issues arise, you can roll back to the state of step 4.
> [!NOTE]
> **Note:** Careful planning and testing are crucial for a successful upgrade. Always consider the rollback limitations and follow the recommended methodology.
### Prerequisites for Cassandra upgrade
You should be running Cassandra 3.11.16 with Edge for Private Cloud 4.52.02 and ensure the following:
1. The entire cluster is operational and fully functional with Cassandra 3.11.16.
2. The [compaction strategy](https://docs.apigee.com/private-cloud/v4.52.02/cassandra-compaction-strategy) is set to `LeveledCompactionStrategy` (a prerequisite for the upgrade to version 4.52.02).
3. Ensure that all the below steps have been completed as part of the initial upgrade of Cassandra 3.11 in Edge for Private Cloud of 4.52.02:
- `post_upgrade` command should have been executed on each Cassandra node during previous upgrade.
- `drop_old_tables` command should have been executed on the entire Cassandra cluster during previous upgrade.
> [!NOTE]
> **Note:** The above steps ([post-upgrade](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#step-3:-upgrade-all-cassandra-nodes-in-the-first-data-center) and [Drop Unused tables](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#step-10---drop-unused-tables)) are part of standard steps that you should have executed while upgrading your cluster to Edge for Private Cloud 4.52.02 from older versions.
If you are unsure whether the preceding steps were completed, you can safely rerun them again. Ensure that these steps are executed on Cassandra 3.11 while you are still on Edge for Private Cloud 4.52.02, before upgrade to 4.53.00 is attempted:
1. Run the following `post_upgrade` command on each Cassandra node one by one:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```
2. Run the following command to drop old unused tables from the Cassandra cluster. This command should only be executed on only 1 node in the cluster:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile
```
### Step 1: Prepare for upgrade
The steps below are in addition to standard files that you typically create, such as [Apigee's standard configuration file](https://docs.apigee.com/private-cloud/v4.52.02/edge-configuration-file-reference) for enabling component upgrades.
1. Backup Cassandra using Apigee.
2. Take VM snapshots of Cassandra nodes (if feasible).
3. Ensure that port 9042 is accessible from all Edge for Private Cloud components, including Management Server, Message Processor, Router, Qpid, and Postgres, to Cassandra nodes if not already configured. Refer to the [Port requirements](https://docs.apigee.com/private-cloud/v4.53.00/port-requirements) for more information.
> [!WARNING]
> **Caution:** All these steps are critical for upgrading Cassandra to version 4 to ensure minimal data loss if a rollback is required and to prevent data loss post-upgrade. It is imperative that these steps are carried out carefully and not skipped.
### Step 2: Upgrade all Cassandra nodes
All Cassandra nodes should be updated one by one in each data center, one data center at a time. Between upgrades of nodes within a data center, wait a few minutes to ensure that an updated node has fully started and joined the cluster before proceeding with upgrading another node in the same data center.
After upgrading all Cassandra nodes within a data center, wait for some time (30 minutes to a few hours) before proceeding with the nodes in the next data center. During this time, thoroughly review the data center that was updated and ensure that the functional and performance metrics of your Apigee cluster are intact. This step is crucial to ensure the stability of the data center where Cassandra has been upgraded to version 4.0.X, while the rest of the Apigee components remain on version 4.52.02.
1. To upgrade a Cassandra node, Run the following command:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
2. Once a node is updated, run the following command on the node to run some validations before proceeding ahead:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```
3. The above will output something along the lines of:
```
Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
Metadata is verified
```
4. Run the following `post_upgrade` command on the Cassandra node:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```
5. Run the following nodetool commands to **rebuild indices** on the Cassandra node:
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
> [!NOTE]
> **Note:** Rebuilding indices may take a while to complete, depending on how much data is in your nodes.
If you're using **monetization** , also run the following **rebuild indices** commands related to monetization keyspaces:
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx
> [!WARNING]
> **Caution:** With a major Cassandra upgrade, it is advised to upgrade the entire Cassandra cluster (across all data centers) at once. Major Cassandra upgrades involve automatic schema changes, and until the entire cluster is upgraded, the schema of the Cassandra cluster remains inconsistent. In this state, Cassandra operations such as adding and removing nodes should be avoided.
### Step 3: Upgrade all Management nodes
Upgrade all Management nodes in all regions one by one:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
### Step 4: Upgrade all Runtime nodes
Upgrade all Routers and Message Processor nodes in all regions one by one:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
### Step 5: Upgrade all remaining Edge for Private Cloud 4.53.00 components
Upgrade all remaining `edge-qpid-server` and `edge-postgres-server` nodes in all regions one by one.
## Steps for updating Apigee SSO from older versions
In Edge for Private Cloud 4.53.00, the IDP keys and certificates used in the `apigee-sso` component are now configured through a keystore. You will need to export the key and certificate used earlier into a keystore, configure it, and then proceed with the SSO update as usual.
1. Identify the existing key and certificate used for configuring IDP:
1.
Retrieve the certificate by looking up the value of SSO_SAML_SERVICE_PROVIDER_CERTIFICATE in the SSO installation configuration file or by querying the `apigee-sso` component for conf_login_service_provider_certificate.
Use the following command on the SSO node to query `apigee-sso` for the IDP certificate path. In the output, look for the value in the last line.
```
apigee-service apigee-sso configure -search conf_login_service_provider_certificate
```
2. Retrieve the key by looking up the value of SSO_SAML_SERVICE_PROVIDER_KEY in the SSO installation configuration file or by querying the `apigee-sso` component for conf_login_service_provider_key.
Use the following command on the SSO node to query `apigee-sso` for the IDP key path. In the output, look for the value on the last line.
```
apigee-service apigee-sso configure -search conf_login_service_provider_key
```
2. Export the key and certificate to a keystore:
1. Export the key and certificate to a PKCS12 keystore:
```
sudo openssl pkcs12 -export -clcerts -in -inkey -out -name
```
Parameters:
- `certificate_path`: Path to the certificate file retrieved in Step 1.a.
- `key_path`: Path to the private key file retrieved in Step 1.b.
- `keystore_path`: Path to the newly created keystore containing the certificate and private key.
- `alias`: Alias used for the key and certificate pair within the keystore.
Refer to the [OpenSSL documentation](https://docs.openssl.org/1.1.1/man1/pkcs12/) for more details.
> [!NOTE]
> **Note:** You can skip the step below if you prefer to use a PKCS12 keystore.
2. (Optional) Export the key and certificate from PKCS12 to a JKS keystore:
```
sudo keytool -importkeystore -srckeystore -srcstoretype PKCS12 -destkeystore -deststoretype JKS -alias
```
Parameters:
- `PKCS12_keystore_path`: Path to the PKCS12 keystore created in Step 2.a, containing the certificate and key.
- `destination_keystore_path`: Path to the new JKS keystore where the certificate and key will be exported.
- `alias`: Alias used for the key and certificate pair within the JKS keystore.
3. Refer to the [keytool documentation](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) for more details.
3. Change the owner of the output keystore file to the "apigee" user:
```
sudo chown apigee:apigee
```
4. Add the following properties in [Apigee SSO configuration file](https://docs.apigee.com/private-cloud/v4.53.00/install-and-configure-edge-sso#commonconfig) and update them with the keystore file path, password, keystore type, and alias:
```
# Path to the keystore file
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks
# Keystore password
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123 # Password for accessing the keystore
# Keystore type
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS # Type of keystore, e.g., JKS, PKCS12
# Alias within keystore that stores the key and certificate
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert
```
5. Update Apigee SSO software on the SSO node as usual using the following command:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf
```
## New Edge UI
This section lists considerations regarding the Edge UI. For more information, see
[The new Edge UI for Private Cloud](https://docs.apigee.com/private-cloud/v4.53.00/new-edge-ui).
### Install the Edge UI
After you complete the initial installation, Apigee recommends that you install the Edge UI,
which is an enhanced user interface for developers and administrators of Apigee Edge for Private Cloud.
Note that the Edge UI requires that you disable Basic authentication and use an
such as SAML or LDAP.
For more information, see [Install the new Edge UI](https://docs.apigee.com/private-cloud/v4.53.00/install-new-edge-ui).
## Update with Apigee mTLS
To update [Apigee mTLS](https://docs.apigee.com/private-cloud/v4.53.00/mtls-intro) , do the following
steps:
- [Uninstall Apigee mTLS](https://docs.apigee.com/private-cloud/v4.53.00/mtls-uninstall).
- [Re-install Apigee mTLS](https://docs.apigee.com/private-cloud/v4.53.00/mtls-install).
## Rolling back an update
In the case of an update failure, you can try to correct the issue, and then execute
`update.sh` again. You can run the update multiple times and it continues the update
from where it last left off.
If the failure requires that you roll back the update to your previous version, see
[Roll back 4.53.00](https://docs.apigee.com/private-cloud/v4.53.00/rollback-45300) for detailed instructions.
> [!NOTE]
> **NOTE:** The Edge [all-in-one (AIO)](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies#allinoneinstallation) and [standalone (2-node)](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies#standaloneinstallation2host) topologies are designed for a getting started and prototyping environments, not for production. Therefore, there is no rollback procedure for the [all-in-one (AIO)](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies#allinoneinstallation) and [standalone (2-node)](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies#standaloneinstallation2host) topologies. In the situation where the update of these topologies fails, and retrying the update does not resolve the issue, the easiest option is to do a fresh install of 4.53.00.
## Logging update information
By default, the `update.sh` utility writes log information to:
```
/opt/apigee/var/log/apigee-setup/update.log
```
If the person running the `update.sh` utility does not have access to
that directory, it writes the log to the `/tmp` directory as a file named
`update_username.log`.
If the person does not have access to `/tmp`, the `update.sh` utility
fails.
## Zero-downtime update
A zero-downtime update, or rolling update, lets you update your Edge installation without
bringing down Edge.
Zero-downtime update is only possible with a 5-node configuration and larger.
The key to zero-downtime upgrading is to remove each Router, one at a time, from the load
balancer. You then update the Router and any other components on the same machine as the Router,
and then add the Router back to the load balancer.
1. Update the machines in the correct order for your installation as described [Order of machine update](https://docs.apigee.com/private-cloud/v4.53.00/update-apigee-edge-45202-45300#orderofmachineupdate).
2. When it is time to update the Routers, select any one Router and make it unreachable, as described in [Enabling/Disabling server
(Message Processor/Router) reachability](https://docs.apigee.com/private-cloud/v4.53.00/enablingdisabling-server-message-processorrouter-reachability).
3. Update the selected Router and all other Edge components on the same machine as the Router. All Edge configurations show a Router and Message Processor on the same node.
4. Make the Router reachable again.
5. Repeat steps 2 through 4 for the remaining Routers.
6. Continue the update for any remaining machines in your installation.
Take care of the following before and after the update:
- On combined Router and Message Processor node:
- Before update -- perform the following:
1. Make the Router unreachable.
2. Make the Message Processor unreachable.
- After update -- perform the following:
1. Make the Message Processor reachable.
2. Make the Router reachable.
- On single Router nodes:
- Before update, [make the Router unreachable](https://docs.apigee.com/private-cloud/v4.53.00/enablingdisabling-server-message-processorrouter-reachability#disablingenablingreachabilityonarouter).
- After update, [make the Router reachable](https://docs.apigee.com/private-cloud/v4.53.00/enablingdisabling-server-message-processorrouter-reachability#disablingenablingreachabilityonarouter).
- On single Message Processor nodes:
- Before update, [make the Message Processor unreachable](https://docs.apigee.com/private-cloud/v4.53.00/enablingdisabling-server-message-processorrouter-reachability#disablingenablingreachabilityonamessageprocessor).
- After update, [make the Message Processor reachable](https://docs.apigee.com/private-cloud/v4.53.00/enablingdisabling-server-message-processorrouter-reachability#disablingenablingreachabilityonamessageprocessor).
## Use a silent configuration file
You must pass a silent configuration file to the update command. The silent configuration file
should be the same one that you used to install Edge for Private Cloud 4.52.02.
## Update to
4.53.00 on a node with an external internet connection
Use the following procedure to update the Edge components on a node:
1. If present, disable any `cron` jobs configured to perform a repair operation on Cassandra until after the update completes.
2. Log in to your node as root to install the Edge RPMs.
> [!NOTE]
> **NOTE:** While RPM installation requires root access, you can perform Edge configuration without root access.
3. Disable SELinux as described in [Install
the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.53.00/install-edge-apigee-setup-utility).
4. **If you are installing on AWS** , execute the following `yum-configure-manager` commands:
yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
5. If you are currently on Edge 4.52.02:
1. Download the Edge `bootstrap_4.53.00.sh` file to `/tmp/bootstrap_4.53.00.sh`:
```
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
```
2. Install the Edge 4.53.00 `apigee-service` utility and dependencies by executing the following command:
```
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
Where uName:pWord are the username and password you received from Apigee. If you
omit pWord, you will be prompted to enter it.
By default, the installer checks that you have Java 1.8 installed. If you do not, the
installer installs it for you.
Use the `JAVA_FIX` option to specify how to handle
Java installation. `JAVA_FIX` takes the following values:
- `I`: Install OpenJDK 1.8 (default).
- `C`: Continue without installing Java.
- `Q`: Quit. For this option, you must install Java yourself.
3. Use `apigee-service` to update the `apigee-setup` utility, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. Update the `apigee-validate` utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. Update the `apigee-provision` utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. Run the `update` utility on your nodes by executing the following command:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
Do this in the order described in [Order of machine
update](https://docs.apigee.com/private-cloud/v4.53.00/update-apigee-edge-45202-45300#orderofmachineupdate).
Where:
- component is the Edge component to update. Possible values include:
- `cs`: Cassandra
- `edge`: All Edge components except Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server
- `ldap`: OpenLDAP
- `ps`: postgresql
- `qpid`: qpidd
- `sso`: Apigee SSO (if you installed SSO)
- `ue`: New Edge UI
- `ui`: Classic Edge UI
- `zk`: Zookeeper
- configFile is the same configuration file that you used to [define your Edge
components](https://docs.apigee.com/private-cloud/v4.53.00/install-edge-components-node#installedgecomponents) during the 4.52.02 installation.
> [!NOTE]
> **NOTE:** The configuration file must be readable by the "apigee" user. To change the owner, use the following command:
>
> ```
> chown apigee:apigee configFile
> ```
You can run `update.sh` against all components by setting component
to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
```
7. Restart the Edge UI components on all nodes running them, if you haven't done so already:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
8. Test the update by running the `apigee-validate` utility on the Management Server, as described in [Test the install](https://docs.apigee.com/private-cloud/v4.53.00/test-install).
If you later decide to roll back the update, use the procedure described in
[Roll back 4.53.00](https://docs.apigee.com/private-cloud/v4.53.00/rollback-45300).
## Update to 4.53.00 from a local repo
If your Edge nodes are behind a firewall, or in some other way are prohibited from accessing
the Apigee repository over the Internet, then you can perform the update from a local repository,
or mirror, of the Apigee repo.
After you create a local Edge repository, you have two options for updating Edge from the
local repo:
- Create a .tar file of the repo, copy the .tar file to a node, and then update Edge from the .tar file.
- Install a webserver on the node with the local repo so that other nodes can access it. Apigee provides the Nginx webserver for you to use, or you can use your own webserver.
To update from a local 4.53.00 repo:
1. Create a local 4.53.00 repo as described in "Create a local Apigee repository" at [Install the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.53.00/install-edge-apigee-setup-utility).
> [!NOTE]
> **NOTE:** If you already have an existing repo, you can add the 4.53.00 repo to it as described in "Update a local Apigee repository" at [Install the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.53.00/install-edge-apigee-setup-utility).
2. **To install apigee-service from a .tar file** :
1. On the node with the local repo, use the following command to package the local repo into a single .tar file named `/opt/apigee/data/apigee-mirror/apigee-4.53.00.tar.gz`:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
2. Copy the .tar file to the node where you want to update Edge. For example, copy it to the `/tmp` directory on the new node.
3. On the new node, untar the file to the `/tmp` directory:
```
tar -xzf apigee-4.53.00.tar.gz
```
This command creates a new directory, named `repos`, in the directory
containing the .tar file. For example `/tmp/repos`.
4. Install the Edge `apigee-service` utility and dependencies from `/tmp/repos`:
```
sudo bash /tmp/repos/bootstrap_4.53.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
Notice that you include the path to the repos directory in this command.
3. **To install apigee-service using the Nginx webserver:**
1. Configure the Nginx web server as described in "Install from the repo using the Nginx webserver" at [Install the Edge
apigee-setup utility](https://docs.apigee.com/private-cloud/v4.53.00/install-edge-apigee-setup-utility).
2. On the remote node, download the Edge `bootstrap_4.53.00.sh` file to `/tmp/bootstrap_4.53.00.sh`:
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
```
Where uName:pWord are the username and password you set previously for
the repo, and remoteRepo is the IP address or DNS name of the repo node.
3. On the remote node, install the Edge `apigee-setup` utility and dependencies:
```
sudo bash /tmp/bootstrap_4.53.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
Where uName:pWord are the repo username and password.
4. Use `apigee-service` to update the `apigee-setup` utility, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
5. Update the `apigee-validate` utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
6. Update the `apigee-provision` utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
7. Run the `update` utility on your nodes in the order described in [Order of machine update](https://docs.apigee.com/private-cloud/v4.53.00/update-apigee-edge-45202-45300#orderofmachineupdate):
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
Where:
- component is the Edge component to update. You typically update the following components:
- `cs`: Cassandra
- `edge`: All Edge components except Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server
- `ldap`: OpenLDAP
- `ps`: postgresql
- `qpid`: qpidd
- `sso`: Apigee SSO (if you installed SSO)
- `ue` New Edge UI
- `ui`: Classic Edge UI
- `zk`: Zookeeper
- configFile is the same configuration file that you used to [define your Edge components](https://docs.apigee.com/private-cloud/v4.53.00/install-edge-components-node#installedgecomponents) during the 4.50.00 or 4.51.00 installation.
> [!NOTE]
> **NOTE:** The configuration file must be readable by the "apigee" user. To change the owner, use the following command:
>
> ```
> chown apigee:apigee configFile
> ```
You can run `update.sh` against all components by setting component
to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
```
8. Restart the UI components on all nodes running it, if you haven't done so already:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
9. Test the update by running the `apigee-validate` utility on the Management Server, as described in [Test the install](https://docs.apigee.com/private-cloud/v4.53.00/test-install).
If you later decide to roll back the update, use the procedure described in
[Roll back 4.53.00](https://docs.apigee.com/private-cloud/v4.53.00/rollback-41901).
## Order of machine update
The order that you update the machines in an Edge installation is important:
- You must update **all** Cassandra and ZooKeeper nodes before you update any other nodes.
- For any machine with multiple Edge components (Management Server, Message Processor, Router, QPID Server but not Postgres Server), use the `-c edge` option to update them all at the same time.
- If a step specifies that it should be performed on multiple machines, perform it in the specified machine order.
- There is no separate step to update Monetization. It is updated when you specify the `-c edge` option.
> [!NOTE]
> **NOTE:** After you update the Edge UI component, you must restart the Edge UI service, as described in the update installation instructions.
### 1-node standalone upgrade
**To upgrade a 1-node standalone configuration to 4.53.00:**
1. Update all components:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
2. *(If you installed `apigee-adminapi`)* Update the `apigee-adminapi` utility:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
### 2-node standalone upgrade
Update the following components for a 2-node standalone installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies) for the list of Edge topologies and node numbers.
1. Update Cassandra and ZooKeeper on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
```
2. Update Postgres on machine 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
3. Update LDAP on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
4. Update Edge components on machine 2 and 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
5. Update Qpid on Machine 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
6. Update the UI on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
7. *(If you installed `apigee-adminapi`)* Updated the `apigee-adminapi` utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
8. *(If you installed Apigee SSO)* Update Apigee SSO on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you
[installed SSO](https://docs.apigee.com/private-cloud/v4.53.00/install-and-configure-edge-sso).
9. Restart the Edge UI component on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
### 5-node upgrade
Update the following components for a 5-node installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies) for the list of Edge topologies and node numbers.
1. Update Cassandra and ZooKeeper on machine 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
```
2. Update Postgres on machine 4:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
3. Update Postgres on machine 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
4. Update LDAP on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
5. Update Edge components on machine 4, 5, 1, 2, 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
6. Update Qpid on machine 4:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
7. Update Qpid on machine 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
8. Update the Edge UI:
- **Classic UI:** If you are using the classic UI, then update the `ui` component on machine 1, as the following example shows:
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
- **New Edge UI:** If you installed the new Edge UI, then update the `ue` component on the appropriate machine (may not be machine 1):
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
```
9. *(If you installed `apigee-adminapi`)* Updated the `apigee-adminapi` utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
10. *(If you installed Apigee SSO)* Update Apigee SSO on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you
[installed SSO](https://docs.apigee.com/private-cloud/v4.53.00/install-and-configure-edge-sso).
11. Restart the UI component:
- **Classic UI:** If you are using the classic UI, then restart the `edge-ui` component on machine 1, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- **New Edge UI:** If you installed the new Edge UI, then restart the `edge-management-ui` component on the appropriate machine (may not be machine 1):
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
### 9-node clustered upgrade
Update the following components for a 9-node clustered installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies) for the list of Edge topologies and node numbers.
1. Update Cassandra and ZooKeeper on machine 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
```
2. Update Postgres on machine 8:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
3. Update Postgres on machine 9:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
4. Update LDAP on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
5. Update Edge components on machine 6, 7, 8, 9, 1, 4, and 5 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
6. Update Qpid on machines 6 and 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
7. Update either the new UI (`ue`) or classic UI (`ui`) on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
8. *(If you installed `apigee-adminapi`)* Update the `apigee-adminapi` utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
9. *(If you installed Apigee SSO)* Update Apigee SSO on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you
[installed SSO](https://docs.apigee.com/private-cloud/v4.53.00/install-and-configure-edge-sso).
10. Restart the UI component:
- **Classic UI:** If you are using the classic UI, then restart the `edge-ui` component on machine 1, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- **New Edge UI:** If you installed the new Edge UI, then restart the `edge-management-ui` component on the appropriate machine (may not be machine 1):
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
### 13-node clustered upgrade
Update the following components for a 13-node clustered installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies) for the list of Edge topologies and node numbers.
1. Update Cassandra and ZooKeeper on machines 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
```
2. Update Postgres on machine 8:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
3. Update Postgres on machine 9:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
4. Update LDAP on machine 4 and 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
5. Update Edge components on machines 12, 13, 8, 9, 6, 7, 10, and 11 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
6. Update Qpid on machines 12 and 13:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
7. Update either the new UI (`ue`) or classic UI (`ui`) on machines 6 and 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
8. *(If you installed `apigee-adminapi`)* Updated the `apigee-adminapi` utility on machines 6 and 7:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
9. *(If you installed Apigee SSO)* Update Apigee SSO on machines 6 and 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you
[installed SSO](https://docs.apigee.com/private-cloud/v4.53.00/install-and-configure-edge-sso).
10. Restart the UI component:
- **Classic UI:** If you are using the classic UI, then restart the `edge-ui` component on machines 6 and 7, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- **New Edge UI:** If you installed the new Edge UI, then restart the `edge-management-ui` component on machines 6 and 7:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
### 12-node clustered upgrade
Update the following components for a 12-node clustered installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.53.00/installation-topologies) for the list of Edge topologies and node numbers.
1. Update Cassandra and ZooKeeper:
1. On machines 1, 2 and 3 in Data Center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
```
2. On machines 7, 8, and 9 in Data Center 2
```
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
```
2. Update Postgres:
1. Machine 6 in Data Center 1
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
2. Machine 12 in Data Center 2
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
3. Update LDAP:
1. Machine 1 in Data Center 1
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
2. Machine 7 in Data Center 2
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
4. Update Edge components:
1. Machines 4, 5, 6, 1, 2, 3 in Data Center 1
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
2. Machines 10, 11, 12, 7, 8, 9 in Data Center 2
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
5. Update qpidd:
1. Machines 4, 5 in Data Center 1
1. Update `qpidd` on machine 4:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
2. Update `qpidd` on machine 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
2. Machines 10, 11 in Data Center 2
1. Update `qpidd `on machine 10:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
2. Update `qpidd `on machine 11:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
6. Update either the new UI (`ue`) or classic UI (`ui`):
1. Machine 1 in Data Center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
2. Machine 7 in Data Center 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
7. *(If you installed `apigee-adminapi`)* Updated the `apigee-adminapi` utility:
1. Machine 1 in Data Center 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
2. Machine 7 in Data Center 2:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
8. *(If you installed Apigee SSO)* Update Apigee SSO:
1. Machine 1 in Data Center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
2. Machine 7 in Data Center 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
3. Where sso_config_file is the configuration file you created when you [installed SSO](https://docs.apigee.com/private-cloud/v4.53.00/install-and-configure-edge-sso).
9. Restart the new Edge UI (`edge-management-ui`) or classic Edge UI (`edge-ui`) component on machines 1 and 7:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```
### For a non-standard configuration
If you have a non-standard configuration, then update Edge components in the following
order:
1. ZooKeeper
2. Cassandra
3. ps
4. LDAP
5. Edge, meaning the "-c edge" profile on all nodes in the order: nodes with Qpid server, Edge Postgres Server, Management Server, Message Processor, and Router.
> [!NOTE]
> **NOTE:** If a node has both Qpid server and Edge Postgres Server installed, run the "-c edge" profile step.
6. qpidd
7. Edge UI (either classic or new)
8. `apigee-adminapi`
9. Apigee SSO
After you finish updating, be sure to restart the Edge UI component on all machines running
it.
*[IDP]: Identity Provider