Revierte Apigee Edge 4.54.00

Si se produce un error durante una actualización a Edge 4.54.00, puedes revertir el componente que causó el error y, luego, volver a intentar la actualización.

Puedes revertir Edge 4.54.00 a cualquiera de las siguientes versiones de actualización principales:

  • Versión 4.53.00
  • Versión 4.53.01

Para obtener más información, consulta el proceso de lanzamiento de Apigee Edge.

Orden de reversión

La reversión de los componentes se debe realizar en el orden inverso al que se actualizaron. Un orden general típico de reversión para Nube privada 4.54.00 se verá de la siguiente manera:

  • Revierte Cassandra y Zookeeper.
  • Revierte Qpid, otros componentes relacionados con las estadísticas y Postgres.
  • Revertir la IU
  • Revertir LDAP
  • Revierte el servidor de administración.
  • Revierte los routers y los procesadores de mensajes.

Por ejemplo, supongamos que actualizaste todos tus routers y Message Processors, todos tus servidores de administración, LDAP y algunos nodos de la IU a la versión 4.54.00 desde la versión 4.53.00 (o) 4.53.01 y deseas revertir la actualización. En este caso, deberías hacer lo siguiente:

  • Revierte los nodos de la IU actualizados
  • Revierte los nodos de LDAP
  • Revierte los nodos del servidor de administración uno por uno
  • Revierte todos los RMP uno por uno

Quién puede realizar una reversión

El usuario que realiza la reversión debe ser el mismo que actualizó Edge originalmente o un usuario que se ejecuta como raíz.

De forma predeterminada, los componentes de Edge se ejecutan como el usuario "apigee". En algunos casos, es posible que ejecutes componentes de Edge como usuarios diferentes. Por ejemplo, si el router tiene que acceder a puertos privilegiados, como los que están por debajo de 1000, debes ejecutar el router como usuario raíz o como un usuario con acceso a esos puertos. También puedes ejecutar un componente como un usuario y otro componente como otro usuario.

Cómo revertir Cassandra

Cuando se realiza una actualización importante de Cassandra en un nodo específico, Cassandra modifica el esquema de los datos almacenados en ese nodo. Por lo tanto, no es posible realizar una reversión directa in situ.

Situaciones de reversión

En la siguiente tabla, se resumen las estrategias de reversión que puedes usar:

Situación Estrategia de reversión
DC único, algunos nodos de Cassandra actualizados Cómo usar las copias de seguridad
Varios DC, algunos nodos en un DC actualizado Rebuild from existing DC
Varios centros de datos, todos los nodos de Cassandra en algunos centros de datos se actualizaron Recompila desde un CD existente
Varios DC, nodos de Cassandra del último DC que se actualiza Intenta finalizar la actualización. Si no es posible, revierte 1 DC con la copia de seguridad. Vuelve a compilar los DC restantes a partir del DC revertido.

Consideraciones generales

Cuando consideres una reversión, ten en cuenta lo siguiente:

  • Reversión de Cassandra durante la actualización de Cassandra: Si tienes problemas durante la actualización de Cassandra, es posible que quieras considerar una reversión. Sigue las estrategias de reversión de este artículo según el estado en el que te encuentres durante el proceso de actualización.
  • Reversión con copias de seguridad: Las copias de seguridad tomadas de Cassandra 5.0.X no son compatibles con las copias de seguridad de Cassandra 4.0.X. Para revertir Cassandra con el restablecimiento de la copia de seguridad, debes realizar copias de seguridad de Cassandra 4.0.X antes de intentar la actualización.

Cómo revertir Cassandra con la recompilación

Requisitos previos

  • Estás operando un clúster de Edge para nube privada 4.53.00/4.53.01 en varios centros de datos.
  • Estás en el proceso de actualizar Cassandra de la versión 4.0.X a la 5.0.X y encontraste problemas durante la actualización.
  • Tienes al menos un centro de datos completamente funcional en el clúster que aún ejecuta la versión anterior de Cassandra (Cassandra 4.0.X).

Este procedimiento se basa en la transmisión de datos desde un centro de datos existente. Podría llevar una cantidad significativa de tiempo, según la cantidad de datos almacenados en Cassandra. Debes prepararte para desviar el tráfico del tiempo de ejecución de este centro de datos mientras se realiza la reversión.

Pasos de alto nivel

  1. Selecciona un centro de datos (actualizado de forma parcial o total) al que quieras revertir la actualización. Desvía el tráfico del entorno de ejecución a un centro de datos diferente que funcione.
  2. Identifica el nodo de origen en el centro de datos y comienza con uno de los nodos de origen.
  3. Detén, desinstala y limpia el nodo de Cassandra.
  4. Instala la versión anterior de Cassandra en el nodo y configúrala según sea necesario.
  5. Quita los parámetros de configuración adicionales que se agregaron antes.
  6. Repite los pasos anteriores para todos los nodos de origen en el centro de datos, uno por uno.
  7. Repite los pasos anteriores para todos los nodos de Cassandra restantes en el centro de datos, uno por uno.
  8. Vuelve a compilar los nodos del centro de datos funcional existente, uno por uno.
  9. Reinicia todos los componentes edge-* del centro de datos que están conectados a Cassandra.
  10. Prueba y desvía el tráfico de vuelta a este centro de datos.
  11. Repite los pasos para cada centro de datos, uno por uno.

Pasos detallados

  1. Elige un centro de datos en el que se actualicen todos o algunos nodos de Cassandra. Desvía todo el tráfico de proxy del entorno de ejecución y el tráfico de administración de este centro de datos mientras se revierten los nodos de Cassandra en este centro de datos. Asegúrate de que todos los nodos de Cassandra estén en el estado UN (Up/Normal) cuando se ejecute el comando nodetool ring en los nodos. Si algunos nodos están inactivos, soluciona el problema y vuelve a activarlos antes de continuar.

    Consulte el siguiente ejemplo:

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    Puedes ejecutar nodetool describecluster en los nodos para comprender el estado actual de todo el clúster. Por ejemplo, a continuación, se muestra una instancia de un clúster de 2 centros de datos en la que todos los nodos de DC-1 están en la versión 4 de Cassandra, mientras que todos los nodos de DC-2 están en la versión 3 de Cassandra:

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    5.0.8: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    4.0.13: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. Identifica los nodos de origen en el centro de datos: Consulta la sección Cómo identificar los nodos de origen en el Apéndice. Ejecuta los pasos que se indican a continuación en uno de los nodos de origen:
  3. Detén, desinstala y limpia los datos del nodo de Cassandra. Elige el primer nodo de origen en la versión 5 de Cassandra en este centro de datos. Detente. 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. Instala el software de Cassandra más antiguo en el nodo y establece algunos parámetros de configuración. Ejecuta el archivo de arranque de Edge para nube privada 4.53.00/4.53.01. 
    5. # Download bootstrap of 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap of 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
  5. Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties.
  6. Agrega el siguiente contenido al archivo. ipOfNode es la dirección IP del nodo que Cassandra usa para comunicarse con otros nodos de Cassandra: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Asegúrate de que el usuario de apigee sea el propietario del archivo y pueda leerlo: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Instala y configura Cassandra:
    9. # Install cassandra version 4.0.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Verifica que el nodo se haya iniciado. Verifica el siguiente comando en este nodo y en otros nodos del clúster. El nodo debe informar que se encuentra en el estado "UN" (Up/Normal): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Quita los parámetros de configuración adicionales que agregaste antes del archivo /opt/apigee/customer/application/cassandra.properties.
  11. Repite los pasos del 3 al 10 en todos los nodos de origen de Cassandra del centro de datos, uno por uno.
  12. Repite los pasos del 3 al 10 en todos los nodos de Cassandra restantes del centro de datos, uno por uno.
  13. Vuelve a compilar todos los nodos del centro de datos desde un centro de datos que ejecute la versión anterior de Cassandra. Realiza este paso en un nodo a la vez: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Este procedimiento puede tardar un tiempo. Puedes ajustar streamingthroughput si es necesario. Verifica nodetool netstats para conocer el estado de finalización de la operación.

  14. (Opcional) Ejecuta el comando de reparación en el nodo de Cassandra si los datos no se vuelven a compilar. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Reinicia todos los componentes edge-* del centro de datos, uno por uno: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. Valida y desvía el tráfico de vuelta a este centro de datos. Ejecuta algunas validaciones para el tráfico del entorno de ejecución y las APIs de administración en este centro de datos, y comienza a redireccionar el tráfico del proxy y de las APIs de administración hacia él.
  17. Repite los pasos anteriores para cada centro de datos que quieras revertir.

Revierte Cassandra con la copia de seguridad

Requisitos previos

  1. Estás en el proceso de actualizar Cassandra de la versión 4.0.X a la 5.0.X y encontraste problemas durante la actualización.
  2. Tienes copias de seguridad del nodo al que reviertes. La copia de seguridad se realizó antes de que se intentara la actualización de la versión 4.0.X a la 5.0.X.

Pasos

  1. Selecciona un nodo que quieras revertir. Si reviertes todos los nodos de un centro de datos con copias de seguridad, comienza con los nodos semilla. Consulta la sección Cómo identificar nodos de origen en el Apéndice.

  2. Detén, desinstala y limpia el nodo de Cassandra:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. Instala el software de Cassandra anterior en el nodo y configúralo:

    • Ejecuta el archivo de arranque de Edge para nube privada 4.53.00/4.53.01:
      • # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    • Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties:
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Asegúrate de que el usuario de Apigee sea el propietario del archivo y de que se pueda leer:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Instala y configura Cassandra:
      • # Install Cassandra version 4.0.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    Verifica que el nodo se haya iniciado. Verifica el siguiente comando en este nodo y en otros nodos del clúster. Los nodos deben informar que este nodo está en el estado "UN":

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Detén el servicio de Cassandra y restablece la copia de seguridad. Consulta la documentación sobre copias de seguridad y restablecimiento para obtener más detalles:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. Una vez que se restablezca la copia de seguridad, quita las configuraciones adicionales:

    Quita la configuración que agregaste antes del archivo /opt/apigee/customer/application/cassandra.properties.

  6. Inicia el servicio de Cassandra en el nodo:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. Repite los pasos en cada nodo de Cassandra que desees revertir con copias de seguridad, uno por uno.

  8. Una vez que se restablezcan todos los nodos de Cassandra, reinicia todos los componentes edge-* uno por uno:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Optimizaciones de copias de seguridad (opción avanzada)

Puedes minimizar (o eliminar) la pérdida de datos mientras restableces copias de seguridad si tienes réplicas disponibles que contengan los datos más recientes. Si hay réplicas disponibles, después de restablecer la copia de seguridad, ejecuta una reparación en el nodo que se restableció.

Apéndice

Cómo identificar los nodos de origen

En cualquier nodo de Cassandra de un centro de datos, ejecuta el siguiente comando:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

El comando generará varias líneas. Busca la última línea del resultado. Las direcciones IP que aparecen en la última línea son los nodos de origen. En el siguiente ejemplo, DC-1-IP1, DC-1-IP2, DC-2-IP1 y DC-2-IP2 son las IP de los nodos de origen:

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Cómo revertir ZooKeeper

Revertir

En caso de que se requiera una reversión, haz lo siguiente:

  1. Primero, realiza los pasos de reversión en los observadores y los seguidores. Consulta Identifica al líder, los seguidores y los observadores para seleccionar observadores y seguidores.
  2. Descarga y ejecuta el arranque de la versión a la que quieres volver, ya sea la 4.53.00 o la 4.53.01. Es probable que el proceso varíe según si el nodo tiene una conexión a Internet externa o si estás siguiendo la instalación sin conexión.
  3. Detén Zookeeper si se está ejecutando en el nodo: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. Desinstala el ZooKeeper existente: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Instala ZooKeeper como de costumbre: 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. Una vez que se hayan revertido todos los seguidores y observadores, revierte el nodo líder siguiendo los pasos del 2 al 5 en el nodo líder.
  7. Después de revertir todos los nodos, verifica el estado del clúster y asegúrate de que haya un nodo principal en él.

Restaurar copia de seguridad

Consulta Restablece una región a partir de una copia de seguridad.

Revertir Qpid

Para revertir a una versión anterior de la versión de funciones, asegúrate de descargar el archivo bootstrap.sh de la versión a la que deseas revertir. Para revertir a la versión 4.53.00/4.53.01, descarga bootstrap_4.53.00.sh.

Para revertir Qpid, sigue estos pasos en todos los hosts de Qpid:

  1. Detén el agente de Qpid existente: 
    apigee-service apigee-qpidd stop
  2. Bloquea el tráfico entrante en el puerto 5672 del agente de mensajes desde todos los Message Processors aplicando un firewall. Puedes aplicar este firewall a nivel de la instancia del nodo de Qpid o algún otro componente de red o firewall externo.

    Te recomendamos que realices el mismo paso para todas las direcciones IP del Message Processor. Por ejemplo, para DESCARTAR las solicitudes que provienen de las direcciones IP del Message Processor al nodo de Qpid en el puerto 5672 con IPTables, puedes usar un comando como este:

    iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
  3. Vuelve a iniciar el agente de Qpid para vaciar los mensajes existentes, si los hay: 
    apigee-service apigee-qpidd start
  4. Asegúrate de que las colas existentes estén vacías. Para verificarlo, accede al portal de administración de Qpid: 
    http://QPID_NODE_IP:8090
  5. Después de verificar que las colas se hayan vaciado, detén y desinstala Qpid: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall
  6. Borra el directorio de datos de Qpid: 
    rm -r APIGEE_ROOT/data/apigee-qpidd
  7. Reinstala el agente de Qpid: 
    /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
  8. Una vez que se reinstale el agente de Qpid, quita la configuración del firewall y enumera los parámetros de configuración existentes con los siguientes comandos: 
    iptables -F
iptables -L

Revierte Postgres

Para cambiar de la versión 4.54.00 a la versión 4.53.00 o 4.53.01, debes revertir la actualización de Postgres, además de los componentes de Edge.

Para revertir la actualización de Postgres cuando actualizas Postgres en una configuración de principal-en espera, haz lo siguiente:

  • Ascender el nuevo nodo en espera para que se convierta en el nodo principal de Postgres La nueva instancia principal de Postgres será la misma versión que la instalación anterior de Edge.
  • Configura el nodo en espera anterior para que sea un nodo en espera del nuevo nodo principal. El nodo de reserva anterior tendrá la misma versión que la instalación anterior de Edge.
  • Registra los nodos principal y en espera nuevos con los grupos de análisis y de consumidores.

Cuando termines con la reversión, el nodo principal anterior ya no será necesario. Luego, puedes retirar el nodo principal anterior.

Antes de comenzar

Antes de revertir Postgres 18 a 17/14, sigue estos pasos en el host en espera nuevo y en el antiguo para actualizar la propiedad max_locks_per_transaction en apigee-postgresql:

  1. Si no está presente, crea el archivo /opt/apigee/customer/application/postgresql.properties.
  2. Cambia la propiedad de este archivo a apigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Agrega la siguiente propiedad al archivo: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Configura apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. Reinicia apigee-postgresql: 
    apigee-service apigee-postgresql restart

Procedimiento de reversión detallado

  1. Asegúrate de que el nuevo nodo de Postgres en espera se esté ejecutando: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Si Postgres no se está ejecutando, inícialo:

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Asegúrate de que Postgres esté detenido en el nodo principal anterior y en el nodo en espera anterior: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Si Postgres se está ejecutando, detenlo: 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. Si está instalado, inicia Qpid en el nodo en espera anterior: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. Asciende el nuevo nodo en espera como el principal de Postgres:
    1. Ascender el nuevo nodo en espera para que sea el nuevo principal: 
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      Si se te solicita, ingresa la contraseña de Postgres para el usuario "apigee", que de forma predeterminada es "postgres".

    2. Edita el archivo de configuración que usaste para instalar la versión actual de Edge a fin de especificar lo siguiente: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. Configura la nueva instancia principal:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Si ya actualizaste el nodo en espera anterior a la versión más reciente, primero debes revertir el software de Apigee en el nodo en espera anterior. Si aún tienes la versión anterior en el nodo de reserva anterior, puedes omitir este paso y continuar con el paso 6.
    1. Detén Postgres en el nodo de espera anterior: 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Desinstala Postgres del nodo en espera anterior: 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
apigee-service edge-analytics uninstall
    3. Borra el directorio de datos de Postgres del nodo en espera anterior: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. Descarga y ejecuta el arranque de la versión anterior (para la versión de Apigee a la que reviertes) en el nodo en espera anterior. Los pasos exactos pueden variar según si usas la instalación sin conexión o basada en Internet. Si ejecutas el programa de arranque de Apigee de la versión anterior, se configurarán los repositorios de yum con datos de Apigee de la versión anterior.
    5. Configura los componentes de Postgres en el nodo de espera anterior: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Comprueba y verifica que los componentes de Postgres en el nodo en espera anterior se hayan revertido a la versión anterior: 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. Vuelve a compilar el nodo en espera anterior:
    1. Edita el archivo de configuración que usaste para instalar tu versión actual de Edge y especifica lo siguiente: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. Quita el directorio de datos en el nodo en espera anterior: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. Vuelve a configurar el nodo en espera anterior para que sea un nodo en espera del nuevo nodo principal: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Asegúrate de que Postgres se esté ejecutando en el nodo en espera anterior: 
      /opt/apigee/apigee-service/bin/apigee-all status

      Si Postgres no se está ejecutando, inícialo:

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. Verifica que se haya agregado el nodo en espera nuevo. Para ello, consulta el archivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf en la instancia principal nueva.
  8. Ejecuta el siguiente comando en el servidor de administración para ver la información actual de las estadísticas y del grupo de consumidores: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Este comando devuelve el nombre del grupo de Analytics en el campo name y el nombre del grupo de consumidores en el campo name en consumer-groups. También devuelve los UUID de los nodos principal y en espera de Postgres antiguos en el campo postgres-server y en el campo datastores. Deberías ver un resultado con el siguiente formato: 

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. Obtén la dirección UUID de la instancia principal anterior ejecutando el siguiente comando curl en el nodo principal anterior: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    Deberías ver el UUID del nodo al final del resultado, con el siguiente formato:

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. Repite el paso anterior para obtener las direcciones IP del nodo en espera anterior y del nuevo principal.
  11. Quita los nodos principales y de reserva antiguos del grupo de consumidores: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    Donde axgroup-001 y consumer-group-001 son los nombres predeterminados de los grupos de consumidores y de estadísticas. masterUUID,standbyUUID están en el mismo orden en el que aparecieron antes cuando consultaste la información actual de las estadísticas y del grupo de consumidores. Es posible que debas especificarlos como standbyUUID,masterUUID.

    La propiedad datastores de consumer-groups ahora debería estar vacía.

  12. Quita los nodos principal y de reserva anteriores del grupo de Analytics: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    La propiedad postgres-server en uuids ahora debería estar vacía.

  13. Registra los nuevos nodos principal y en espera de PG con los grupos de consumidores y de estadísticas:
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. Valida el grupo de estadísticas: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Deberías ver los UUID de los nuevos nodos principal y en espera que se enumeran en el grupo de estadísticas y el grupo de consumidores.

  15. Reinicia el servidor de administración de Edge: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. Reinicia todos los servidores de Qpid: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. Reinicia todos los servidores de Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. Verifica el estado de la replicación ejecutando las siguientes secuencias de comandos en ambos servidores. El sistema debería mostrar resultados idénticos en ambos servidores para garantizar una replicación exitosa:

    En la nueva instancia principal, ejecuta lo siguiente:

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

    Verifica que sea la instancia principal. En el nodo de reserva anterior, ejecuta el siguiente comando:

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

    Verifica que sea la copia de seguridad.

  19. Repite el paso anterior después de realizar varias solicitudes a la API para asegurarte de que los nodos estén sincronizados.
  20. Retira el servidor principal de Postgres anterior:

    Como alternativa, puedes desinstalar Qpid de la instancia principal anterior y, luego, instalar Qpid en el nodo principal nuevo. Después de desinstalar Qpid, puedes retirar el nodo principal anterior.

