Update Apigee Edge 4.53.00 or 4.53.01 to 4.54.00

Apigee supports upgrading Edge for Private Cloud directly from version 4.53.00 or 4.53.01 to version 4.54.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.

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.

Pre-read materials

Review the following topics for important information about changes introduced in Edge for Private Cloud 4.54.00:

  • Changes in 4.54.00: Review changes in TLS and Java Callout that require preparation before upgrading. For more information, see Changes in 4.54.00.

  • Dual-Java runtime architecture (Java 17 and Java 21): Starting in 4.54.00, Edge for Private Cloud removes support for Java 8 and runs components on either Java 17 or Java 21. For more information, see Changes in 4.54.00.

  • No automatic Java installation during bootstrap: Edge for Private Cloud 4.54.00 has the capability to discover Java installations and validates that you have both Java 17 and 21 installed.

  • New Edge UI in 4.54.00: Learn about the transition to the New Edge UI as the default management interface and the removal of the Classic UI (edge-ui). For more information, see New Edge UI.

  • Apigee SSO in 4.54.00: Understand the updated SSO architecture and configuration changes for authentication. For more information, see Apigee SSO.

  • Nginx 1.30 in 4.54.00: Review the automatic Nginx 1.30.x upgrade on Edge Routers, potential runtime impacts, and mitigation steps. For more information, see Nginx 1.30 Changes.

Upgrade prerequisites

Make sure of the following prerequisites before upgrading Apigee Edge:

  • Review release notes and new features

    Ensure you thoroughly review and understand all new features, behavior changes, and retirements detailed in the Edge for Private Cloud release notes for version 4.54.00 prior to initiating the upgrade process.

  • Automatic Java binary discovery and coexistence during upgrade: Install Java using standard package managers (such as yum) or standard locations (such as /usr/lib/jvm or update-alternatives). You do not need to configure both versions on the system PATH simultaneously. Do not uninstall Java 8 prior to upgrading. Keep Java 8 installed alongside Java 17 and Java 21 so that existing Edge for Private Cloud 4.53.xx services continue running uninterrupted until they are updated.

  • 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.

  • Backup of silent configuration file

    Ensure that backup copies of the silent configuration files for Edge for Private Cloud 4.53.00 or 4.53.01 are retained to facilitate a rollback if required.

  • 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.53.00 (or) 4.53.01 and are now planning to upgrade to version 4.54.00, make sure you completed the required post-upgrade steps for Cassandra. These steps are outlined in the version 4.53.00 (or) 4.53.01 upgrade documentation and also, mentioned under 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.54.00.

  • Stop apigee-monit: If apigee-monit is running on the node, stop it with /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop prior to upgrading. This prevents apigee-monit from automatically restarting components while they are being upgraded. Re-enable it with apigee-service apigee-monit start after the upgrade is complete.

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.

Upgrade Router and Message Processor

Upgrade all Routers and Message Processor nodes across data centers one by one:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Upgrade Management Server

Upgrade all Management Server nodes across data centers one by one:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Upgrade to OpenLDAP 2.6.10

Edge for Private Cloud 4.54.00 introduces OpenLDAP 2.6.10. This upgrade applies to all Apigee OpenLDAP deployment topologies: single-server, active-passive, and active-active (multi-master).

Preparation and installation (All LDAP servers)

Upgrade to New Edge UI and Apigee SSO (If Installed)

In Apigee Edge for Private Cloud 4.54.00, the Classic UI (edge-ui) is removed and replaced by the New Edge UI (edge-management-ui). Depending on whether Apigee Single Sign-On (SSO) is installed and used in your setup, follow one of the two options below:

Upgrade to Qpid 10.0.1

This method makes sure there is no downtime for your Edge runtime environment and minimizes the loss on runtime data, if any, acquired for analytics.

To perform an in-place, zero downtime upgrade to Qpid:

  1. Pick one Qpid node to start with.

  2. Stop the Qpid broker on the node:

    apigee-service apigee-qpidd stop

  3. Block incoming traffic on broker port 5672 from all message processors by applying a firewall. You can apply this firewall at the level of the Qpid node instance or some other external firewall/network component.

    We recommend that you perform the same step for all the message processor IP addresses. For example, to DROP requests coming from message processor IP addresses to the Qpid node on port 5672 using IPTables, you could use a command like this:

    iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP

  4. Start the Qpid broker again to drain existing messages, if any:

    apigee-service apigee-qpidd start

  5. Check that the existing queues are empty:

    /opt/apigee/apigee-qpidd/bin/qpid-stat -q

    If messages are stuck in the dead letter queue (DLQ) (ax-q-axgroup-001-consumer-group-001-dl), then drain the queue using the steps to resolve analytics data stuck in the dead letter queue.

  6. After verifying queues have drained on the old node, stop apigee-qpidd:

    apigee-service apigee-qpidd stop

  7. Upgrade Qpid on the node:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

  8. Restart edge-qpid-server:

    apigee-service edge-qpid-server restart

  9. Remove the firewall rule applied in Step 3.

    Perform the same removal step for all the message processor IP addresses to which the firewall was applied. Once the firewalls are removed, requests coming from message processor IP addresses to the Qpid node on port 5672 will be accepted. If you used iptables to add the firewall, to remove the firewall and to list the existing settings you can use commands like following:

    iptables -F
iptables -L

  10. Use web monitoring to verify that the Qpid queues are receiving messages:

    http://QPID_NODE_IP:8090

  11. Repeat Step 1 to 9 for each Qpid node.

Upgrade to Postgres 18.6

This release of Edge includes an upgrade to Postgres 18.6. As part of that upgrade, all Postgres data is migrated to Postgres 18.6

Most Edge production systems use two Postgres nodes configured for primary-standby replication. During the update process, while the Postgres nodes are down for update, analytics data is still written to the Qpid nodes. After the Postgres nodes are updated and back online, analytics data is then pushed to the Postgres nodes.

The way you perform the Postgres update depends on how you configured data storage for your Postgres nodes:

  • If you use local data storage for your Postgres nodes , you must install a new Postgres standby node for the duration of the upgrade. After the upgrade completes, you can decommission the new Postgres standby node. The additional Postgres standby node is required if you have to roll back the update for any reason. If you have to roll back the update, the new Postgres standby node becomes the primary Postgres node after the rollback. Therefore, when you install the new Postgres standby node, it should be on a node that meets all the hardware requirements of a Postgres server, as defined in the Edge Installation requirements.

    In a 1-node and 2-node configuration of Edge, topologies used for prototyping and testing, you only have a single Postgres node. You can update these Postgres nodes directly without having to create a new Postgres node.

  • If you use network storage for your Postgres nodes , as recommended by Apigee, you do not have to install a new Postgres node. In the procedures below, you can skip the steps that specify to install and later decommission a new Postgres standby node. Before you begin the update process, take a network snapshot of the data store used by Postgres. Then, if any errors occur during update and you are forced to perform a rollback, you can restore the Postgres node from that snapshot.

Installing a new Postgres standby node

This procedure creates a Postgres standby server on a new node. Ensure that you install a new Postgres standby server for your existing version of Edge (4.53.00 or 4.53.01), not for version 4.54.00.

To perform the install, use the same config file that you used to install your current version of Edge.

To create a new Postgres standby node:

  1. On the current Postgres primary, edit the /opt/apigee/customer/application/postgresql.properties file to set the following token. If that file does not exist, create it:

    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

    Where existing_standby_ip is the IP address of the current Postgres standby server and new_standby_ip is the IP address of the new standby node.

  2. Restart apigee-postgresql on the Postgres primary:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

  3. Verify that the new standby node was added by viewing the /opt/apigee/apigee-postgresql/conf/pg_hba.conf file on the primary. You should see the following lines in that file:

    host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust

  4. Install the new Postgres standby server:

    1. Edit the config file that you used to install your current version of Edge to specify the following:

      # IP address of the current primary(master):
PG_MASTER=PG_MASTER_NODE_IP
# IP address of the new standby node
PG_STANDBY=PG_STANDBY_NODE_IP

    2. Disable SELinux as described in Install the Edge apigee-setup utility.

    3. Download and run the bootstrap script based on your current Edge version:

      • If you are currently on Edge 4.53.00:

        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

        Install the Edge apigee-service utility and dependencies:

        bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

      • If you are currently on Edge 4.53.01:

        Download the Edge bootstrap_4.53.01.sh file to /tmp/bootstrap_4.53.01.sh:

        curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

        Install the Edge apigee-service utility and dependencies:

        bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

    4. Use apigee-service to install the apigee-setup utility:

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install

    5. Install Postgres:

      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile

    6. On the new standby node, run the following command and verify that it is the standby:

      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

Performing an in-place upgrade of Postgres

Preliminary step

