Se usó la API de Cloud Translation para traducir esta página.

Cómo revertir Apigee Edge 4.53.01

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

Puedes revertir Edge 4.53.01 a cualquiera de las siguientes versiones principales:

Versión 4.53.00
Versión 4.52.02

Revertir una versión implica revertir cada componente que hayas actualizado. Además, según la versión desde la que comenzaste, es posible que debas considerar pasos especiales antes de revertir ciertos componentes de software. En la siguiente tabla, se enumeran los distintos componentes de software para los que es posible que se necesiten pasos especiales durante la reversión:

Revertir a la versión	Consideraciones especiales para el software
4.53.00	Zookeeper, Postgres, LDAP
4.52.02	Zookeeper, Cassandra, Postgres, LDAP

Esta es la situación en la que tal vez quieras revertir la versión:

Revierte a una versión principal o secundaria anterior. Por ejemplo, de la versión 4.53.01 a la 4.53.00.

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

Orden de reversión

La reversión de los componentes debe realizarse en el orden inverso al que se actualizaron, con la excepción de que los servidores de administración deben revertirse después de Cassandra. Un orden general típico de reversión para Private Cloud 4.53.01 se verá de la siguiente manera:

Revierte Qpid, otros componentes relacionados con Analytics y Postgres.
Cómo revertir routers y procesadores de mensajes
Revierte Cassandra y ZooKeeper
Servidor de administración de reversión
Revertir LDAP

Por ejemplo, supongamos que actualizaste todo el clúster de Cassandra, todos tus servidores de administración y algunos RMP a la versión 4.53.01 desde la versión 4.52.02 y deseas revertir la actualización. En este caso, harías lo siguiente:

Cómo revertir todos los RMP uno por uno
Cómo revertir todo el clúster de Cassandra con copias de seguridad
Cómo revertir los nodos del servidor de administración de Edge 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 root.

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 enrutador tiene que acceder a puertos privilegiados, como los que están por debajo de 1,000, debes ejecutar el enrutador como usuario raíz o como un usuario con acceso a esos puertos. O bien, puedes ejecutar un componente como un usuario y otro componente como otro usuario.

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 encuentren 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 instalados el servidor de administración, el router y el procesador de mensajes en el nodo, para revertir cualquiera de ellos, debes revertir los tres.

Reversión de 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 en el lugar.

Situaciones de reversión

Cassandra 4.0.X, disponible con Edge para la nube privada 4.53.01, es compatible con otros componentes de la nube privada 4.52.02.

Consulta la siguiente tabla para obtener un resumen de las distintas estrategias de reversión que puedes usar:

Situación	Estrategia de reversión
Un solo centro de datos, algunos nodos de Cassandra actualizados	Cómo usar copias de seguridad
Un solo centro de datos, todos los nodos de Cassandra actualizados	No reviertas Cassandra. Se pueden revertir otros componentes.
Un solo centro de datos, todos los nodos (Cassandra y otros) actualizados	No reviertas Cassandra. Se pueden revertir otros componentes.
Varios CD, algunos nodos en un CD actualizado	Reconstruir a partir del centro de datos existente
Varios DC, todos los nodos de Cassandra en algunos DC se actualizaron	Reconstruir a partir del centro de datos existente
Varios CD, nodos de Cassandra del último CD que se actualiza	Intenta finalizar la actualización. Si no es factible, revierte 1 DC con la copia de seguridad. Vuelve a compilar los centros de datos restantes a partir del centro de datos revertido.
Varios CD, todos los nodos de Cassandra actualizados	No reviertas Cassandra. Se pueden revertir otros componentes.
Varios CD, todos los nodos (Cassandra y otros) actualizados	No reviertas Cassandra. Se pueden revertir otros componentes.

Consideraciones generales

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

Reversión de componentes de administración o del entorno de ejecución: Si deseas revertir componentes como edge-management-server, edge-message-processor o cualquier componente que no sea de Cassandra a la versión 4.52.02 de Private Cloud, te recomendamos que NO reviertas Cassandra. La versión de Cassandra incluida en Private Cloud 4.53.00 es compatible con todos los componentes que no son de Cassandra de Edge para Private Cloud 4.52.02. Puedes revertir los componentes que no son de Cassandra con la metodología que se indica aquí, mientras que Cassandra permanece en la versión 4.0.13.
Reversión después de actualizar todo el clúster de Cassandra a la versión 4.0.X: Si todo tu clúster de Cassandra se actualizó a la versión 4.0.X como parte de la actualización a la versión 4.53.00 de Private Cloud, te recomendamos que continúes con esta configuración del clúster y NO reviertas Cassandra. Los componentes como edge-management-server, edge-message-processor, edge-router, etc., de la versión 4.52.02 de Private Cloud son compatibles con la versión 4.0.X de Cassandra.
Reversión de Cassandra durante la actualización de Cassandra: Si tienes problemas durante la actualización de Cassandra, es posible que desees considerar una reversión. Las estrategias de reversión que se indican en este artículo se pueden seguir 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 4.0.X no son compatibles con las copias de seguridad de Cassandra 3.11.X. Para revertir Cassandra con el restablecimiento de copias de seguridad, debes crear copias de seguridad de Cassandra 3.11.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 Private Cloud 4.52.02 en varios centros de datos.
Estás en el proceso de actualizar Cassandra de la versión 3.11.X a la 4.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 3.11.X).

Este procedimiento se basa en la transmisión de datos desde un centro de datos existente. Este proceso podría tardar un tiempo considerable, 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

Selecciona un centro de datos (actualizado de forma parcial o total) al que desees revertir la actualización. Desviar el tráfico del tiempo de ejecución a un centro de datos diferente que funcione.
Identifica el nodo semilla en el centro de datos y comienza con uno de los nodos semilla.
Detén, desinstala y limpia el nodo de Cassandra.
Instala la versión anterior de Cassandra en el nodo y configúrala según sea necesario.
Quita las configuraciones adicionales que se agregaron antes.
Repite los pasos anteriores para todos los nodos semilla del centro de datos, uno por uno.
Repite los pasos anteriores para todos los nodos de Cassandra restantes en el centro de datos, uno por uno.
Reconstruye los nodos del centro de datos existente que funciona, uno por uno.
Reinicia todos los componentes edge-* del centro de datos que estén conectados a Cassandra.
Prueba y desvía el tráfico de vuelta a este centro de datos.
Repite los pasos para cada centro de datos, uno por uno.

Pasos detallados

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 estado UN (Up/Normal) cuando se ejecute el comando nodetool ring en los nodos. Si algunos nodos no funcionan, soluciona el problema y vuelve a ponerlos en funcionamiento 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:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [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]

Identifica los nodos semilla en el centro de datos: Consulta la sección Cómo identificar los nodos semilla en el Apéndice. Ejecuta los siguientes pasos en uno de los nodos semilla:

Detiene, desinstala y limpia los datos del nodo de Cassandra. Elige el primer nodo semilla en la versión 4 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

Instala el software de Cassandra anterior en el nodo y establece algunos parámetros de configuración. Ejecuta el archivo de arranque de Edge para la nube privada 4.52.02.

# Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

Establece la configuración de Cassandra

Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties.
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
```
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
```

Instala y configura Cassandra:

Instala la versión 3.11.X de Cassandra:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

Para configurar Cassandra, pasa el archivo de configuración estándar:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

Asegúrate de que Cassandra 3.11.X esté instalado y de que el servicio esté en ejecución:

/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. El nodo debe informar que se encuentra en el estado "UN" (Up/Normal):
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Quita las configuraciones adicionales que agregaste antes del archivo /opt/apigee/customer/application/cassandra.properties.
Repite los pasos del 3 al 6 en todos los nodos semilla de Cassandra del centro de datos, uno por uno.
Repite los pasos del 3 al 6 en todos los nodos de Cassandra restantes del centro de datos, uno por uno.
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 poco. Puedes ajustar el streamingthroughput si es necesario. Verifica el estado con el siguiente comando:
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```

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

Valida el tráfico y desvíalo de nuevo 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 a él.
Repite los pasos anteriores para cada centro de datos al que desees revertir la versión.

Cómo revertir Cassandra con una copia de seguridad

Requisitos previos

Estás en el proceso de actualizar Cassandra de la versión 3.11.X a la 4.0.X y encontraste problemas durante la actualización.
Tienes copias de seguridad del nodo al que reviertes. Se realizó la copia de seguridad antes de intentar la actualización de la versión 3.11.X a la 4.0.X.

Pasos

Selecciona un nodo al 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 semilla" en el Apéndice.

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

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

Ejecuta el archivo de arranque para Edge para la nube privada 4.52.02:

# Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.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 archivo sea propiedad del usuario de Apigee y de que se pueda leer:

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

Instala y configura Cassandra:

# Install Cassandra version 3.11.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

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

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.

Inicia el servicio de Cassandra en el nodo:

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

Repite los pasos en cada nodo de Cassandra en el que desees revertir los cambios con copias de seguridad, uno a la vez.

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 cuando 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 nodos semilla

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 se indican en la última línea son los nodos semilla. En el siguiente ejemplo, DC-1-IP1, DC-1-IP2, DC-2-IP1 y DC-2-IP2 son las IPs de los nodos semilla:

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 la actualización de Zookeeper 3.8.4

Revertir

En caso de que se requiera una reversión, sigue estos pasos:

Primero, realiza los pasos de reversión en los observadores y seguidores.
Descarga y ejecuta el bootstrap de la versión a la que revertirás (4.52.02 o 4.53.00). Es probable que el proceso varíe según si el nodo tiene una conexión a Internet externa o si sigues la instalación sin conexión.

Detén Zookeeper si se está ejecutando en el nodo:

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

Desinstala el zookeeper existente:

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall

Instala Zookeeper como de costumbre:

  /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>

Una vez que se reviertan todos los nodos de seguidores y observadores, revierte el nodo principal siguiendo los pasos del 2 al 5 en el nodo principal.
Después de que se reviertan todos los nodos, verifica el estado del clúster y asegúrate de que haya un nodo líder en él.

Restaurar copia de seguridad

Consulta Cómo restablecer una copia de seguridad. Ten en cuenta que las copias de seguridad de ZooKeeper tomadas de versiones anteriores de Edge para la nube privada, como la 4.52.02 o la 4.53.00, deben ser compatibles con la versión de ZooKeeper en Edge para la nube privada 4.53.01.

Revierte la actualización de Postgres 17

Si actualizaste a la versión 4.53.01 desde la versión 4.52.02 o 4.53.00, debes revertir la actualización de Postgres, además de los componentes de Edge.

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

Promociona el nuevo nodo en espera para que se convierta en el nodo principal de Postgres. El nuevo servidor principal de Postgres tendrá 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 en los grupos de análisis y de consumidores.

Cuando termines la reversión, ya no será necesario el nodo principal anterior. Luego, puedes dar de baja el nodo principal anterior.

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
```

Asegúrate de que Postgres esté detenido en el nodo principal anterior y en el nodo de reserva anterior:

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

Si Postgres se está ejecutando, deténlo:

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop

Si está instalado, inicia Qpid en el nodo de reserva anterior:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
Nota: En muchas configuraciones, el nodo de reserva anterior solo alojará Postgres, pero no Qpid.
Promueve el nuevo nodo en espera como el principal de Postgres:
1. Promociona el nuevo nodo en espera para que sea el nuevo principal:
```
apigee-service apigee-postgresql promote-standby-to-master new_standby_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 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
```
3. Configura el nuevo elemento principal:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
```
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
```
3. Borra el directorio de datos de Postgres del nodo de reserva 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 de reserva anterior. Los pasos exactos pueden variar según si usas la instalación en línea o sin conexión. 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 reserva anterior:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Comprueba y verifica que los componentes de Postgres en el nodo de reserva anterior se hayan revertido a la versión anterior:
```
apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
```
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 de reserva 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
```
Verifica que se haya agregado el nuevo nodo en espera. Para ello, consulta el archivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf en el nuevo nodo principal.

Ejecuta el siguiente comando en el servidor de administración para ver la información actual de Analytics 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 análisis 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 anteriores en el campo postgres-server y en el campo datastores. Deberías ver un resultado como el siguiente:

{
  "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" : {
  }
}

Ejecuta el siguiente comando curl en el nodo principal anterior para obtener la dirección UUID del 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, de la siguiente manera:
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Nota: El servicio edge-postgres-server debe estar en ejecución. Si el servidor de Postgres no se está ejecutando, puedes ejecutar el siguiente comando en el servidor de administración para determinar el UUID:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
El resultado de este comando enumera el UUID de la dirección IP de cada nodo de PostgreSQL.
Repite el paso anterior para obtener las direcciones IP del nodo en espera anterior y del nuevo nodo principal.
Quita los nodos principales y en espera 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 análisis y de consumidores. masterUUID,standbyUUID están en el mismo orden en que aparecieron arriba cuando viste la información actual de Analytics 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.

Quita los nodos principal y en espera 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.

Registra los nodos principal y en espera nuevos de PG con los grupos de análisis y de consumidores:

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

Valida el grupo de análisis:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
Deberías ver los UUID de los nodos principal y de reserva nuevos en el grupo de Analytics y en el grupo de consumidores.

Reinicia el servidor de administración de Edge:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart

Reinicia todos los servidores de Qpid:

/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart

Reinicia todos los servidores de Postgres:

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Verifica el estado de la replicación con los siguientes comandos en ambos servidores. El sistema debería mostrar resultados idénticos en ambos servidores para garantizar una replicación exitosa:
En el nuevo elemento principal, ejecuta lo siguiente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Verifica que sea el dispositivo principal. En el nodo de reserva anterior, haz lo siguiente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Verifica que sea el servidor en espera.
Repite el paso anterior después de realizar varias solicitudes a la API para asegurarte de que los nodos estén sincronizados.
Inhabilita la instancia principal anterior de Postgres con el procedimiento que se describe en Cómo inhabilitar un nodo de Postgres.
Nota: Si el nodo principal anterior ejecutaba Qpid, puedes dejar ese servidor en funcionamiento para ejecutar Qpid. Asegúrate de que se esté ejecutando. De lo contrario, inícialo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-server start
```
Como alternativa, puedes desinstalar Qpid del nodo principal anterior y, luego, instalarlo en el nuevo nodo principal. Después de desinstalar Qpid, puedes dar de baja el nodo principal anterior.

Cómo revertir la actualización de LDAP 2.6

En esta sección, se proporciona una guía integral paso a paso para revertir una instalación de LDAP a una versión anterior. La reversión se debe realizar en todo el clúster de LDAP y solo es posible con una copia de seguridad válida de LDAP 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 correcta conocida. Este procedimiento es el mismo para todas las situaciones: servidor único, activo/activo y activo/pasivo.

Requisitos previos y consideraciones

Incompatibilidad de la copia de seguridad: Usa una copia de seguridad de la versión 2.4 anterior de LDAP que ejecutabas con Edge para la nube privada 4.52.02 o 4.53.00. Esta copia de seguridad debe haberse realizado antes de que se intentara la actualización. Las copias de seguridad que se toman después de la actualización son incompatibles y no se pueden usar.
Tiempo de inactividad de la API de Management: Durante la reversión de LDAP, las APIs de Management no estarán disponibles, lo que puede afectar las tareas administrativas. Asegúrate de cerrar todos los servidores de administración perimetral y la IU perimetral 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 LDAP válida previa a la actualización.

Procedimiento de reversión

Asegúrate de apagar todos los servidores de administración perimetral y la IU perimetral antes de continuar con la actualización de LDAP.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Copia de seguridad de los datos LDAP existentes (antes de detener LDAP)
Obtén el recuento total de registros para referencia de todos los servidores 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
```
Detén y desinstala el nuevo LDAP 2.6
Detener el servicio de apigee-openldap y borrar sus directorios de configuración y datos Esto se debe realizar 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/*
```

Instala la versión anterior de LDAP 2.4

Instala la versión anterior de LDAP:

/opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf

Validar la versión de LDAP:

source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46

Repite los pasos anteriores en cada nodo LDAP, uno a la vez

Cómo limpiar los datos residuales
En todos los servidores LDAP, detén el servicio recién instalado y limpia su directorio de datos uno a la vez para prepararlo para el restablecimiento desde la copia de seguridad.
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```

Cómo restablecer datos de LDAP

En el caso de la configuración de un solo servidor, puedes continuar directamente con el paso 5b. Para la configuración de varios servidores, continúa con el paso 5a.

Identifica el servidor LDAP activo

Antes de restablecer los datos de LDAP, ejecuta este comando para identificar el servidor (proveedor) activo.

grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif

* **Note**:
* If this command returns output, the server is a passive server. 
* If it returns no output, the server is the active server.

Restablece los datos de LDAP (asegúrate de que el paso 4 se haya completado en todos los servidores antes de restablecerlos).

En el servidor LDAP único y activo (determinado en el paso 5a), restablece la copia de seguridad.

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
```

Inicia los servidores LDAP restantes
Si tienes una configuración de varios servidores, en cada uno de los servidores LDAP, inicia el servicio:
```
apigee-service apigee-openldap start
```
Nota: No es necesario que restablezcas los datos de forma manual en estos servidores de procesamiento. Cuando se inicie, se conectará al primer servidor (que ahora contiene los datos restablecidos) y sincronizará automáticamente todo el directorio a través de la replicación.
Validación final
- El paso final es verificar 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. El recuento de registros debe ser idéntico en todos los servidores y debe coincidir con el recuento que capturaste en el paso 1.
```
# 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
```
- Una vez que confirmes que los datos son correctos y coherentes, se completará la reversión de LDAP. Ahora puedes iniciar edge-management-server, edge-ui y cualquier otro componente dependiente según el procedimiento de actualización estándar de tu organización.

Cómo revertir a una versión principal o secundaria anterior

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

Descarga el archivo bootstrap.sh para la versión a la que deseas revertir:
- Para revertir a la versión 4.52.02, descarga bootstrap_4.52.02.sh

Detén el componente para revertir la versión:

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

Para revertir cualquier otro componente en el nodo, detén solo ese componente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

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
```
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 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.
3. Para revertir el router perimetral, 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 *
```

Desinstala la versión 4.53.01 de apigee-setup:

/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

Instala la versión 4.52.02 de la utilidad apigee-service y sus dependencias. En el siguiente ejemplo, se instala la versión 4.52.02 de apigee-service:
```
sudo bash /tmp/bootstrap_4.52.02.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 pedirá que lo ingreses.

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

Instala apigee-setup:

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

Instala la versión anterior del componente:
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
Aquí, component es el componente que se instalará y configFile es el archivo de configuración de la versión anterior.
Si reviertes Qpid, limpia iptables:
```
sudo iptables -F
```
Repite este proceso para cada nodo que aloje el componente al que reviertas la versión.

Cómo revertir la mTLS

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

Detén Apigee:
```
apigee-all stop
```
Detén la mTLS:
```
apigee-service apigee-mtls uninstall
```

Reinstala la mTLS:

apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf