Reverter o Apigee Edge 4.53.00

Se você encontrar um erro durante uma atualização para o Edge 4.53.00, é possível reverter o componente que causou o erro e tentar a atualização novamente.

É possível reverter o Edge 4.53.00 para a seguinte versão secundária:

  • Versão 4.52.02

O downgrade de uma versão envolve o downgrade de todos os componentes que você pode ter atualizado. Além disso, é preciso considerar alguns aspectos ao reverter o Cassandra para a versão 4.52.02.

Há dois cenários em que você pode querer fazer uma reversão:

  1. Reverter para uma versão principal ou secundária anterior. Por exemplo, de 4.53.00 para 4.52.02.
  2. Reverter para uma versão de patch anterior na mesma versão. Por exemplo, de 4.53.00.01 para 4.53.00.00.

Para mais informações, consulte o processo de lançamento do Apigee Edge.

Ordem de reversão

A reversão dos componentes precisa ser feita na ordem inversa em que foram atualizados, com a exceção de que os servidores de gerenciamento precisam ser revertidos após o Cassandra.

Uma ordem geral típica de reversão para a Private Cloud 4.53.00 será semelhante a esta:

  1. Rollback Postgres, Qpid e outros componentes relacionados à análise
  2. Roteadores de reversão e processadores de mensagens
  3. Rollback Cassandra, Zookeeper
  4. Servidor de gerenciamento de reversão

Por exemplo, digamos que você tenha atualizado o cluster do Cassandra, todos os servidores de gerenciamento e alguns RMPs para a versão 4.53.00 da versão 4.52.02 e queira reverter. Nesse caso, você precisa:

  1. Reverter todos os RMPs um por um
  2. Fazer o rollback de todo o cluster do Cassandra usando backups
  3. Fazer o rollback de nós do servidor de gerenciamento do Edge um por um

Quem pode fazer uma reversão

O usuário que executa 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, você pode estar executando componentes do Edge como usuários diferentes. Por exemplo, se o roteador precisar acessar portas privilegiadas, como as abaixo de 1000, execute o roteador 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.

Componentes com código comum

Os componentes do Edge a seguir compartilham um 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 (Postgres Server)
  • 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, você precisará reverter os três.

Reversão do Cassandra

Reversão do Cassandra

Quando um upgrade importante do Cassandra é realizado em um nó específico, o Cassandra modifica o esquema dos dados armazenados nesse nó. Portanto, uma reversão direta no local não é viável.

Cenários de reversão

O Cassandra 4.0.X, disponível com o Edge para nuvem privada 4.53.00, é compatível com outros componentes da nuvem privada 4.52.02.

Consulte a tabela abaixo para ver um resumo das várias estratégias de reversão que podem ser usadas:

Cenário Estratégia de reversão
Um DC único, alguns nós do Cassandra atualizados Usar backups
Um DC único, todos os nós do Cassandra atualizados Não reverta o Cassandra. Outros componentes podem ser revertidos.
Um DC único, todos os nós (Cassandra e outros) atualizados Não reverta o Cassandra. Outros componentes podem ser revertidos.
Vários DCs, alguns nós em um DC atualizado Recriar a partir do DC atual
Vários DCs, todos os nós do Cassandra em alguns DCs atualizados Recriar a partir do DC atual
Vários nós do DC e do Cassandra do último DC sendo atualizados Tente concluir o upgrade. Se não for possível, restaure um DC usando o backup. Recrie os DCs restantes usando o DC revertido.
Vários DCs, todos os nós do Cassandra atualizados Não reverta o Cassandra. Outros componentes podem ser revertidos.
Vários DCs, todos os nós (Cassandra e outros) atualizados Não reverta o Cassandra. Outros componentes podem ser revertidos.

Considerações gerais

Ao considerar uma reversão, tenha em mente o seguinte:

  • Reversão de componentes de execução ou de gerenciamento:se você quiser reverter componentes como edge-management-server, edge-message-processor ou qualquer componente que não seja do Cassandra para a versão 4.52.02 da nuvem particular, é recomendável que você NÃO reverta o Cassandra. O Cassandra enviado com a Private Cloud 4.53.00 é compatível com todos os componentes que não são do Cassandra do Edge para nuvem privada 4.52.02. É possível reverter componentes que não são do Cassandra usando a metodologia listada aqui enquanto o Cassandra permanece na versão 4.0.13.
  • Reversão depois que todo o cluster do Cassandra for atualizado para a versão 4.0.X:se todo o cluster do Cassandra for atualizado para a versão 4.0.X como parte do upgrade para a versão 4.53.00 da nuvem privada, recomendamos que você continue com essa configuração de cluster e NÃO faça o rollback do Cassandra. Componentes como edge-management-server, edge-message-processor, edge-router etc., da versão 4.52.02 da nuvem privada são compatíveis com a versão 4.0.X do Cassandra.
  • Reversão do Cassandra durante o upgrade:se você encontrar problemas durante o upgrade do Cassandra, considere fazer uma reversão. As estratégias de reversão listadas neste artigo podem ser seguidas com base no estado em que você está durante o processo de upgrade.
  • Reversão usando backups:os backups feitos do Cassandra 4.0.X não são compatíveis com os backups do Cassandra 3.11.X. Para reverter o Cassandra usando a restauração de backup, é necessário fazer backups do Cassandra 3.11.X antes de tentar o upgrade.

Reversão do Cassandra usando a reconstrução

Pré-requisitos

  • Você está operando um cluster do Edge para nuvem particular 4.52.02 em vários data centers.
  • Você está atualizando o Cassandra da versão 3.11.X para a 4.0.X e encontrou problemas durante o upgrade.
  • Você tem pelo menos um data center totalmente funcional no cluster que ainda executa a versão mais antiga do Cassandra (Cassandra 3.11.X).

Esse procedimento depende do streaming de dados de um data center. Isso pode levar um tempo considerável, dependendo da quantidade de dados armazenados no Cassandra. Você precisa estar preparado para desviar o tráfego de execução desse data center enquanto a reversão estiver em andamento.

Etapas avançadas

  1. Selecione um data center (parcial ou totalmente atualizado) que você quer reverter. Direcione o tráfego de execução para um data center em funcionamento diferente.
  2. Identifique o nó de semente no data center e comece com um dos nós de semente.
  3. Pare, desinstale e limpe o nó do Cassandra.
  4. Instale a versão anterior do Cassandra no nó e configure conforme necessário.
  5. Remova as configurações extras que foram adicionadas anteriormente.
  6. Repita as etapas acima para todos os nós de semente no data center, um por um.
  7. Repita as etapas acima para todos os nós do Cassandra restantes no data center, um por um.
  8. Reconstruir os nós do data center funcional atual, um por um.
  9. Reinicie todos os componentes de borda* no data center que estão conectados ao Cassandra.
  10. Teste e redirecione o tráfego de volta para esse data center.
  11. Repita as etapas para cada data center, um por um.

Etapas detalhadas

  1. Escolha um data center em que todos ou alguns nós do Cassandra sejam atualizados. Desvie todo o tráfego de proxy e de gerenciamento do ambiente de execução desse data center enquanto os nós do Cassandra nesse data center estão sendo revertidos. Verifique se todos os nós do Cassandra estão no estado UN (para cima/normal) quando o comando nodetool ring é executado nos nós. Se alguns nós estiverem inativos, resolva o problema e volte a ativar esses nós 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

    É possível executar nodetool describecluster nos nós para entender o estado atual de todo o cluster. Por exemplo, a seguir, mostramos uma instância de um cluster de dois data centers em que todos os nós do DC-1 estão na versão 4 do Cassandra, enquanto todos os nós do DC-2 estão na versão 3 do 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]
  2. Identifique os nós de semente no data center:consulte a seção Como identificar nós de semente no Apêndice. Siga as etapas abaixo em um dos nós de semente:
  3. Pare, desinstale e limpe os dados do nó do Cassandra. Escolha o primeiro nó de semente na versão 4 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
  4. 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.52.02. 
    5. # 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

Definir as configurações do Cassandra

  1. Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties.
  2. 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
  3. Verifique se o arquivo é de propriedade do usuário da apigee e se ele pode ser lido: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Instale e configure o Cassandra:
    • Instale o Cassandra versão 3.11.X: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
    • Configure o Cassandra transmitindo o arquivo de configuração padrão: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
    • Verifique se o Cassandra 3.11.X está instalado e o serviço está em execução: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  5. 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
  6. Remova as configurações extras adicionadas anteriormente do arquivo /opt/apigee/customer/application/cassandra.properties.
  7. Repita as etapas 3 a 6 em todos os nós de semente do Cassandra no data center, um por um.
  8. Repita as etapas 3 a 6 em todos os nós do Cassandra restantes no data center, um por um.
  9. Refazer todos os nós no data center usando um data center com a versão mais antiga do Cassandra. Realize esta etapa um nó por vez: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
    Esse procedimento pode levar algum tempo. É possível ajustar o streamingthroughput, se necessário. Verifique o status usando: 
    /opt/apigee/apigee-cassandra/bin/nodetool netstats
  10. 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
  11. Valide e redirecione o tráfego de volta para esse data center. Execute algumas validações para o tráfego 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.
  12. Repita as etapas acima para cada data center que você quer reverter.

Reversão do Cassandra usando o backup

Pré-requisitos

  1. Você está atualizando o Cassandra da versão 3.11.X para a 4.0.X e encontrou problemas durante o upgrade.
  2. Você tem backups do nó que está sendo revertido. O backup foi feito antes da tentativa de upgrade da versão 3.11.X para a 4.0.X.

Etapas

  1. Selecione um nó que você quer reverter. Se você estiver revertendo todos os nós de um data center usando backups, comece pelos nós de semente. Consulte a seção "Como identificar nós de semente" no apêndice.

  2. Pare, 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

  3. Instale e configure o software antigo do Cassandra no nó:

    • Execute o arquivo de inicialização do Edge para nuvem 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
    • 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 da Apigee e se ele é legível:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Instale e configure o 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

    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 estão no estado "UN":

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

  4. Interrompa 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

  5. Depois que o backup for restaurado, remova as outras configurações:

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

  6. Inicie o serviço do Cassandra no nó:

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

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

  8. 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)

Você pode minimizar (ou eliminar) a perda de dados ao restaurar backups se tiver réplicas disponíveis com os dados mais recentes. Se as réplicas estiverem disponíveis, execute um reparo no nó restaurado após a restauração do backup.

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 semente. No exemplo abaixo, DC-1-IP1, DC-1-IP2, DC-2-IP1 e DC-2-IP2 são os IPs do nó de semente:

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 para uma versão principal ou secundária anterior

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

  1. Faça o download do arquivo bootstrap.sh da versão para a qual você quer reverter:

    • Para reverter para a versão 4.52.02, faça o download de bootstrap_4.52.02.sh: 
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
  2. Pare o componente para reverter:
    1. Para reverter qualquer um dos componentes com código comum no node, é 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
    2. Para reverter qualquer outro componente no nó, interrompa apenas esse componente: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. 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
  4. Desinstale o componente para reverter no nó:
    1. Para reverter qualquer um dos componentes com código comum no node, desinstale todos eles desinstalando o grupo de componentes edge-gateway, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
    2. Para reverter qualquer outro componente no nó, desinstale apenas esse componente, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Em que component é o nome do componente.

    3. Para reverter o 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 *
  5. Desinstale a versão 4.53.00 do apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Instale a versão 4.52.02 do utilitário apigee-service e as dependências dele. O exemplo a seguir instala a versão 4.52.02 do apigee-service: 
    sudo bash /tmp/bootstrap_4.52.02.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.

  7. Instale apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. 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 mais antiga.

  9. Se você estiver revertendo o Qpid, limpe o iptables: 
    sudo iptables -F
  10. Repita esse processo para cada nó que hospeda o componente que você está revertendo.

Reverter para uma versão anterior do patch

Para reverter um componente para uma versão específica do patch, faça o seguinte em cada nó que hospeda o componente:

  1. Faça o download da versão específica do componente: 
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    Em que component_version é a versão do componente e do patch a ser instalada. Exemplo:

    /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.53.00-0.0.20254 install

    Se você estiver usando o repositório on-line da Apigee, poderá determinar as versões de componentes disponíveis usando o seguinte comando: 

    yum --showduplicates list comp

    Exemplo:

    yum --showduplicates list edge-ui
  2. Use apigee-setup para instalar o componente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

    Exemplo:

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

    Ao instalar, você especifica apenas o nome do componente, não a versão.

  3. Repita esse processo para cada nó que hospeda o componente que você está revertendo.

Reverter o mTLS

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

  1. Parar a Apigee: 
    apigee-all stop
  2. Parar mTLS: 
    apigee-service apigee-mtls uninstall
  3. Reinstale o mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf