Apigee supports upgrading Edge for Private Cloud directly from version 4.51.00, 4.52.00, or 4.52.01 to version 4.52.02. This page describes how to perform such upgrades.
> [!WARNING]
> **Caution:** It is strongly recommended to use the latest patch available for Private Cloud 4.52.02 during upgrades to ensure upgrades are seamless and you have the latest features and fixes.
> [!WARNING]
> **Caution:** Edge for Private Cloud 4.52.02 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.
## 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 Apigee on Red Hat Enterprise Linux (RHEL) 6.10, you first need to update to one of the supported Operating Systems for Edge for Private Cloud 4.52.02 as listed in [Edge for private cloud supported software](https://docs.apigee.com/release/supported-software). See [Upgrading Red Hat Enterprise Linux](https://docs.apigee.com/how-to-guides/upgrade-rhel).
## Update prerequisites
Ensure 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.52.02/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
```
> [!NOTE]
> **Note:** Ensure that **edge-management-server** setup on your existing version is running successfully without failures. Address any failures in the **edge-management-server** setup from previous versions before proceeding with further upgrade.
- **Ensure that the Cassandra Compaction Strategy is `LeveledCompactionStrategy`**
Depending on your current version, perform the necessary changes to the Cassandra compaction strategy. Follow the steps below and then return to the main upgrade procedure:
- If you are upgrading from version 4.51.00, refer to the [Cassandra Compaction Strategy document for v4.51.00](https://docs.apigee.com/private-cloud/v4.51.00/cassandra-compaction-strategy).
- If you are upgrading from version 4.52.00, refer to the [Cassandra Compaction Strategy document for v4.52.00](https://docs.apigee.com/private-cloud/v4.52.00/cassandra-compaction-strategy).
- If you are upgrading from version 4.52.01, refer to the [Cassandra Compaction Strategy document for v4.52.01](https://docs.apigee.com/private-cloud/v4.52.01/cassandra-compaction-strategy).
## What special steps to consider for upgrade
To upgrade to Edge for Private Cloud 4.52.02, consider running specific steps for upgrading certain software. Necessary steps depend on your current version. Refer to the table below for the various software requiring supplementary steps, and follow the detailed instructions for each. After completing the necessary tasks, return to the main upgrade procedure to continue the upgrade process.
| Current version | Software that requires special steps for upgrade to 4.52.02 |
|---|---|
| 4.52.01 | [Cassandra](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradecassandra) |
| 4.52.00 | [Zookeeper](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradezookeeper), [Cassandra](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradecassandra), [Qpid](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradeqpid) |
| 4.51.00 | [Zookeeper](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradezookeeper), [Postgres](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradepostgres), [Cassandra](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradecassandra), [Qpid](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradeqpid) |
After performing the necessary steps based on your version, return to the main upgrade procedure to continue.
## Automatic propagation of property settings
If you have set any properties by editing `.properties` files in `/opt/apigee/customer/application`, those values will be retained after the update.
## Upgrade to Zookeeper 3.8.3
Edge for Private Cloud 4.52.02 does not include a Zookeeper upgrade. However, if you are upgrading from a version older than 4.52.01, you are required to follow the Zookeeper upgrade steps outlined below.
- If you are upgrading from Edge for Private Cloud versions 4.51.00 or 4.52.00, refer to the steps in [Required upgrade to Zookeeper 3.8.3](https://docs.apigee.com/private-cloud/v4.52.01/update-apigee-edge-45100-45200#required-upgrade-to-zookeeper-3.8.3) to upgrade Zookeeper.
- If you are upgrading from Edge for Private Cloud version 4.52.01, you should already be using Zookeeper version 3.8.3, and you don't need to follow any special steps for upgrading Zookeeper.
> [!NOTE]
> **Note:**
>
> Upgrading from Edge for Private Cloud 4.52.01 to 4.52.02 is simplified because Zookeeper and Cassandra are typically co-located on the same host or virtual machine, which removes the necessity for separate Zookeeper upgrade procedures alongside the significant Cassandra upgrade.
>
> Should Zookeeper require updating with specific steps, upgrade Zookeeper across all data centers by updating one node at a time. Once all Zookeeper nodes globally are updated, then upgrade Cassandra one data center at a time, adhering to the procedure outlined later in this article.
>
> The following command facilitates a separate Zookeeper upgrade:
>
> `/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile`
>
> For a Zookeeper rollback, use the [standard zookeeper rollback procedure.](https://docs.apigee.com/private-cloud/v4.52.01/update-apigee-edge-45100-45200#rollback) If a rollback becomes necessary for Cassandra or other components, those components should be rolled back; a Zookeeper rollback is not required.
## Upgrade to Postgres 14
- If you are upgrading from Edge for Private Cloud 4.51.00 to 4.52.02, you must follow the steps to upgrade Postgres, even though Edge for Private Cloud 4.52.02 does not include a Postgres upgrade. Upgrading from Edge for Private Cloud 4.51.00 to 4.52.02 requires additional Postgres upgrade steps. Please refer to the [Required upgrade to Postgres 14](https://docs.apigee.com/private-cloud/v4.52.00/update-apigee-edge-45100-45200#required-upgrade-to-postgres-14) section.
- If you are upgrading from Edge for Private Cloud 4.52.00 or 4.52.01 to 4.52.02, no additional Postgres upgrade steps are required.
> [!NOTE]
> **Note:**
>
> If Postgres requires updating with special steps, perform this independently before upgrading Cassandra. It is recommended to upgrade Cassandra one data center at a time. However, Postgres should be updated across all data centers by updating one postgres node at a time.After updating Postgres, verify that the cluster is fully operational before proceeding with the upgrade of Cassandra and other components.
>
> For a Postgres rollback, follow the [standard Postgres rollback procedure.](https://docs.apigee.com/private-cloud/v4.52.00/rollback-45200#rollback-postgres) If a rollback is necessary for Cassandra or other components, roll back those components; a Postgres rollback is not required.
## Upgrade to Cassandra 3.11.16
Apigee Edge for Private Cloud 4.52.02 includes an upgrade of Cassandra to version 3.11.16. Cassandra is a critical component of Apigee, and this upgrade also includes updates to the driver software in various runtime and management components used to query and write to Cassandra.
As this is a major upgrade, certain changes to Apigee's data model in Cassandra were necessary to ensure optimal performance in newer versions. Although these changes are minimal, the upgrade process disrupts certain management APIs when the upgrade is kicked off. The exact management APIs that are generally disrupted are listed in relevant sections below.
**Additionally, the upgrade process causes disruption to a larger set of runtime proxy flows and management APIs in the data center that is being upgraded.** It is critical that you isolate your runtime and management traffic from the data center being upgraded so as to minimize such disruption. Read sections for [single data center](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#singledatacenter) and [multiple data centers](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#multipledatacenters) below for more information.
> [!WARNING]
> **Caution:**
>
> While Apigee has certified Cassandra upgrade, it is strongly advised that you thoroughly test the upgrade in your lower environments before applying it in production to ensure that you are familiar with the upgrade steps and that the upgrade is not disruptive.
> [!NOTE]
> **Note:** The `cassandra-cli` tool is no longer supported in Cassandra 3.X and is not available for your use.
### Developer Portal - Documenting APIs
The Apigee Drupal developer portal offers various features for documenting your APIs. While it is recommended to transition away from using the Drupal 7-based developer portal, if you are still using it and utilizing its SmartDocs feature, [Using SmartDocs APIs](https://docs.apigee.com/api-platform/publish/drupal/using-smartdocs-document-apis) document applies to you. If you are using newer versions of the developer portal, there will be no impact on your API documentation during this upgrade.
When you upgrade Apigee to version 4.52.02, any API models created using the SmartDocs feature of the Drupal 7 developer portal will not be migrated to the newer version automatically. You are expected to manually export each model using the developer portal and import it again after completing the upgrade.
### Terminology used below
**Runtime:** Runtime encompasses the handling of your runtime proxy traffic. It includes all operations performed by your Routers and Message Processors to effectively process a runtime API request for existing proxies. However, it does not include the deployment of new proxies or new revisions of proxies.
**Management:** Management includes the administration of your Apigee Edge system. This includes, but is not limited to, deployments, modifications of apps, products, target servers, keystores, etc. All management APIs (and their clients such as Apigee UI and developer portal) are included in this scope.
During this upgrade, Runtime and Management traffic is impacted in the region or data center (DC) where the update is being executed. Irrespective of the data center being updated, there is an impact to certain management APIs in all data centers. This impact is noted after each step.
In each step below, state of runtime and management is described as you progress through the various stages of the upgrade procedure.
### Upgrade strategies
#### Multiple data centers
The upgrade must be performed **one data center at a time** to ensure traffic continuity and avoid downtime. Before upgrading a DC, traffic should be rerouted to other functional DCs.
**Note:**
To avoid traffic impact during the upgrade, follow a **data center-by-data center (DC-by-DC) approach** by temporarily redirecting traffic away from the data center being upgraded. This ensures a controlled upgrade process for **Cassandra** , **Management Server** , and **Runtime nodes** while maintaining service availability.
For a **two data centers setup**, follow these high-level steps:
- **Redirect traffic** from **DC-1** to **DC-2** and block incoming traffic to DC-1.
- **Upgrade DC-1** , including **Cassandra** , **Management Server** and **Runtime components**.
- **Redirect traffic** back to **DC-1** and block incoming traffic to DC-2.
- **Upgrade DC-2** , including **Cassandra** , **Management Server** and **Runtime components**.
This process ensures seamless traffic management while performing the upgrade. A similar pattern should be followed for setups with more than two data centers, where traffic is temporarily redirected to data centers that are either fully upgraded or not yet upgraded.
#### Single data center
For a single data center setup, **the upgrade procedure will encounter a significant impact on runtime traffic and certain management APIs.** The following options are available for a single data center setup.
- Expand your Edge for Private cloud cluster to a temporary data center by [adding a data center](https://docs.apigee.com/private-cloud/v4.52.00/adding-data-center) alongside the existing one to handle traffic during the upgrade, then [decommission](https://docs.apigee.com/private-cloud/v4.52.00/decommission-data-center) one of the data centers upon completion of the upgrade process.
- If you are unable to expand to an additional data center, prepare for downtime and schedule the upgrade during periods of low traffic to minimize the impact on management APIs and the runtime traffic.
It is advised to expand to an additional data center to avoid impact to runtime traffic and management APIs. During upgrade, impacts to the data center being upgraded include, but not limited to the following areas:
- Runtime APIs refreshing OAuth tokens
- Runtime APIs using Access Entity Policy
- Management APIs listing developer apps
- Management APIs listing products
The impact described above is in addition to the specific management APIs that will remain non-functional on all data centers until all data centers are upgraded. Such management APIs are listed in the steps in subsequent sections.
### Rollback - high level
- **Impact During Rollback**
Rolling back from Cassandra 3.11.x to 2.1.x affects both runtime and management traffic within the data center (DC) where the rollback is being performed. Additionally, certain management APIs may experience disruptions across all data centers, regardless of which DC is currently being rolled back.
- **Follow DC by DC Rollback Approach**
Rollback must be executed one data center at a time to maintain service continuity and prevent downtime. Prior to initiating rollback in a specific DC, ensure that application traffic is rerouted to another fully operational data center.
- **Rolling Back Partially Upgraded Cluster**
If at least one data center remains fully operational on the older version of Cassandra (2.1.22), other upgraded DCs can be rolled back by performing a rebuild from the fully functional Cassandra 2.1.X DC.
- **Cluster-Wide Rollback**
If the entire Cassandra cluster has been upgraded and rollback is required, it must be performed using backups or VM snapshots. This approach is complex and will likely lead to temporary downtime or data loss.
- **Pre-Upgrade Considerations**
It is important that you familiarize yourself with rollback procedures before attempting the upgrade. It is critical that nuances of rollback are being considered while upgrading to ensure appropriate rollback paths are available.
#### Rollback clusters with a single data center
Upgrading Cassandra from version 2.1.x to 3.11.x can significantly impact runtime traffic and certain management APIs. These impacts also apply during rollback and may result in downtime or data loss.
For production workloads, it is strongly recommended to [provision a new data center](https://docs.apigee.com/private-cloud/v4.52.02/adding-data-center) prior to the upgrade. This allows for a safer rollback path without data loss or disruption to API traffic. The additional data center can be decommissioned after the upgrade is successfully completed.
If adding a new data center is not feasible but rollback capability is still required, ensure that reliable backups are taken prior to the upgrade. Restoring Cassandra 2.1.x from backups is possible, but this approach may involve service downtime and potential data loss.
#### Rollback clusters with multiple data centers
Rolling back multiple data centers follows a data center--by--data center (DC-by-DC) approach. In this approach, traffic from the data center being rolled back is redirected to other functional data centers, ensuring a controlled and isolated rollback process for **Cassandra** , **Management Server** , and **Runtime nodes** to avoid traffic disruption.
Refer to section [Rollback the Cassandra 3.11.16](https://docs.apigee.com/private-cloud/v4.52.02/rollback-45202#update-version) update for details.
**Note:**
Careful planning and testing are crucial for a successful upgrade. Always consider the rollback limitations and follow the recommended methodology.
### Step 0: Start state
> [!NOTE]
> **Note:**
>
> Please ensure that Zookeeper has been upgraded by referring to [upgrade Zookeeper 3.8.3](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradezookeeper) before proceeding with Cassandra upgrade. Sometimes Zookeeper and Cassandra are co-located in the same machine.
- Zookeeper, Postgres and LDAP components are already upgraded to 4.52.02 versions. Your Edge for a private cloud cluster is stable and working. If rollback is required, the cluster will be rolled back to this state.
- Cassandra in Apigee running with version 2.1.22.
- Edge components:
- Management-server communicating with Cassandra via older thrift protocol.
- Runtime servers (Message Processors \& Routers) communicating with Cassandra via older thrift protocol.
| Runtime state at this stage | Management state at this stage |
|---|---|
| Runtime fully functional | Management fully functional |
### 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. [Change Cassandra to use LeveledCompactionStrategy.](https://docs.apigee.com/private-cloud/v4.52.02/cassandra-compaction-strategy)
2. [Backup Cassandra using Apigee.](https://docs.apigee.com/private-cloud/v4.52.00/how-perform-backup)
3. Take VM snapshots of Cassandra nodes (if feasible).
4. Create a Cassandra upgrade configuration file on each Cassandra node at `/opt/apigee/apigee-cassandra/cass_upgrade.conf` with the following contents:
```
# IP Address of node
HOSTIP=10.0.0.1
# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=
# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=
# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160
# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042
# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
```
If the file cannot be created at `/opt/apigee/apigee-cassandra/cass_upgrade.conf`, create the file `/opt/silent.conf` with the same contents on each Cassandra node.
> [!WARNING]
> **Caution:** Apigee's upgrade installer will look for the file in the locations listed above. If the file is not present in either of the locations listed above, the upgrade will fail with a message like below:
>
> ```
> could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
> file does not exist or cannot be sourced
> could not read env location: '/opt/silent.conf'
> file does not exist or cannot be sourced
> ```
> If this happens, the upgrade will fail but Cassandra service on the node will likely be in a stopped state. You can start the Cassandra service as usual and reattempt the upgrade by placing the configuration file in any one of the expected locations. Additionally, if the file is found but the configurations provided are incorrect (for example, Cassandra credentials are incorrect), then the upgrade will fail with an error like below:
>
> ```
> Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
> ```
> In this case, similarly, start the Cassandra service if it is stopped when the upgrade fails and reattempt the upgrade after fixing configurations in the file.
5. If you use the SmartDocs feature of Apigee Drupal 7 developer portal, [take an export](https://docs.apigee.com/api-platform/publish/drupal/using-smartdocs-document-apis#exportingandimportingamodel) of each of your models by downloading them in JSON format from the developer portal UI. These models will need to be imported back into Apigee after the management servers are updated.
6. Ensure that ports 9160 and 9042 are accessible from all Edge components to Cassandra nodes if not already present. Refer to [Port requirements](https://docs.apigee.com/private-cloud/v4.52.02/port-requirements) for more information.
> [!WARNING]
> **Caution:** All these steps are critical for upgrading Cassandra to version 3, for ensuring minimal data loss if a rollback is required during upgrade and to ensure you don't lose any data after upgrade - like your API documentation in smartdocs. It is imperative that these steps are done carefully and not skipped.
### Step 2: Redirect traffic away from the first data center
1. Block incoming runtime and management traffic from the first data center.
2. Redirect all runtime traffic and management APIs to the other functional data centers.
3. Validate that runtime and management traffic are successfully handled by the other DC(s).
### Step 3: Upgrade all Cassandra nodes in the first data center
1. Upgrade all Cassandra nodes in the data center 1 by 1. Run the following commands on each node one by one:
```
/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
```
The above will output something along the lines of:
```
Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified
```
3. Run the following `post_upgrade` command on each Cassandra node one by one after the upgrade is complete:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```
| Runtime state at this stage | Management state at this stage |
|---|---|
| - Runtime traffic blocked on data centers being upgraded - Runtime fully functional on other data centers | - Management traffic blocked on data centers being upgraded. - Following management function is degraded after Cassandra is upgraded in other data centers: - [Management API to create API product with environment](https://apidocs.apigee.com/docs/api-products/1/routes/organizations/%7Borg_name%7D/apiproducts/post) - [Management API to update an API product with environment](https://apidocs.apigee.com/docs/api-products/1/routes/organizations/%7Borg_name%7D/apiproducts/%7Bapiproduct_name%7D/put) - [Management API to delete an organization](https://apidocs.apigee.com/docs/organizations/1/routes/organizations/%7Borg_name%7D/delete) |
### Step 4: Upgrade all management nodes in the first data center
> [!WARNING]
> **Warning:** During upgrade of the management-server nodes you may encounter the below WARNING messages and upgrading the management-server may take longer to complete. However, such warnings can be ignored.
>
> ```
> Warning:schema version mismatch detected; check the schema versions of your nodes in system.local and system.peers.
> ```
> In subsequent steps, you will be re-running setup of management server nodes where such warnings will not occur.
Upgrade all management nodes in the data center:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
| Runtime state at this stage | Management state at this stage |
|---|---|
| - Runtime traffic blocked on data centers being upgraded - Runtime fully functional | - Management traffic blocked on data centers being upgraded. - Following management function is degraded after Cassandra is upgraded: - [Management API to create API product with environment](https://apidocs.apigee.com/docs/api-products/1/routes/organizations/%7Borg_name%7D/apiproducts/post) - [Management API to update an API product with environment](https://apidocs.apigee.com/docs/api-products/1/routes/organizations/%7Borg_name%7D/apiproducts/%7Bapiproduct_name%7D/put) - [Management API to delete an organization](https://apidocs.apigee.com/docs/organizations/1/routes/organizations/%7Borg_name%7D/delete) |
### Step 5: Upgrade all runtime nodes in the first data center
Upgrade all Routers and Message Processor nodes in the data center one by one:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
| Runtime state at this stage | Management state at this stage |
|---|---|
| - Runtime traffic blocked on data centers being upgraded - Runtime fully functional on other data centers | - Management traffic blocked on data centers being upgraded. - Following management function is degraded after Cassandra is upgraded in other data centers: - [Management API to create API product with environment](https://apidocs.apigee.com/docs/api-products/1/routes/organizations/%7Borg_name%7D/apiproducts/post) - [Management API to update an API product with environment](https://apidocs.apigee.com/docs/api-products/1/routes/organizations/%7Borg_name%7D/apiproducts/%7Bapiproduct_name%7D/put) - [Management API to delete an organization](https://apidocs.apigee.com/docs/organizations/1/routes/organizations/%7Borg_name%7D/delete) |
### Step 6: Redirect traffic back to the first data center
- Once the First data center is upgraded with Cassandra, runtime components and management-server, re-enable runtime and management traffic to First data center.
- Ensure the runtime and management traffic is successful across DCs.
### Step 7: Upgrade other data centers
Repeat [Step 1](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#prepforupgrade) to [Step 6](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#redirecttraffic) on remaining data centers, one at a time by redirecting traffic away from such data centers, updating the Apigee software and re-enabling traffic on such data centers.
### Step 8: Rerun upgrade step in all the Management nodes
Rerun the following upgrade command in all management nodes across data centers:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
### Step 9 - \[Optional\] Import smartdocs which were previously exported
Once all management servers are upgraded, you can [import the smart docs models](https://docs.apigee.com/api-platform/publish/drupal/using-smartdocs-document-apis#exportingandimportingamodel) you had exported in Step 1. You can decide to do this later.
You only need to do this if you use Drupal 7 based developer portal and are using the smartdocs feature.
| Runtime state at this stage | Management state at this stage |
|---|---|
| Runtime fully functional | Management fully functional |
### Step 10 - Drop Unused tables
> [!WARNING]
> **Warning:** This step should be followed only after the entire Cassandra cluster across all regions (or data centers) has been upgraded. All Cassandra nodes in all regions must be upgraded. Do not execute these steps if your Cassandra cluster is only partially upgraded.
Run the following command to drop old unused tables from the Cassandra cluster. Until this is run, you cannot use certain features of Cassandra (like setting up new authentication - old authentication mechanisms will continue to work). This command can only be executed on only one node in the cluster
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile
```
### Step 11 - Upgrade all remaining Edge and other components for Private Cloud 4.52.02
Upgrade all remaining `edge-qpid-server` and `edge-postgres-server` nodes in all regions one by one.
At this stage, if you are upgrading from versions earlier than Edge for Private Cloud 4.52.01 as below to do additional steps for upgrading [Qpid,](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradeqpid) [Postgres](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradepostgres) respectively and upgrade remaining components as per these [steps.](https://docs.apigee.com/private-cloud/v4.52.01/update-apigee-edge-45100-45200#orderofmachineupdate-fora12hostclusteredinstallation)
## Upgrade to Qpid J-Broker
Even though Edge for Private Cloud 4.52.02 does not include an upgrade to Qpid, if you are upgrading from versions older than 4.52.01, you need to follow the steps to upgrade QPID.
- If you are upgrading from Edge for Private Cloud 4.51.00 or 4.52.00 to 4.52.02, it is necessary to follow additional Qpid upgrade steps. Please refer to the [Upgrade Qpid](https://docs.apigee.com/private-cloud/v4.52.01/update-apigee-edge-45100-45200#upgrade-qpid) section if you are upgrading from version 4.51.00 or 4.52.00 to 4.52.02.
- If you are upgrading from Edge for Private Cloud 4.52.01 to 4.52.02, you should already be using the latest version of the Qpid Broker, and no additional Qpidupgrade steps are necessary.
## 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.52.02/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.52.02/install-new-edge-ui).
### Update the Edge UI
To update the Edge UI component, consider the version of Edge for the Private Cloud that you
are upgrading from:
- **From 4.51.00 to 4.52.00** (with the new Edge UI already installed): Use the [upgrade instructions in this section](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#orderofmachineupdate) for the `edge-management-ui` component.
## Update with Apigee mTLS
To update [Apigee mTLS](https://docs.apigee.com/private-cloud/v4.52.02/mtls-intro) , do the following
steps:
- [Uninstall Apigee mTLS](https://docs.apigee.com/private-cloud/v4.52.02/mtls-uninstall).
- [Re-install Apigee mTLS](https://docs.apigee.com/private-cloud/v4.52.02/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.52.00](https://docs.apigee.com/private-cloud/v4.52.02/rollback-45202) for detailed instructions.
> [!NOTE]
> **NOTE:** The Edge [all-in-one (AIO)](https://docs.apigee.com/private-cloud/v4.52.02/installation-topologies#allinoneinstallation) and [standalone (2-node)](https://docs.apigee.com/private-cloud/v4.52.02/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.52.02/installation-topologies#allinoneinstallation) and [standalone (2-node)](https://docs.apigee.com/private-cloud/v4.52.02/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.52.02.
## 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 you do 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. Then, update the Router and any other components on the same machine as the Router, and 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.52.02/update-apigee-edge-45100-45200#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.52.02/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.52.02/enablingdisabling-server-message-processorrouter-reachability#disablingenablingreachabilityonarouter).
- After update, [make the Router reachable](https://docs.apigee.com/private-cloud/v4.52.02/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.52.02/enablingdisabling-server-message-processorrouter-reachability#disablingenablingreachabilityonamessageprocessor).
- After update, [make the Message Processor reachable](https://docs.apigee.com/private-cloud/v4.52.02/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 4.50.00 or 4.51.00.
## Update to
4.52.02 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. Install `yum-utils` and `yum-plugin-priorities`:
> [!NOTE]
> **Note:** If your operating system is RHEL 8.0 - 8.6, skip this step.
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
4. Disable SELinux as described in [Install
the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.52.02/install-edge-apigee-setup-utility).
5. **If you are installing on Oracle 7.x** , execute the following command:
```
sudo yum-config-manager --enable ol7_optional_latest
```
6. **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
7. If you are currently on Edge 4.51.00:
1. Download the Edge `bootstrap_4.52.02.sh` file to `/tmp/bootstrap_4.52.02.sh`:
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
2. Install the Edge 4.52.02 `apigee-service` utility and dependencies by executing the following command:
```
sudo bash /tmp/bootstrap_4.52.02.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.52.02/update-apigee-edge-45100-45200#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.52.02/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 ./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.52.02/test-install).
If you later decide to roll back the update, use the procedure described in [Roll back 4.52.02.](https://docs.apigee.com/private-cloud/v4.52.02/rollback-45202)
## Update to 4.52.02 from a local repo
If your Edge nodes are behind a firewall, or are otherwise prohibited from accessing the Apigee repository over the Internet, then you can perform the update from a local repository, or mirror of the Apigee repository.#heading
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.52.02 repo:
1. Create a local 4.52.02 repo as described in "Create a local Apigee repository" at [Install the Edge apigee-setup utility](https://docs.apigee.com/private-cloud/v4.52.02/install-edge-apigee-setup-utility).
> [!NOTE]
> **NOTE:** If you already have an existing repo, you can add the 4.52.02 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.52.02/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.52.02.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.52.02.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.52.02.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.52.02/install-edge-apigee-setup-utility).
2. On the remote node, download the Edge `bootstrap_4.52.02.sh` file to `/tmp/bootstrap_4.52.02.sh`:
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.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.52.02.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.52.02/update-apigee-edge-45100-45200#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.52.02/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.52.02/test-install).
If you later decide to roll back the update, use the procedure described in
[Roll back 4.52.02](https://docs.apigee.com/private-cloud/v4.52.02/rollback-45202).
## Order of machine update - upgrade from 4.51.00 (or) 4.52.00 (or) 4.52.01
The order that you update the machines in an Edge installation is important:
- You must update all ZooKeeper nodes across data centers before upgrading all other components. If you are upgrading from Edge Private Cloud 4.51.00 (or) 4.52.00, you will also need to follow additional steps to [upgrade zookeeper](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradezookeeper).
- You must update Postgresql across all the data centers. If you are upgrading from Edge Private Cloud 4.51.00, you will also need to follow additional steps to [upgrade postgres](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradepostgres).
- You must update LDAP nodes across all the data centers.
- You must update all Cassandra, Management Server, Message Processor and Router nodes, [one data center at a time](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradecassandra), until all data centers are upgraded.
- You must update `edge-qpid-server` \& `edge-postgres-server` components across all data centers.
- You must upgrade Qpid nodes across all data centers. If you are upgrading from Edge Private Cloud 4.51.00 (or) 4.52.00, you will also need to follow additional steps to [upgrade Qpid](https://docs.apigee.com/private-cloud/v4.52.02/update-apigee-edge-45100-45200#upgradeqpid).
- Update Edge UI and New Edge UI, SSO nodes across all data centers.
- 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.52.02:**
1. Update all components:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
2. (If you installed `apigee-adminapi`) Updated 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.52.02/installation-topologies) for the list of Edge topologies and node numbers.
1. Update Zookeeper on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c 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 Cassandra on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
5. Update Edge components on machine 1 and 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
6. Update Qpid on Machine 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
7. Update the UI on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
8. *(If you installed `apigee-adminapi`)* Updated 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.52.02/install-and-configure-edge-sso).
10. 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.52.02/installation-topologies) for the list of Edge topologies and node numbers.
1. Update ZooKeeper on machines 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c 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 Cassandra on machines 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
6. Update Edge components on machines 1, 2, 3, 4, 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
7. Update Qpid on machine 4:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
8. Update Qpid on machine 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
9. 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
```
10. *(If you installed `apigee-adminapi`)* Updated the `apigee-adminapi` utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
11. *(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.52.02/install-and-configure-edge-sso).
12. 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 cluster upgrade
Update the following components for a 9-node clustered installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.52.02/installation-topologies) for the list of Edge topologies and node numbers.
1. Update ZooKeeper on machine 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c 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 Cassandra on machine 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
6. Update Edge components on machines 1, 4, 5, 6, 7, 8, and 9 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
7. Update Qpid on machines 6 and 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
8. 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
```
9. *(If you installed `apigee-adminapi`)* Update 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.52.02/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
```
### 13-node cluster upgrade
Update the following components for a 13-node clustered installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.52.02/installation-topologies) for the list of Edge topologies and node numbers.
1. Update ZooKeeper on machines 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c 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 machines 4 and 5:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
5. Update Cassandra on machines 1, 2, and 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
6. Update Edge components on machines 6, 7, 10, 11, 12, 13, 8, and 9 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
7. Update Qpid on machines 12 and 13:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
8. 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
```
9. *(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
```
10. *(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.52.02/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 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 cluster upgrade
Update the following components for a 12-node clustered installation:
See [Installation topologies](https://docs.apigee.com/private-cloud/v4.52.02/installation-topologies) for the list of Edge topologies and node numbers.
1. Update ZooKeeper on machines 1,2,3,7,8,9 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
2. Update Postgres on machines 6,12 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
3. Update LDAP on machines 1,7 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
4. Block the traffic in DC-1 and make sure all the traffic rerouted to other DC-2
5. Update Update Cassandra on machine 1,2,3 in DC-1:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
6. Update Management Server on machine 1 in DC-1:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
7. Update Router, Message Processor on machine 2,3 in DC-1:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
8. Unblock the traffic in DC-1 and validate the DC-1 and proceed with the DC-2 by blocking traffic in DC-2 and reroute the traffic to DC-1
9. Update Cassandra on machine 7,8,9 in DC-2:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
10. Update Management Server on machine 7 in DC-2:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
11. Update Router, Message Processor on machine 8,9 in DC-2:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
12. Unblock the traffic in DC-2 and now, both DCs will handle traffic
13. Re-run the update command in all the management-server across DCs on machine 1 \& 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
14. Update edge-qpid-server \& edge-postgres-server on machine 4,5,6,10,11,12 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
15. Update Qpid on machine 4,5,10,11 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
16. Update either the new UI (ue) or classic UI (ui) in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
17. (If you installed apigee-adminapi) Update the apigee-adminapi in both DCs:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
18. (If you installed Apigee SSO) Update Apigee SSO nodes in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
19. Restart the new Edge UI (edge-management-ui) or classic Edge UI (edge-ui) component in both DCs:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```
*[IDP]: Identity Provider