Before performing an in-place upgrade to Postgres, do the following steps on both the primary host and standby, to update the max_locks_per_transaction property on apigee-postgresql:

  1. If not present, create the file /opt/apigee/customer/application/postgresql.properties .

  2. Change the ownership of this file to apigee :

    chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

  3. Add the following property to the file:

    conf/postgresql.conf+max_locks_per_transaction=30000

  4. Configure apigee-postgresql :

    apigee-service apigee-postgresql configure

  5. Restart apigee-postgresql :

    apigee-service apigee-postgresql restart

Perform the in-place upgrade

To perform an in-place upgrade to Postgres 18, do the following steps:

  1. Upgrade postgres on the primary host

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  2. Run the setup command on the primary host:

    apigee-service apigee-postgresql setup -f configFile

  3. Run the configure command on the primary host:

    apigee-service apigee-postgresql configure

  4. Restart the primary host:

    apigee-service apigee-postgresql restart

  5. Configure it as primary:

    apigee-service apigee-postgresql setup-replication-on-master -f configFile

  6. Ensure the primary host has started:

    apigee-service apigee-postgresql wait_for_ready

  7. Stop the standby:

    apigee-service apigee-postgresql stop

  8. Upgrade the standby.

    Note: If this step errors/fails, it can be ignored. update.sh will attempt to start the stand-by server with an incorrect configuration. Provided the Postgres installation is upgraded to 18, the error can be ignored.

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  9. Ensure the standby is stopped:

    apigee-service apigee-postgresql stop

  10. Remove the old standby configuration:

    rm -rf /opt/apigee/data/apigee-postgresql/

  11. Set up replication on the standby server:

    apigee-service apigee-postgresql setup-replication-on-standby -f configFile

  12. Remove the line conf/postgresql.conf+max_locks_per_transaction=30000 from the file /opt/apigee/customer/application/postgresql.properties on both the primary host and standby. This line was added in the preliminary step .

    After completing this procedure, the standby will start successfully.

Decommissioning a Postgres node

After the update completes, decommission the new standby node:

  1. Make sure Postgres is running:

    /opt/apigee/apigee-service/bin/apigee-all status

    If Postgres is not running, start it:

    /opt/apigee/apigee-service/bin/apigee-all start

  2. Get the UUID of the new standby node by running the following curl command on the new standby node:

    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    You should see the UUID of the node at the end of the output, in the form:

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

  3. Stop the new standby node by running the following command on the new standby node:

    /opt/apigee/apigee-service/bin/apigee-all stop

  4. On the Postgres primary node, edit /opt/apigee/customer/application/postgresql.properties to remove the new standby node from conf_pg_hba_replication.connection:

    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust

  5. Restart apigee-postgresql on the Postgres primary:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

  6. Verify that the new standby node was removed by viewing the /opt/apigee/apigee-postgresql/conf/pg_hba.conf file on the primary. You should see only the following line in that file:

    host replication apigee existing_standby_ip/32 trust

  7. Delete the UUID of the standby node from ZooKeeper by making the following Edge management API call on the Management Server node:

    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Post-upgrade steps for Postgres

After a major Postgres upgrade, the internal statistics of Postgres are wiped out. These statistics aid the Postgres query planner in utilizing the most optimal indexes and paths to execute queries.

Postgres can gradually rebuild its statistics over time as queries are executed and when the autovacuum daemon runs. However, until the statistics are rebuilt, your queries may be slow.

To address this issue, execute ANALYZE on all tables in the database on the primary Postgres node. Alternatively, you can execute ANALYZE for a few tables at a time.

Upgrade to ZooKeeper 3.8.5

This release of Edge for Private Cloud includes an upgrade to ZooKeeper 3.8.5. As part of that upgrade, all ZooKeeper data will be migrated to ZooKeeper 3.8.5.

Before upgrading ZooKeeper, read through the ZooKeeper maintenance guide. Most Edge production systems use a cluster of ZooKeeper nodes spread across multiple data centers. Some of these nodes are configured as voters who participate in ZooKeeper leader election, and the rest are configured as observers. See About leaders, followers, voters, and observers for more details. The voter nodes elect a leader after which the voter nodes themselves become followers.

During the update process, there could be a momentary delay or write failure in ZooKeeper when the leader node is shutdown. This could affect Management operations that write into ZooKeeper, such as deployment operation of a proxy, and Apigee infrastructure changes, such as addition or removal of a message processor, etc. There should be no impact on runtime APIs of Apigee (unless these runtime APIs call management APIs) during upgrade of ZooKeeper while following the procedure below.

At a high level, the upgrade process involves taking a backup of each node. This is followed by upgrading all observers and followers and finally upgrading the leader node.

Take a backup

Take a backup of all nodes of ZooKeeper for use in case a rollback is required. Note that a rollback will restore ZooKeeper to the state when the backup was taken.

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

If you are using virtual machines and have the capability, VM snapshots or backups could also be taken for restoration or rollback (if necessary).

Identify leader, followers and observers

  1. If it is not installed on the ZooKeeper node, install nc:

    yum install nc

  2. Run the following nc command on the node, where 2181 is the ZooKeeper port:

    echo stat | nc localhost 2181

    You should see output like the following:

    Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
Clients:
 /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 3/4.3333/6
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x500000005
Mode: follower

    In the Mode line of the output for the nodes, you should see observer, leader, or follower (meaning a voter that is not the leader) depending on the node configuration.

  1. Repeat steps 1 and 2 on each ZooKeeper node.

Upgrade ZooKeeper on the observer and follower nodes

Upgrade ZooKeeper on each of the observer and follower nodes as follows:

  1. Download and run bootstrap of Edge for Private Cloud 4.54.00, as described in Update to 4.54.00 on a node with an external internet connection . The process will likely vary depending on whether the node has an external internet connection or you're performing an offline installation.

  2. Upgrade the ZooKeeper component: 

    /opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file

    Note: If these nodes have other components installed (such as Cassandra), you could upgrade them too now (like with zk,cs profile) or you could upgrade the other components later. Apigee recommends that you upgrade ZooKeeper only first and ensure your cluster is working properly before upgrading other components.

  3. Repeat above steps on each ZooKeeper observer and follower nodes.

Shutdown the leader

Once all observer and follower nodes have been upgraded, shutdown the leader. On the node identified as leader, run the command below:

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

Note that during this event, before a new leader is elected, there could be momentary delays or write failures in ZooKeeper. This could affect operations which write into ZooKeeper such as deployment action of proxies or Apigee infrastructure changes, such as addition or removal of message processors, etc.

Verify that the new leader is elected

Using the steps in the Identify leader, followers and observers section above, verify that a new leader has been elected from the followers, once the existing leader is stopped. Note that the leader could have been elected in a different data center than the current leader.

Upgrade leader

Follow the same steps as in Upgrading ZooKeeper on the observer and follower nodes above.

Once the old leader node is upgraded as well, verify the cluster health and ensure there is a leader node.

Upgrade to Cassandra 5.0.8

Apigee Edge for Private Cloud 4.54.00 includes an upgrade of Cassandra to version 5.0.8.

Upgrades and rollback

  • Upgrading from Cassandra 4.0.X to Cassandra 5.0.X is a rolling process.

  • Direct in-place rollback from Cassandra 5.0.X to 4.0.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 5.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.

Single data center

Upgrading Cassandra from 4.0.X to 5.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 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.

If adding a new data center isn't feasible but rollback capability is still desired, backups will be necessary for restoring Cassandra 4.0.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.53.00 (or) 4.53.01 offers more flexibility for rollbacks during the upgrade to Edge for Private Cloud 4.54.00.

  • Rollbacks require at least one data center running the earlier Cassandra version (4.0.X).

  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 checkpoint process

Single Rollback Checkpoint: When all components are upgraded to 4.54.00, a cassandra rollback remains possible only if at least one Cassandra data center continues to run the older version. Once the final Cassandra data center is upgraded, the upgrade to Edge for Private Cloud 4.54.00 is complete, and rollback is no longer possible.

Example

Consider a two-data-center (DC) cluster:

  1. Start state: Cassandra nodes in both DCs are on version 4.0.X. All other nodes are on Edge for Private Cloud version 4.54.00. 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. Once all Cassandra nodes in DC-2 are successfully upgraded, the Edge for Private Cloud 4.54.00 upgrade is complete.

Prerequisites for Cassandra upgrade

You should be running Cassandra 4.0.X with Edge for Private Cloud 4.53.00 (or) 4.53.01 and ensure the following:

  1. Set Java 17 as the default Java version on the server: Cassandra 5.0.X removes Java 8 support. You cannot run Cassandra 5.0.X or its nodetool utility with Java 8. Ensure that Java 17 is installed on each Cassandra node and set Java 17 as the default Java version before running the Cassandra upgrade steps so that nodetool commands execute with Java 17:

    alternatives --set java JAVA_17_PATH/bin/java

    Verify that the active default Java version is Java 17:

    java -version

  2. The entire cluster is operational and fully functional with Cassandra 4.0.X.

  3. The compaction strategy is set to LeveledCompactionStrategy (a prerequisite for the upgrade to version 4.53.00 (or) 4.53.01).

  4. Confirm that each step below was completed as part of the initial upgrade of Cassandra 4.0.X in Edge for Private Cloud of 4.53.00 (or) 4.53.01.

    • The post_upgrade command was executed on each Cassandra node during previous upgrade

    • The drop_old_tables command was executed on the entire Cassandra cluster during the previous upgrade.

If you are not sure that the post_upgrade and drop_old_tables commands were executed on Cassandra 4.0.X while using Edge for Private Cloud 4.53.00 (or) 4.53.01, you can safely re-run them before attempting the upgrade to 4.54.00.

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 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 for more information.

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 5.0.X, while the rest of the Apigee components upgraded to 4.54.00.

  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.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | 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 cleanup_old_index command on the Cassandra node:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index

  6. 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 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 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
/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 cache cache_entries cache_entries_cache_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

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

Update with Apigee mTLS

To update Apigee mTLS , do the following steps:

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.54.00 for detailed instructions.

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 in Order of machine update .

  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 .

  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:

Use a silent configuration file

You must pass a silent configuration file to the update command. While the silent configuration file is mostly similar to the one you used to install Edge for Private Cloud 4.53.00 or 4.53.01, you may need to make changes for components such as the UI and SSO, as described in Upgrade to New Edge UI and Apigee SSO (If Installed).

Update to 4.54.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: 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 .

  4. If you are installing on AWS , execute the following yum-configure-manager commands:

    yum update rh-amazon-rhui-client.noarch
yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

  5. If you are currently on Edge for Private Cloud 4.53.00 (or) 4.53.01:

    1. Download the Edge bootstrap_4.54.00.sh file to /tmp/bootstrap_4.54.00.sh :

      curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh

    2. Install the Edge 4.54.00 apigee-service utility and dependencies by executing the following command:

      bash /tmp/bootstrap_4.54.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 17 & 21 installed.

    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.

      Where:

      • component is the Edge component to update. Possible values include:

        • edge : All Edge components except New Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server

        • ldap : OpenLDAP

        • ue : New Edge UI

        • qpid : Apigee Qpid

        • ps : Apigee Postgresql

        • zk : ZooKeeper

        • cs : Cassandra

      • configFile is the same configuration file that you used to define your Edge components during the 4.53.00 (or) 4.53.01 installation.

      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 configFile

    7. Restart the New 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 restart

    8. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install.

If you later decide to roll back the update, use the procedure described in Roll back 4.54.00

Update to 4.54.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 web server for you to use, or you can use your own web server.

To update from a local 4.54.00 repo:

  1. Create a local 4.54.00 repo as described in "Create a local Apigee repository" at Install the Edge apigee-setup utility.

  2. Install apigee-service on the target nodes using one of the following methods:

    • Option 1: 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.54.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.54.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:

        bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

        Notice that you include the path to the repos directory in this command.

    • Option 2: Install apigee-service using the Nginx web server

      1. Configure the Nginx web server as described in "Install from the repo using the Nginx web server" at Install the Edge apigee-setup utility.

      2. On the remote node, download the Edge bootstrap_4.54.00.sh file to /tmp/bootstrap_4.54.00.sh:

        /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.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-service utility and dependencies:

        bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

        Where uName:pWord are the repo username and password.

  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 in the order described in Order of machine update:

    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    Where:

    • component is the Edge component to update. Possible values include:

      • edge : All Edge components except New Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server

      • ldap : OpenLDAP

      • ue : New Edge UI

      • qpid : Apigee Qpid

      • ps : Apigee Postgresql

      • zk : ZooKeeper

      • cs : Cassandra

    • configFile is the same configuration file that you used to define your Edge components during the 4.53.00 (or) 4.53.01 installation.

      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 configFile

  7. 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 restart

  8. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install.

If you later decide to roll back the update, use the procedure described in Roll back 4.54.00.

Order of machine update

The order that you update the machines in an Edge installation is important. Upgrade your components in the below sequence.

  1. Upgrade all Router and Message Processor nodes across all data centers using the -c edge option.

  2. Upgrade all Management Server nodes across all data centers using the -c edge option.

  3. Upgrade all LDAP nodes across all the data centers. If you are upgrading from Edge for Private Cloud 4.53.00, you will need to follow additional steps to special steps of LDAP upgrade

  4. Upgrade UI and Apigee SSO (if installed) across all data centers:

    1. If apigee-sso is not installed: Follow Option 1: Upgrade UI (without Apigee SSO) to upgrade to the New Edge UI.

    2. If apigee-sso is installed: Follow Option 2: Upgrade UI (with Apigee SSO) to upgrade to New Edge UI and Apigee SSO.

  5. Upgrade all Qpid and edge-qpid-server components across all the data centers by following the special steps of Qpid.

  6. Upgrade all Postgresql and edge-postgres-server components across all the data centers by following the special steps of Postgres

  7. Upgrade all Zookeeper components across all the data centers by following the special steps of Zookeeper upgrade.

  8. Upgrade all Cassandra components across all the data centers by following the special steps of Cassandra upgrade.

  9. There is no separate step to update Monetization. It is updated when you specify the -c edge option.

1-node standalone upgrade

To upgrade a 1-node standalone configuration to 4.54.00:

When upgrading from Edge for Private Cloud 4.53.00, LDAP must be upgraded first by following the Steps to upgrade from 4.53.00 to 4.54.00 before starting the upgrade of all components.

  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 for the list of Edge topologies and node numbers.

  1. Update Edge components on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  2. Update LDAP on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  3. Update the New Edge UI on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

  4. Update Edge components on machine 2:

    /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 Postgres on machine 2:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  7. Update Cassandra and ZooKeeper on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -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

5-node upgrade

Update the following components for a 5-node installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update Edge components on machine 2, 3, 1:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  2. Update LDAP on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  3. Update the New Edge UI in machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

  4. Update Edge components on machine 4, 5:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  5. Update Qpid on machine 4, 5:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

  6. Update Postgres on machine 4, 5:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  7. Update Cassandra and ZooKeeper on machine 1, 2, and 3:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -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-node clustered upgrade

Update the following components for a 9-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update Edge components on machine 4, 5, and 1 (router, message-processor & management-server) in that order:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  2. Update LDAP on machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  3. Update the New Edge UI in machine 1:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

  4. Update Edge components on machine 6, 7, 8, and 9 in that order:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  5. Update Qpid on machines 6 and 7:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

  6. Update Postgres on machine 8:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  7. Update Postgres on machine 9:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  8. Update Cassandra and ZooKeeper on machine 1, 2, and 3:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -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

13-node clustered upgrade

Update the following components for a 13-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update Edge components on machines 10, 11, 6, and 7 in that order:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  2. Update LDAP on machine 4 and 5:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  3. Update the New Edge UI in machine 6, 7:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

  4. Update Edge components on machines 12, 13, 8, and 9 in that order:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  5. Update Qpid on machines 12 and 13:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

  6. Update Postgres on machine 8:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  7. Update Postgres on machine 9:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  8. Update Cassandra and ZooKeeper on machines 1, 2, and 3:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

  9. (If you installed apigee-adminapi) Update the apigee-adminapi utility on machines 6 and 7:

    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

12-node clustered upgrade

Update the following components for a 12-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update Edge (Router & Message Processor) components:

    • On machines 2, 3 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

    • On machines 8, 9 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  2. Update Edge (Management Server) components:

    • On machine 1 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

    • On machine 7 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  3. Update LDAP:

    • Machine 1 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

    • Machine 7 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  4. Update New Edge UI components:

    • On machine 1 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

    • On machine 7 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

  5. Update Edge components:

    • Machines 4, 5, 6 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

    • Machines 10, 11, 12 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

  6. Update qpidd:

    • Machines 4, 5 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

    • Machines 10, 11 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

  7. Update Postgres:

    • Machine 6 in Data Center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

    • Machine 12 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

  8. Update Cassandra and ZooKeeper:

    • Machines 1, 2 and 3 in Data center 1:

      /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

    • On machines 7, 8, and 9 in Data Center 2:

      /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

  9. (If you installed apigee-adminapi) Update the apigee-adminapi utility:

    • Machine 1 in Data Center 1:

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

    • Machine 7 in Data Center 2:

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

For a non-standard configuration

If you have a non-standard configuration, then update Edge components in the following order:

  1. Router

  2. Message Processor

  3. Management Server

  4. LDAP

  5. UI (either classic UI or New UI)

  6. SSO (if applicable)

  7. Qpid and edge-qpid-server

  8. Postgres and edge-postgres-server

  9. ZooKeeper

  10. Cassandra

  11. apigee-adminapi