Revierte la IU de New Edge

Apigee Edge para nube privada 4.54.00 reemplaza la IU clásica (edge-ui) por la nueva IU de Edge (edge-management-ui). Debido a que el componente de IU cambia en la versión 4.54.00, revertir a la versión 4.53.00 o 4.53.01 requiere desinstalar edge-management-ui y reinstalar tu perfil de IU anterior:

  • IU clásica (edge-ui): Vuelve a instalar el perfil de ui.
  • Nueva IU de Edge (edge-ui y edge-management-ui): Vuelve a instalar los perfiles ui y ue en sus respectivos nodos.

Para revertir la IU en un nodo, haz lo siguiente:

  1. Detén y desinstala la nueva IU de Edge 4.54.00, y luego instala la versión anterior para revertir el cambio:
    1. Detén y desinstala la IU de New Edge 4.54.00 (edge-management-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui uninstall
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui-static uninstall
    2. Ejecuta el archivo de arranque de Apigee Edge para nube privada 4.53.00/4.53.01: 
      # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    3. Revierte apigee-setup de la versión 4.54.00 a la anterior: 
      # Uninstall apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

# Install apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  2. Restablece la configuración de la IU de la versión 4.53.00 o 4.53.01:
    • Si creaste una copia de seguridad del archivo de configuración silenciosa de tu instalación de la versión 4.53.00 o 4.53.01, usa ese archivo de copia de seguridad para el procedimiento de reversión. De lo contrario, en tu archivo de configuración silenciosa 4.54.00, restablece o quita el comentario de las propiedades de la IU 4.53.00 o 4.53.01 que se quitaron o marcaron como comentario durante la actualización. Para obtener más información, consulta la sección de actualización de la IU.
    • Si /opt/apigee/customer/application/ui.properties se borró durante la actualización, restablécelo desde el directorio de copias de seguridad: 
      cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
  3. Vuelve a instalar y configurar la versión anterior de la IU:
    • Vuelve a la IU clásica (edge-ui):
      1. Instala y configura la IU clásica (para la autenticación básica, no se requieren pasos adicionales): 
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
      2. Si el SSO está habilitado, configúralo en la IU clásica (asegúrate de que apigee-sso se esté ejecutando primero): 
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
    • Revertir a la nueva IU de Edge 4.53.00 o 4.53.01 (edge-management-ui y Shoehorn edge-ui):
      1. Asegúrate de que EDGEUI_ENABLE_UNIFIED_UI=y esté configurado en el archivo de configuración silenciosa y, luego, instala y configura los perfiles ui y ue: 
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
      2. Si el SSO está habilitado, configúralo en ambos componentes de la IU (asegúrate de que apigee-sso se esté ejecutando primero): 
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile
  4. Verifica el estado y la versión de la IU revertida:
    • Para la IU clásica (edge-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-ui version
    • Para la nueva IU de Edge (edge-management-ui): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui version

Revierte OpenLDAP

En esta sección, se proporciona una guía paso a paso para revertir Symas OpenLDAP 2.6.10 en Edge para la nube privada 4.54.00 a OpenLDAP 2.4.46 (Edge para la nube privada 4.53.00) o Symas OpenLDAP 2.6.7 (Edge para la nube privada 4.53.01). Debes realizar la reversión en todo el clúster de LDAP con una copia de seguridad de LDAP válida previa a la actualización.

El objetivo principal es revertir todo el clúster de LDAP a un estado coherente a partir de una copia de seguridad en buen estado conocida. Este procedimiento es el mismo para todas las situaciones: un solo servidor, activo/activo y activo/pasivo.

Antes de comenzar

  • Incompatibilidad de la copia de seguridad: Usa una copia de seguridad previa a la actualización de OpenLDAP 2.4.46 (Edge para nube privada 4.53.00) o Symas OpenLDAP 2.6.7 (Edge para nube privada 4.53.01) que se haya realizado con apigee-service apigee-openldap backup antes del intento de actualización. Las copias de seguridad que se realicen después de la actualización no serán compatibles y no se podrán usar.
  • Tiempo de inactividad de la API de administración: Durante la reversión de LDAP, las APIs de administración no estarán disponibles, lo que puede afectar las tareas administrativas. Cierra todas las instancias de edge-management-server y edge-ui antes de continuar con la reversión de LDAP.
  • Riesgo de pérdida de datos: Si continúas sin una copia de seguridad válida y compatible, corres el riesgo de perder datos de forma irreversible.
  • Copia de seguridad válida: Se requiere una copia de seguridad de LDAP válida previa a la actualización.
  • Copia de seguridad de los archivos silent.conf: Conserva copias de seguridad de tus archivos silent.conf de las versiones anterior y actual para evitar confusiones en la configuración durante los procedimientos de actualización y reversión.
  • Secuencia de reversión: Completa los procedimientos de reversión para Cassandra, ZooKeeper, Qpid, PostgreSQL, apigee-sso y la IU de Edge antes de revertir OpenLDAP.

Procedimiento de reversión

  1. Cierra el servidor de administración y la IU: Cierra todas las instancias de edge-management-server y edge-ui antes de continuar con la reversión de LDAP: 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. Registra el recuento actual de entradas de LDAP (antes de detener LDAP): Obtén el recuento total de registros para referencia de todos los servidores LDAP y reemplaza YOUR_PASSWORD por la contraseña actual del administrador de LDAP. (El recuento de registros debe coincidir en todos los servidores LDAP). 
    # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. Detén y desinstala el nuevo LDAP 2.6: Detén el servicio apigee-openldap y borra sus directorios de configuración y datos. Realiza este paso en todos los servidores LDAP, un nodo a la vez en el clúster, para garantizar la coherencia: 
    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. Instala la versión anterior de LDAP 2.4.46 o 2.6.7:
    • Instala la versión anterior de LDAP: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • Valida la versión de LDAP: 
      source ~/.bash_profile
ldapsearch -VV

# Expected output if rolled back to 4.53.00:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46

# Expected output if rolled back to 4.53.01:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7
    • Repite los pasos secundarios anteriores del paso 4 en cada nodo LDAP, uno por uno.
  5. Limpia los datos residuales: En todos los servidores LDAP, uno a la vez, detén el servicio recién instalado y limpia su directorio de datos para prepararte para el restablecimiento desde la copia de seguridad: 
    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. Restablece los datos de LDAP: En el caso de una configuración de un solo servidor, continúa directamente con el paso 6b. Para una configuración de varios servidores, continúa con el paso 6a.
    1. Identifica el servidor LDAP activo: Antes de restablecer los datos de LDAP, identifica el servidor activo (proveedor) ejecutando este comando: 
      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
    2. Restablece los datos de LDAP (asegúrate de que el paso 5 se complete en todos los servidores antes de restablecer):
      • En el servidor LDAP único o activo (determinado en el paso 6a), navega al directorio de copia de seguridad y restablece la copia de seguridad previa a la actualización (por ejemplo, 2025.07.28,13.59.00, u omite la marca de tiempo si la copia de seguridad previa a la actualización es la copia de seguridad más reciente en el directorio): 
        cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00

# Note: If no timestamp is provided, the latest available backup will be restored by default:
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • Inicia el servicio apigee-openldap: 
        apigee-service apigee-openldap start
  7. Inicia los servidores LDAP restantes: Si tienes una configuración de varios servidores, en cada uno de los servidores LDAP restantes, inicia el servicio: 
    apigee-service apigee-openldap start
  8. Validación final:
    • Verifica que la reversión se haya realizado correctamente y que los datos sean coherentes en todo el clúster de LDAP.
    • Ejecuta el comando de validación en todos los servidores LDAP y reemplaza YOUR_PASSWORD por tu contraseña actual del administrador de LDAP. El recuento de registros debe ser idéntico en todos los servidores y debe coincidir con el recuento que capturaste en el paso 2: 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • Después de confirmar que los datos son correctos y coherentes, inicia edge-management-server, edge-ui y cualquier otro componente dependiente según el procedimiento estándar de tu organización.

Revierte los componentes de Edge

Componentes con código común

Los siguientes componentes de Edge comparten código común. Por lo tanto, para revertir cualquiera de estos componentes en un nodo, debes revertir todos los componentes que se encuentran en ese nodo:

  • edge-management-server (servidor de administración)
  • edge-message-processor (Message Processor)
  • edge-router (router)
  • edge-postgres-server (servidor de Postgres)
  • edge-qpid-server (servidor de Qpid)

Por ejemplo, si tienes el servidor de administración, el router y el Message Processor instalados en el nodo, para revertir cualquiera de ellos, debes revertir los tres.

Para revertir a una versión principal o secundaria anterior, haz lo siguiente en cada nodo que aloja el componente:

  1. Descarga el archivo bootstrap.sh de la versión a la que deseas revertir:

    • Para revertir a la versión 4.53.00/4.53.01, descarga bootstrap_4.53.00.sh/bootstrap_4.53.01.sh
  2. Detén el componente para revertir:
    1. Para revertir cualquiera de los componentes con código común en el nodo, debes detenerlos todos, como se muestra en el siguiente ejemplo: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. Para revertir cualquier otro componente en el nodo, detén solo ese componente: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Si reviertes la Monetización, desinstálala de todos los nodos del servidor de administración y del procesador de mensajes: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Desinstala el componente para revertir el nodo:
    1. Para revertir cualquiera de los componentes con código común en el nodo, debes desinstalarlos todos desinstalando el grupo de componentes edge-gateway y apigee-cassandra-client, como se muestra en el siguiente ejemplo: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Para revertir Nginx, haz lo siguiente: 
      ### Find the apigee-nginx RPM
rpm -qa | grep -i "apigee-nginx"

### Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.30.x
    3. Para revertir cualquier otro componente del nodo, desinstala solo ese componente, como se muestra en el siguiente ejemplo: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Aquí, component es el nombre del componente.

    4. Para revertir el router de Edge, debes borrar el contenido del archivo /opt/nginx/conf.d, además de desinstalar el grupo de componentes edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Desinstala la versión 4.54.00 de apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Instala la versión 4.53.00 de la utilidad apigee-service y sus dependencias. En el siguiente ejemplo, se instala la versión 4.53.00 de apigee-service: 
    sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

    En el ejemplo anterior, uName y pWord son el nombre de usuario y la contraseña que recibiste de Apigee. Si omites pWord, se te solicitará que lo ingreses.

    Si recibes un error, asegúrate de haber descargado el archivo bootstrap.sh en el paso 1.

  7. Instala apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Instala la versión anterior del componente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Donde component es el componente que se instalará y configFile es tu archivo de configuración para la versión anterior.

  9. Si reviertes Qpid, limpia iptables: 
    sudo iptables -F
  10. Repite este proceso para cada nodo que aloje el componente al que deseas revertir la versión.

Cómo revertir la mTLS

Para revertir la actualización de mTLS, sigue estos pasos en todos los hosts:

  1. Detén Apigee: 
    apigee-all stop
  2. Detén la mTLS: 
    apigee-service apigee-mtls uninstall
  3. Reinstala mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf