O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Reverter a Apigee Edge 4.54.00

Se você encontrar um erro durante uma atualização para o Edge 4.54.00, reverta o componente que causou o erro e tente atualizar novamente.

É possível reverter o Edge 4.54.00 para qualquer uma das seguintes versões de lançamento principais:

Versão 4.53.00
Versão 4.53.01

Para mais informações, consulte Processo de lançamento da Apigee Edge.

Ordem de reversão

A reversão dos componentes precisa ser feita na ordem inversa da atualização. Uma ordem geral típica de rollback para a nuvem privada 4.54.00 é semelhante a esta:

Reverta o Cassandra e o Zookeeper.
Reverta o Qpid, outros componentes relacionados a análises e o Postgres.
Reverter interface
Reverter o LDAP.
Reverter o servidor de gerenciamento.
Reverta roteadores e processadores de mensagens.

Por exemplo, digamos que você tenha feito upgrade de todos os roteadores e processadores de mensagens, de todos os servidores de gerenciamento, do LDAP e de alguns nós de interface para a versão 4.54.00 da versão 4.53.00 (ou) 4.53.01 e queira reverter. Nesse caso, você:

Reverter os nós de IU atualizados
Reverter os nós do LDAP
Reverter os nós do servidor de gerenciamento um por um
Reverter todas as RMPs uma por uma

Observação:o SSO da Apigee no Apigee Edge para Private Cloud 4.54.00 não aceita rollbacks diretos ou parciais. Para reverter o SSO da Apigee, é necessário reverter todos os componentes atualizados anteriormente e restaurar apigee-sso usando o arquivo de configuração silenciosa da versão anterior.

Reinicie ou reinstale o apigee-sso:

Se você só interrompeu apigee-sso durante o upgrade, reinicie o serviço.
Se você desinstalou o apigee-sso durante o upgrade, reinstale-o usando o arquivo de configuração silenciosa da versão anterior:
- 4.53.01 Etapas de instalação
- 4.53.00 Etapas de instalação

Quem pode realizar uma reversão

O usuário que realiza uma reversão precisa ser o mesmo que atualizou o Edge originalmente ou um usuário que esteja executando como raiz.

Por padrão, os componentes do Edge são executados como o usuário "apigee". Em alguns casos, é possível que você esteja executando componentes do Edge como usuários diferentes. Por exemplo, se o roteador precisar acessar portas privilegiadas, como as abaixo de 1000, será necessário executá-lo como raiz ou como um usuário com acesso a essas portas. Ou você pode executar um componente como um usuário e outro componente como outro usuário.

Reverter o Cassandra

Quando um upgrade principal do Cassandra é realizado em um nó específico, o Cassandra modifica o esquema do repositório de dados armazenado nesse nó. Por isso, não é possível fazer uma reversão direta no local.

Cenários de reversão

A tabela a seguir resume as estratégias de reversão que você pode usar:

Cenário	Estratégia de reversão
DC único, alguns nós do Cassandra atualizados	Usar backups
Vários DCs, alguns nós em um DC atualizados	Reconstruir com base em uma DC atual
Vários DCs, todos os nós do Cassandra em alguns DCs atualizados	Reconstruir com base em uma DC atual
Vários data centers, nós do Cassandra do último data center sendo atualizados	Tente concluir o upgrade. Se não for possível, reverta 1 DC usando o backup. Recrie os DCs restantes com base no DC revertido.

Considerações gerais

Ao considerar um rollback, lembre-se do seguinte:

Reversão do Cassandra durante o upgrade do Cassandra:se você encontrar problemas durante o upgrade do Cassandra, considere uma reversão. Siga as estratégias de reversão neste artigo com base no seu estado durante o processo de upgrade.
Reversão usando backups:os backups feitos do Cassandra 5.0.X não são compatíveis com os backups do Cassandra 4.0.X. Para reverter o Cassandra usando a restauração de backup, faça backups do Cassandra 4.0.X antes de tentar o upgrade.

Reverter o Cassandra usando a recriação

Pré-requisitos

Você está operando um cluster do Edge para nuvem privada 4.53.00/4.53.01 em vários data centers.
Você está fazendo upgrade do Cassandra da versão 4.0.X para a 5.0.X e encontrou problemas durante o processo.
Você tem pelo menos um data center totalmente funcional no cluster que ainda executa a versão mais antiga do Cassandra (Cassandra 4.0.X).

Esse procedimento depende do streaming de dados de um data center atual. Isso pode levar um tempo significativo, dependendo da quantidade de dados armazenados no Cassandra. Prepare-se para desviar o tráfego de ambiente de execução desse data center enquanto a reversão estiver em andamento.

Etapas avançadas

Selecione um data center (parcial ou totalmente atualizado) que você quer reverter. Desviar o tráfego do ambiente de execução para um data center diferente em funcionamento.
Identifique o nó de seed no data center e comece com um dos nós de seed.
Interrompa, desinstale e limpe o nó do Cassandra.
Instale a versão mais antiga do Cassandra no nó e configure-o conforme necessário.
Remova as configurações extras que foram adicionadas anteriormente.
Repita as etapas acima para todos os nós de seed no data center, um por um.
Repita as etapas acima para todos os nós restantes do Cassandra no data center, um por um.
Recrie os nós do data center funcional atual, um por um.
Reinicie todos os componentes edge-* no data center que estão conectados ao Cassandra.
Teste e redirecione o tráfego de volta para esse data center.
Repita as etapas para cada data center, um por um.

Etapas detalhadas

Escolha um data center em que todos ou alguns nós do Cassandra serão atualizados. Desvie todo o tráfego de proxy do ambiente de execução e o tráfego de gerenciamento desse data center enquanto os nós do Cassandra nele estiverem sendo revertidos. Verifique se todos os nós do Cassandra estão no estado UN (Ativo/Normal) quando o comando nodetool ring é executado nos nós. Se determinados nós estiverem inativos, resolva o problema e reative-os antes de continuar.

Veja o exemplo abaixo:

/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

Execute nodetool describecluster nos nós para entender o estado atual de todo o cluster. Por exemplo, o seguinte mostra uma instância de um cluster de dois data centers em que todos os nós DC-1 estão na versão 4 do Cassandra, enquanto todos os nós DC-2 estão na versão 3:

# 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]

Identifique os nós de semente no data center:consulte a seção Como identificar nós de semente no Apêndice. Execute as etapas abaixo em um dos nós de semente:

Pare, desinstale e limpe os dados do nó do Cassandra. Escolha o primeiro nó de semente na versão 5 do Cassandra neste data center. Pare com isso.

# 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

Instale o software Cassandra mais antigo no nó e defina algumas configurações. Execute o arquivo de inicialização do Edge para nuvem privada 4.53.00/4.53.01.

# 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

Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties.
Adicione o seguinte conteúdo ao arquivo. ipOfNode é o endereço IP do nó que o Cassandra usa para se comunicar com outros nós do Cassandra:
```
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
```
Verifique se o arquivo pertence ao usuário da Apigee e se pode ser lido por ele:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
Instale e configure o Cassandra:

# 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

Verifique se o nó foi iniciado. Verifique o comando a seguir neste nó e em outros nós do cluster. O nó precisa informar que está no estado "UN" (Ativo/Normal):
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Remova as configurações extras adicionadas anteriormente do arquivo /opt/apigee/customer/application/cassandra.properties.
Repita as etapas 3 a 10 em todos os nós de semente do Cassandra no data center, um por um.
Repita as etapas de 3 a 10 em todos os nós restantes do Cassandra no data center, um por um.
Recrie todos os nós no data center usando um data center que execute a versão mais antiga do Cassandra. Siga esta etapa em um nó por vez:
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Esse procedimento pode levar algum tempo. Ajuste streamingthroughput se necessário. Verifique nodetool netstats para saber o status de conclusão da operação.
(Opcional) Execute o comando de reparo no nó do Cassandra se os dados não estiverem sendo recriados.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

