Esta página foi traduzida pela API Cloud Translation.

Reverter o Apigee Edge 4.53.01

Se você encontrar um erro durante uma atualização para o Edge 4.53.01, poderá reverter o componente que causou o erro e tentar atualizar novamente.

É possível reverter o Edge 4.53.01 para qualquer uma das seguintes versões principais:

Versão 4.53.00
Versão 4.52.02

A reversão de uma versão envolve a reversão de todos os componentes que você pode ter atualizado. Além disso, dependendo da versão inicial, talvez seja necessário considerar etapas especiais antes de reverter determinados componentes de software. A tabela a seguir lista os vários componentes de software para os quais etapas especiais podem ser necessárias durante o rollback:

Reverter para a versão	Considerações especiais para software
4.53.00	Zookeeper, Postgres, LDAP
4.52.02	Zookeeper, Cassandra, Postgres, LDAP

Este é o cenário em que talvez seja necessário fazer um rollback:

Reverta para uma versão principal ou secundária anterior. Por exemplo, de 4.53.01 para 4.53.00.

Para mais informações, consulte 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, exceto os servidores de gerenciamento, que precisam ser revertidos depois do Cassandra. Uma ordem geral típica de rollback para a nuvem privada 4.53.01 é semelhante a esta:

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

Por exemplo, digamos que você tenha feito upgrade de todo o cluster do Cassandra, de todos os servidores de gerenciamento e de alguns RMPs da versão 4.52.02 para a versão 4.53.01 e queira fazer o rollback. Nesse caso, você:

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

Quem pode fazer um rollback

O usuário que realiza um rollback precisa ser o mesmo que atualizou o Edge originalmente ou um usuário executando como raiz.

Por padrão, os componentes do Edge são executados como o usuário "apigee". Em alguns casos, talvez você esteja executando componentes do Edge como usuários diferentes. Por exemplo, se o roteador precisar acessar portas privilegiadas, como aquelas 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 (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, é preciso reverter os três.

Reversão do Cassandra

Quando um upgrade principal do Cassandra é realizado em um nó específico, o Cassandra modifica o esquema dos dados armazenados nesse nó. Por isso, 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.01, é compatível com outros componentes da nuvem privada 4.52.02.

Consulte a tabela abaixo para um resumo das várias estratégias de rollback que você pode usar:

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

Considerações gerais

Ao considerar um rollback, lembre-se do seguinte:

Reversão de componentes de gerenciamento ou de ambiente de execução: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 do Private Cloud, é recomendável NÃO reverter o Cassandra. O Cassandra enviado com a nuvem privada 4.53.00 é compatível com todos os componentes não Cassandra do Edge para nuvem privada 4.52.02. É possível fazer o rollback de 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 após o upgrade de todo o cluster do Cassandra 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 do Private Cloud, é recomendável continuar com essa configuração de cluster e NÃO reverter o 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 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 fazer o rollback do Cassandra usando a restauração de backup, é necessário fazer backups do Cassandra 3.11.X antes de tentar o upgrade.

Fazer o rollback do Cassandra usando a recriação

Pré-requisitos

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

Esse procedimento depende do streaming de dados de um data center atual. Isso pode levar muito tempo, dependendo da quantidade de dados armazenados no Cassandra. Prepare-se para desviar o tráfego de tempo 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. Desvie o tráfego de tempo 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.
Pare, desinstale e limpe o nó do Cassandra.
Instale a versão mais antiga do Cassandra no nó e configure conforme necessário.
Remova as configurações extras adicionadas anteriormente.
Repita as etapas acima para todos os nós de semente no data center, um por um.
Repita as etapas acima para todos os nós restantes do Cassandra no data center, um por um.
Reconstrua os nós do data center funcional atual, um por um.
Reinicie todos os componentes edge-* no data center 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 de ambiente de execução e de gerenciamento desse data center enquanto os nós do Cassandra nele são revertidos. Verifique se todos os nós do Cassandra estão no estado UN (Ativo/Normal) quando o comando nodetool ring é executado neles. Se alguns nós estiverem inativos, resolva o problema e coloque esses nós de volta no ar 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, 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:
    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]

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 seed:

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

Instale o software Cassandra mais antigo no nó e defina algumas configurações. Execute o arquivo de bootstrap do Edge para nuvem 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

Definir configurações do Cassandra

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 e pode ser lido pelo usuário do Apigee:

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

Instale e configure o Cassandra:

Instale a versão 3.11.X do Cassandra:

/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 se 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

Verifique se o nó foi iniciado. Verifique o seguinte comando 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 de 3 a 6 em todos os nós de seed do Cassandra no data center, um por um.
Repita as etapas 3 a 6 em todos os nós restantes do Cassandra no data center, um por um.
Recrie todos os nós no data center de um data center que executa a versão mais antiga do Cassandra. Faça 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. É possível ajustar o streamingthroughput, se necessário. Verifique o status usando:
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```

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 tráfego de tempo de execução e 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.

Fazer o rollback do Cassandra usando o backup

Pré-requisitos

Você está fazendo upgrade do Cassandra da versão 3.11.X para a 4.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 3.11.X para a 4.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 pelos nós de seed. Consulte a seção "Como identificar nós de semente" no Apêndice.

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

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

Execute o arquivo de bootstrap 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 apigee e pode ser lido:

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 seguinte comando 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

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

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)

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, depois de restaurar o backup, execute um reparo no nó 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 semente. 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 a atualização do Zookeeper 3.8.4

Reversão

Caso seja necessário fazer uma reversão:

Execute as etapas de rollback primeiro nos observadores e seguidores.
Baixe e execute o bootstrap da versão para a qual você está revertendo: 4.52.02 ou 4.53.00. O processo provavelmente vai variar dependendo se o nó tem uma conexão de Internet externa ou se você está seguindo uma 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 como de costume:

  /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 confira se há um nó líder no cluster.

Restaurar backup

Consulte Restaurar de um backup. Os backups do Zookeeper feitos em versões anteriores do Edge para nuvem privada, como 4.52.02 ou 4.53.00, precisam ser compatíveis com a versão do Zookeeper no Edge para nuvem privada 4.53.01.

Reverter a atualização do Postgres 17

Se você fez upgrade para a versão 4.53.01 da 4.52.02 ou 4.53.00, reverta a atualização do Postgres e dos componentes do Edge.

Para fazer o rollback da atualização do Postgres ao atualizar o Postgres em uma configuração principal-standby:

Promova o novo nó de espera para que ele se torne o mestre do Postgres. O novo mestre do Postgres será a mesma versão da sua instalação anterior do Edge.
Configure o nó de espera antigo para ser um nó de 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 principais e em espera com os grupos de análise e de consumidores.

Quando a reversão for concluída, o nó principal antigo não será mais necessário. Em seguida, desative o nó principal antigo.

Verifique se o novo nó do Postgres em espera 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
```

Confira se o Postgres está parado no nó mestre antigo e no nó de espera antigo:

/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 o mestre do Postgres:
1. Promova o novo nó de espera para ser o novo mestre:
```
apigee-service apigee-postgresql promote-standby-to-master new_standby_IP
```
  Se solicitado, insira 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 e especifique 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 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. Pare 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
```
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 a que você está revertendo) no nó de espera antigo. As etapas exatas podem variar dependendo se você está usando a Internet ou uma instalação off-line. Executar a versão mais antiga do bootstrap da Apigee configura os repositórios yum com dados da Apigee de uma versão mais antiga.
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
```

Recrie o nó em espera antigo:

Edite o arquivo de configuração usado para instalar a versão atual do Edge e especifique 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ó standby 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ó de espera foi adicionado visualizando o arquivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf no novo master.

Para conferir as análises e informações atuais do grupo de consumidores, execute 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 principal e secundário antigos do Postgres nos campos postgres-server e datastores. Você vai 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 receber o endereço UUID do mestre antigo, execute o seguinte comando curl no nó mestre antigo:
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
Você vai ver o UUID do nó 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 PostgreSQL.
Repita a etapa anterior para receber os endereços IP do nó de espera antigo e do novo master.
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 grupo de consumidores. Talvez seja necessário especificá-los como standbyUUID,masterUUID.

A propriedade datastores de consumer-groups agora precisa 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 vai estar vazia.

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

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

Verifique o status da replicação executando os seguintes scripts nos dois servidores. O sistema precisa mostrar 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:
```
/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 mestre do Postgres usando o procedimento em Desativação de um nó do Postgres.
Observação: se o nó principal antigo estava executando o Qpid, você pode deixar esse servidor em execução para executar o Qpid. Verifique se ele está em execução. Caso contrário, inicie o processo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-server start
```
Como alternativa, desinstale o Qpid do mestre antigo e instale-o no novo nó mestre. Depois de desinstalar o Qpid, é possível desativar o antigo nó principal.

Reverter a atualização do LDAP 2.6

Esta seção oferece um guia completo e detalhado para reverter uma instalação do LDAP para uma versão anterior. O rollback precisa ser realizado em todo o cluster LDAP e só é possível usando um backup LDAP válido de pré-upgrade.

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

Pré-requisitos e considerações

Incompatibilidade de backup:use um backup da versão 2.4 mais antiga do LDAP que você estava executando com o Edge para nuvem privada 4.52.02 ou 4.53.00. Esse backup precisa ter sido feito antes da tentativa de upgrade. Os backups feitos após o upgrade são incompatíveis e não podem ser usados.
Tempo de inatividade da API Management:durante o rollback do LDAP, as APIs Management vão ficar indisponíveis, o que pode afetar as tarefas administrativas. Desative todos os servidores de gerenciamento de borda e a interface de borda antes de continuar com o rollback do LDAP.
Risco de perda de dados:continuar sem um backup válido e compatível pode causar perda de dados irreversível.
Backup válido:é necessário ter um backup LDAP válido antes do upgrade.

Procedimento de reversão

Desative todos os servidores de gerenciamento de borda e a interface de borda antes de continuar com o upgrade do LDAP.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```

Fazer backup dos dados do LDAP (antes de interromper o LDAP)

Receba a contagem total de registros para referência de todos os servidores LDAP. A contagem de registros precisa ser igual 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
Interrompa o serviço apigee-openldap e exclua os diretórios de configuração e dados dele. Isso precisa ser feito 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/*
```

Instalar a versão antiga do LDAP 2.4

Instalar a versão antiga do LDAP:

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

Validar versão do LDAP:

source ~/.bash_profile
ldapsearch -VV

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

Repita as etapas acima em cada nó do LDAP, um de cada vez

Limpar 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 do LDAP

Para uma configuração de servidor único, vá direto para a etapa 5b. Para configuração de vários servidores, siga a etapa 5a.

Identificar o servidor LDAP ativo

Antes de restaurar os dados do LDAP, identifique o servidor ativo (provedor) executando este comando.

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.

Restaurar dados do LDAP. Verifique se a etapa 4 foi concluída em todos os servidores antes de restaurar.

No servidor LDAP único e ativo (determinado na etapa 5a), restaure o backup.

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

Iniciar os servidores LDAP restantes
Se você tiver uma configuração de vários servidores, inicie o serviço em cada um dos servidores LDAP:
```
apigee-service apigee-openldap start
```
Observação:não é necessário restaurar dados manualmente nesses servidores semelhantes. Ao iniciar, eles se conectam ao primeiro servidor (que agora contém os dados restaurados) e sincronizam automaticamente todo o diretório por replicação.
Validação final
- A última etapa é verificar 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. A contagem de registros precisa ser idêntica em todos os servidores e corresponder à contagem capturada na etapa 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
```
- Depois de confirmar que os dados estão corretos e consistentes, o rollback do LDAP será concluído. Agora você pode iniciar o edge-management-server, o edge-ui e outros componentes dependentes de acordo com o procedimento padrão de upgrade da sua organização.

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:

Faça o download do arquivo bootstrap.sh da versão para a qual você quer fazer reversão:
- Para reverter para a versão 4.52.02, baixe bootstrap_4.52.02.sh

Pare o componente para fazer o rollback:

Para fazer o rollback de qualquer um dos componentes com código comum no nó, é necessário interromper todos eles, como mostra o 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ó, pare apenas esse componente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Se você estiver fazendo o rollback da 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 fazer o rollback no nó:
1. Para fazer o rollback de qualquer um dos componentes com código comum no nó, desinstale todos eles desinstalando o grupo de componentes edge-gateway e apigee-cassandra-client, como mostra o 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 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.
3. 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.53.01 do apigee-setup:

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

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.

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 mais antiga.
Se você estiver fazendo o rollback do Qpid, limpe as iptables:
```
sudo iptables -F
```
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:

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

Reinstale o mTLS:

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