Reinicie todos os componentes edge-* no data center, um por um:

/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

Valide e redirecione o tráfego de volta para esse data center. Execute algumas validações para o tráfego de ambiente de execução e as APIs de gerenciamento nesse data center e comece a redirecionar o tráfego de proxy e da API de gerenciamento de volta para ele.
Repita as etapas acima para cada data center que você quer reverter.

Reverter o Cassandra usando o backup

Pré-requisitos

Você está fazendo upgrade do Cassandra da versão 4.0.X para a 5.0.X e encontrou problemas durante o processo.
Você tem backups do nó que está revertendo. O backup foi feito antes da tentativa de upgrade da versão 4.0.X para a 5.0.X.

Etapas

Selecione um nó para fazer o rollback. Se você estiver fazendo o rollback de todos os nós em um data center usando backups, comece com os nós de seed. Consulte a seção Como identificar nós de semente no Apêndice.

Interrompa, desinstale e limpe o nó do 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

Instale o software Cassandra mais antigo no nó e configure-o:

Execute o arquivo de inicialização do Edge para nuvem 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

Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties:

conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true

Verifique se o arquivo pertence ao usuário do Apigee e se pode ser lido:

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

Instale e configure o 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

Verifique se o nó foi iniciado. Verifique o comando a seguir neste nó e em outros nós do cluster. Os nós precisam informar que esse nó está no estado "UN":

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

Pare o serviço do Cassandra e restaure o backup. Consulte a documentação de backup e restauração para mais detalhes:

# 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

Depois que o backup for restaurado, remova as configurações adicionais:

Remova a configuração adicionada anteriormente do arquivo /opt/apigee/customer/application/cassandra.properties.

Inicie o serviço do Cassandra no nó:

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

Repita as etapas em cada nó do Cassandra que você quer reverter usando backups, um por vez.

Depois que todos os nós do Cassandra forem restaurados, reinicie todos os componentes edge-* um por um:

/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

Otimizações de backup (opção avançada)

É possível minimizar (ou eliminar) a perda de dados ao restaurar backups se você tiver réplicas disponíveis que contenham os dados mais recentes. Se as réplicas estiverem disponíveis, depois de restaurar o backup, execute um reparo no nó que foi restaurado.

Apêndice

Como identificar nós de semente

Em qualquer nó do Cassandra em um data center, execute o seguinte comando:

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

O comando vai gerar várias linhas. Procure a última linha da saída. Os endereços IP listados na última linha são os nós de seed. No exemplo abaixo, DC-1-IP1, DC-1-IP2, DC-2-IP1 e DC-2-IP2 são os IPs do nó de seed:

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

Reverter o ZooKeeper

Reverter

Caso seja necessário fazer uma reversão:

Execute as etapas de rollback primeiro em observadores e seguidores. Consulte Identificar líderes, seguidores e observadores para selecionar observadores e seguidores.
Faça o download e execute o bootstrap da versão para a qual você está revertendo (4.53.00 ou 4.53.01). O processo provavelmente vai variar dependendo se o nó tem uma conexão de Internet externa ou se você está seguindo a instalação off-line.

Interrompa o Zookeeper se ele estiver em execução no nó:

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

Desinstale o ZooKeeper atual:

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

Instale o Zookeeper normalmente:

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

Depois que todos os seguidores e observadores forem revertidos, reverta o nó principal seguindo as etapas de 2 a 5 no nó principal.
Depois que todos os nós forem revertidos, verifique a integridade do cluster e se há um nó líder no cluster.

Restaurar backup

Consulte Restaurar de um backup.

Reverter o Qpid

Observação:reverta apigee-qpidd primeiro, antes de tentar reverter outros componentes do Edge (edge-qpid-server, edge-message-processor, edge-management-server).

Para reverter para uma versão de recurso anterior, faça o download do arquivo bootstrap.sh da versão para a qual você quer reverter. Para reverter para a v 4.53.00/4.53.01, faça o download de bootstrap_4.53.00.sh.

Para reverter o Qpid, siga estas etapas em todos os hosts do Qpid:

Interrompa o agente Qpid atual:
```
apigee-service apigee-qpidd stop
```
Bloqueie o tráfego de entrada na porta 5672 do agente de todos os processadores de mensagens aplicando um firewall. É possível aplicar esse firewall no nível da instância do nó do Qpid ou de algum outro componente de firewall/rede externo.
Recomendamos que você faça a mesma etapa para todos os endereços IP do processador de mensagens. Por exemplo, para descartar solicitações provenientes de endereços IP do processador de mensagens para o nó do Qpid na porta 5672 usando IPTables, use um comando como este:
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Inicie o broker Qpid novamente para esvaziar as mensagens atuais, se houver:
```
apigee-service apigee-qpidd start
```
Verifique se as filas atuais estão vazias. Para verificar, faça login no portal de gerenciamento do Qpid:
```
http://QPID_NODE_IP:8090
```
Observação:se a porta 8090 no nó QPID não estiver acessível, use mecanismos alternativos, como o encaminhamento de porta SSH, para acessar esse URL.

Depois de verificar se as filas foram esvaziadas, interrompa e desinstale o Qpid:

/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall

Exclua o diretório de dados do Qpid:
```
rm -r APIGEE_ROOT/data/apigee-qpidd
```

Reinstale o agente do Qpid:

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

Depois que o broker Qpid for reinstalado, remova as configurações de firewall e liste as configurações atuais usando os seguintes comandos:
```
iptables -F
iptables -L
```

Reverter o Postgres

Para fazer downgrade da versão 4.54.00 para a 4.53.00/4.53.01, reverta a atualização do Postgres e dos componentes do Edge.

Para reverter a atualização do Postgres ao atualizar o Postgres em uma configuração principal-em espera:

Promova o novo nó de espera para se tornar o mestre do Postgres. O novo mestre do Postgres será da mesma versão da instalação anterior do Edge.
Configure o nó em espera antigo para ser um nó em espera do novo mestre. O nó de espera antigo será da mesma versão da instalação anterior do Edge.
Registre os novos nós mestre e em espera com os grupos de análise e de consumidores.

Quando você terminar a reversão, o nó mestre antigo não será mais necessário. Em seguida, desative o nó mestre antigo.

Antes de começar

Antes de fazer um rollback do Postgres 18 para o 17/14, siga estas etapas no novo e no antigo host de espera para atualizar a propriedade max_locks_per_transaction em apigee-postgresql:

Se não estiver presente, crie o arquivo /opt/apigee/customer/application/postgresql.properties.

Mude a propriedade deste arquivo para apigee:

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

Adicione a seguinte propriedade ao arquivo:

conf/postgresql.conf+max_locks_per_transaction=30000

Configure o apigee-postgresql:

apigee-service apigee-postgresql configure

Reinicie o apigee-postgresql:

apigee-service apigee-postgresql restart

Procedimento detalhado de reversão

Verifique se o novo nó de espera do Postgres está em execução:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Se o Postgres não estiver em execução, inicie-o:
```
/opt/apigee/apigee-service/bin/apigee-all start
```

Confirme se o Postgres foi interrompido no nó mestre e no nó de espera antigos:

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

Se o Postgres estiver em execução, interrompa-o:

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

Se instalado, inicie o Qpid no nó de espera antigo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
Observação: em muitas configurações, o nó de espera antigo hospeda apenas o Postgres, não o Qpid.
Promova o novo nó de espera como mestre do Postgres:
1. Promova o novo nó de espera para ser o novo mestre:
```
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
```
  Se solicitado, digite a senha do Postgres para o usuário "apigee", que é "postgres" por padrão.
2. Edite o arquivo de configuração usado para instalar a versão atual do Edge para especificar o seguinte:
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
3. Configure o novo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
```
Se você já fez upgrade do nó de espera antigo para a versão mais recente, primeiro faça o downgrade do software da Apigee no nó de espera antigo. Se você ainda tiver a versão mais antiga no nó de espera antigo, pule esta etapa e continue com a etapa 6.
1. Interrompa o Postgres no nó de espera antigo:
```
apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
```
2. Desinstale o Postgres do nó de espera antigo:
```
apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
apigee-service edge-analytics uninstall
```
3. Exclua o diretório de dados do Postgres do nó de espera antigo:
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
4. Faça o download e execute o bootstrap da versão mais antiga (para a versão da Apigee que você está revertendo) no nó de espera antigo. As etapas exatas podem variar dependendo se você está usando a instalação on-line ou off-line. Executar a versão mais antiga do bootstrap da Apigee configura os repositórios yum com dados da versão mais antiga da Apigee.
5. Configure os componentes do Postgres no nó de espera antigo:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Verifique se os componentes do Postgres no nó de espera antigo foram revertidos para a versão anterior:
```
apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
```

Observação: remova o RPM postgresql18-libs-18.3-1PGDG se ele ainda existir.

Recrie o nó em espera antigo:

Edite o arquivo de configuração usado para instalar a versão atual do Edge para especificar o seguinte:

# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP

Remova o diretório de dados no nó de espera antigo:

cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *

Reconfigure o nó em espera antigo para ser um nó em espera do novo mestre:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile

Verifique se o Postgres está em execução no nó de espera antigo:

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

Se o Postgres não estiver em execução, inicie-o:

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

Verifique se o novo nó em espera foi adicionado visualizando o arquivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf no novo master.

Veja as informações atuais de análise e do grupo de consumidores executando o seguinte comando no servidor de gerenciamento:

curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

Esse comando retorna o nome do grupo de análise no campo name e o nome do grupo de consumidores no campo name em consumer-groups. Ele também retorna os UUIDs dos nós mestre e de espera antigos do Postgres no campo postgres-server e no campo datastores. Você verá uma saída no 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" : {
  }
}

Para conseguir o endereço UUID do antigo master, execute o seguinte comando curl no nó do antigo master:
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
O UUID do nó vai aparecer no final da saída, no formato:
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Observação: o serviço edge-postgres-server precisa estar em execução. Se o servidor do Postgres não estiver em execução, execute o seguinte comando no servidor de gerenciamento para determinar o UUID:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
A saída desse comando lista o UUID do endereço IP de cada nó do Postgres.
Repita a etapa anterior para receber os endereços IP do nó de espera antigo e do novo mestre.
Remova os nós principais e de espera antigos do 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
```
Em que axgroup-001 e consumer-group-001 são os nomes padrão dos grupos de análise e de consumidores. masterUUID,standbyUUID estão na mesma ordem em que apareceram acima quando você visualizou as informações atuais de análise e do grupo de consumidores. Talvez seja necessário especificá-los como standbyUUID,masterUUID.

A propriedade datastores de consumer-groups agora deve estar vazia.

Remova os nós mestre e de espera antigos do grupo de análise:

curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

A propriedade postgres-server em uuids agora deve estar vazia.

Registre novos nós mestre e em espera do PG com os grupos de análise e 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

Valide o grupo de análise:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
Os UUIDs dos novos nós principais e em espera vão aparecer listados nos grupos de análise e de consumidores.

Reinicie o servidor de gerenciamento do Edge:

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

Reinicie todos os servidores Qpid:

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

Reinicie todos os servidores Postgres:

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

Verifique o status da replicação emitindo os seguintes scripts nos dois servidores. O sistema precisa exibir resultados idênticos nos dois servidores para garantir uma replicação bem-sucedida:
No novo mestre, execute:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Verifique se ele é o mestre. No nó de espera antigo, execute:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Verifique se é o standby.
Repita a etapa anterior depois de fazer várias solicitações de API para garantir que os nós estejam sincronizados.
Desative o antigo master do Postgres:
Observação:se o nó master antigo estava executando o Qpid, deixe esse servidor em execução. Verifique se ele está em execução. Caso contrário, inicie:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd start
```
Como alternativa, desinstale o Qpid do master antigo e instale-o no novo nó master. Depois de desinstalar o Qpid, é possível desativar o nó mestre antigo.

Reverter a nova interface do Edge

O Apigee Edge para nuvem privada 4.54.00 substitui a interface clássica (edge-ui) pela nova interface do Edge (edge-management-ui). Como o componente da interface muda na versão 4.54.00, a reversão para a versão 4.53.00 ou 4.53.01 exige a desinstalação do edge-management-ui e a reinstalação do seu perfil de interface anterior:

Interface clássica (edge-ui): reinstale o perfil ui.
Nova interface do Edge (edge-ui e edge-management-ui): reinstale os perfis ui e ue nos respectivos nós.

Para reverter a interface em um nó:

Pare e desinstale a interface do New Edge 4.54.00 e instale a versão anterior para fazer o rollback:

Interrompa e desinstale a nova interface da 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

Execute o arquivo de inicialização da Apigee Edge para nuvem 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

Reverta o apigee-setup da versão 4.54.00 para a 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

Restaure as configurações da interface 4.53.00/4.53.01:
- Se você fez backup do arquivo de configuração silenciosa da instalação 4.53.00 ou 4.53.01, use esse arquivo de backup para o procedimento de reversão. Caso contrário, no arquivo de configuração silenciosa 4.54.00, restaure ou remova o comentário das propriedades da interface 4.53.00 ou 4.53.01 que foram removidas ou comentadas durante o upgrade. Para referência, consulte a seção de upgrade da interface.
- Se /opt/apigee/customer/application/ui.properties foi excluído durante o upgrade, restaure-o do diretório de backup:
```
cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
```
Reinstale e configure a versão anterior da interface:
- Reverter para a UI clássica (edge-ui):
  1. Instale e configure a interface clássica (para autenticação básica, nenhuma etapa adicional é necessária):
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
```
  2. Se o SSO estiver ativado, configure-o na interface clássica (primeiro, verifique se apigee-sso está em execução):
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Reverter para a nova IU do Edge 4.53.00 ou 4.53.01 (edge-management-ui e Shoehorn edge-ui):
  1. Verifique se EDGEUI_ENABLE_UNIFIED_UI=y está definido no arquivo de configuração silenciosa. Em seguida, instale e configure os perfis ui e ue:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
```
  2. Se o SSO estiver ativado, configure-o nos dois componentes da interface (primeiro, verifique se apigee-sso está em execução):
```
/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
```
Observação:em uma topologia de vários nós em que a interface clássica e a nova interface do Edge 4.53.01 foram hospedadas em nós separados, execute os comandos de rollback nos respectivos hosts. O comando configure-sso só precisa ser executado se o SSO tiver sido configurado na versão anterior.
- Nó 1 (nó da interface clássica): execute os comandos da interface clássica:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Node 2 (novo nó da interface do Edge): execute os comandos da nova interface do Edge (setup.sh -p ue e edge-management-ui configure-sso):
```
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
/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
```

Verifique o status e a versão da interface revertida:

Para a interface clássica (edge-ui):

/opt/apigee/apigee-service/bin/apigee-service edge-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-ui version

Para a nova interface do 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

Observação:nas versões da Apigee Edge para nuvem privada anteriores à 4.54.00, a interface clássica do Edge (edge-ui) e a nova interface do Edge (edge-management-ui) não podiam coexistir no mesmo nó. Os administradores precisavam provisionar nós separados e dedicados para cada componente da interface ao executar essas versões anteriores.

Reverter o OpenLDAP

Nesta seção, apresentamos um guia explicativo para reverter o Symas OpenLDAP 2.6.10 no Edge para nuvem privada 4.54.00 para o OpenLDAP 2.4.46 (Edge para nuvem privada 4.53.00) ou o Symas OpenLDAP 2.6.7 (Edge para nuvem privada 4.53.01). É preciso realizar a reversão em todo o cluster LDAP usando um backup LDAP válido anterior ao upgrade.

O objetivo principal é reverter todo o cluster LDAP para um estado consistente de um backup conhecido. Esse procedimento é o mesmo para todos os cenários: servidor único, ativo-ativo e ativo-passivo.

Antes de começar

Incompatibilidade de backup:use um backup pré-upgrade do OpenLDAP 2.4.46 (Edge para nuvem privada 4.53.00) ou do Symas OpenLDAP 2.6.7 (Edge para nuvem privada 4.53.01) que foi feito usando apigee-service apigee-openldap backup antes da tentativa de upgrade. Os backups feitos após o upgrade são incompatíveis e não podem ser usados.
Inatividade da API Management:durante a reversão do LDAP, as APIs Management vão ficar indisponíveis, o que pode afetar as tarefas administrativas. Desative todas as instâncias de edge-management-server e edge-ui antes de continuar com o rollback do LDAP.
Observação:se você estiver usando a nova IU do Edge (edge-management-ui), interrompa a IU clássica (edge-ui) e a nova IU do Edge (edge-management-ui).
Risco de perda de dados:continuar sem um backup válido e compatível pode causar perda irreversível de dados.
Backup válido:é necessário um backup LDAP válido antes do upgrade.
Backup de arquivos silent.conf:mantenha backups dos arquivos silent.conf das versões anterior e atual para evitar confusões de configuração durante os procedimentos de upgrade e reversão.
Sequência de rollback:conclua os procedimentos de rollback para Cassandra, ZooKeeper, Qpid, PostgreSQL, apigee-sso e a interface do Edge antes de fazer o rollback do OpenLDAP.

Procedimento de reversão

Encerre o servidor de gerenciamento e a interface:encerre todas as instâncias de edge-management-server e edge-ui antes de prosseguir com a reversão do LDAP:
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Registre a contagem atual de entradas LDAP (antes de interromper o LDAP): acesse a contagem total de registros para referência de todos os servidores LDAP, substituindo YOUR_PASSWORD pela senha atual do gerenciador LDAP. A contagem de registros precisa ser a mesma em todos os 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
```
Parar e desinstalar o novo LDAP 2.6:pare o serviço apigee-openldap e exclua os diretórios de configuração e dados dele. Siga esta etapa em todos os servidores LDAP, um nó por vez no cluster, para garantir a consistência:
```
apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
```

Instale a versão anterior do LDAP 2.4.46 ou 2.6.7:

Instale a versão antiga do LDAP:

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

Validar a versão do 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

Repita as subetapas anteriores da etapa 4 em cada nó LDAP, uma de cada vez.

Limpe os dados residuais:em todos os servidores LDAP, um de cada vez, pare o serviço recém-instalado e limpe o diretório de dados dele para se preparar para a restauração do backup:
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```
Restaurar dados LDAP:para uma configuração de servidor único, prossiga diretamente para a etapa 6b. Para uma configuração de vários servidores, prossiga para a etapa 6a.
1. Identifique o servidor LDAP ativo:antes de restaurar os dados LDAP, identifique o servidor ativo (provedor) executando este comando:
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
  Observação:
  1. Se esse comando retornar uma saída, o servidor será passivo.
  2. Se esse comando não retornar nenhuma saída, o servidor é o ativo.
2. Restaure os dados do LDAP (verifique se a etapa 5 foi concluída em todos os servidores antes da restauração):
  - No servidor LDAP único ou ativo (determinado na etapa 6a), navegue até o diretório de backup e restaure o backup pré-upgrade (por exemplo, 2025.07.28,13.59.00, ou omita o carimbo de data/hora se o backup pré-upgrade for o mais recente no diretório):
```
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.
```
  - Inicie o serviço apigee-openldap:
```
apigee-service apigee-openldap start
```
Inicie os servidores LDAP restantes:se você tiver uma configuração de vários servidores, inicie o serviço em cada um dos servidores LDAP restantes:
```
apigee-service apigee-openldap start
```
Observação:não é necessário restaurar os dados manualmente nesses servidores de peering. Ao serem iniciados, eles se conectarão ao primeiro servidor (que agora contém os dados restaurados) e sincronizarão automaticamente todo o diretório por meio de replicação.
Validação final:
- Verifique se a reversão foi bem-sucedida e se os dados estão consistentes em todo o cluster LDAP.
- Execute o comando de validação em todos os servidores LDAP, substituindo YOUR_PASSWORD pela senha atual do gerenciador LDAP. A contagem de registros precisa ser idêntica em todos os servidores e corresponder à contagem capturada na etapa 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
```
- Depois de confirmar que os dados estão corretos e consistentes, inicie edge-management-server, edge-ui e outros componentes dependentes de acordo com o procedimento padrão da sua organização.

Reverter componentes do Edge

Componentes com código comum

Os seguintes componentes do Edge compartilham código comum. Portanto, para reverter qualquer um desses componentes em um nó, é necessário reverter todos os componentes que estão nesse nó:

edge-management-server (servidor de gerenciamento)
edge-message-processor (processador de mensagens)
edge-router (roteador)
edge-postgres-server (servidor Postgres)
edge-qpid-server (servidor Qpid)

Por exemplo, se você tiver o servidor de gerenciamento, o roteador e o processador de mensagens instalados no nó, para reverter qualquer um deles, será necessário reverter os três.

Para reverter para uma versão principal ou secundária anterior, faça o seguinte em cada nó que hospeda o componente:

Faça o download do arquivo bootstrap.sh da versão para a qual você quer reverter:
- Para reverter para 4.53.00/4.53.01, faça o download de bootstrap_4.53.00.sh/bootstrap_4.53.01.sh

Interrompa o componente para reverter:

Para fazer o rollback de qualquer um dos componentes com código comum no nó, é necessário interromper todos eles, conforme mostrado no exemplo a seguir:

/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 reverter qualquer outro componente no nó, interrompa apenas esse componente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Se você estiver revertendo a Monetização, desinstale-a de todos os nós do servidor de gerenciamento e do processador de mensagens:
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
Desinstale o componente para reverter no nó:
1. Para reverter qualquer um dos componentes com código comum no nó, desinstale todos eles desinstalando o grupo de componentes edge-gateway e apigee-cassandra-client, conforme mostrado no exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
```
2. Para reverter o Nginx:
```
### 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 reverter qualquer outro componente no nó, desinstale apenas esse componente, como mostra o exemplo a seguir:
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  Em que component é o nome do componente.
  Observação:se o edge-analytics não for desinstalado automaticamente com edge-qpid-server e edge-postgres-server, faça isso manualmente usando o seguinte comando:
```
/opt/apigee/apigee-service/bin/apigee-service edge-analytics uninstall
```
4. Para fazer o rollback do roteador de borda, exclua o conteúdo do arquivo /opt/nginx/conf.d e desinstale o grupo de componentes edge-gateway:
```
cd /opt/nginx/conf.d
rm -rf *
```

Desinstale a versão 4.54.00 do apigee-setup:

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

Instale a versão 4.53.00 do utilitário apigee-service e as dependências dele. O exemplo a seguir instala a versão 4.53.00 do apigee-service:
```
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
Em que uName e pWord são o nome de usuário e a senha que você recebeu da Apigee. Se você omitir pWord, será solicitado que você o insira.

Se você receber um erro, verifique se fez o download do arquivo bootstrap.sh na etapa 1.

Instale apigee-setup:

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

Instale a versão mais antiga do componente:
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
Em que component é o componente a ser instalado e configFile é o arquivo de configuração da versão anterior.
Se você estiver revertendo o Qpid, limpe as iptables:
```
sudo iptables -F
```
Repita esse processo para cada nó que hospeda o componente que você está revertendo.

Observação:ao desinstalar o apigee-cassandra-client, o apigee-provision e o apigee-validate são removidos automaticamente devido à dependência deles. Se forem necessários posteriormente, eles precisarão ser reinstalados.

Reverter mTLS

Para reverter a atualização de mTLS, siga estas etapas em todos os hosts:

Interrompa a Apigee:
```
apigee-all stop
```
Interrompa o mTLS:
```
apigee-service apigee-mtls uninstall
```

Reinstale o mTLS:

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