Откатить Apigee Edge 4.53.01

Если во время обновления до Edge 4.53.01 возникла ошибка, вы можете откатить компонент, вызвавший ошибку, а затем повторить попытку обновления.

Вы можете выполнить откат Edge 4.53.01 до любой из следующих основных версий релиза:

  • Версия 4.53.00
  • Версия 4.52.02

Откат версии подразумевает откат всех компонентов, которые вы могли обновить. Кроме того, в зависимости от версии, с которой вы начали, вам могут потребоваться специальные действия перед откатом определённых компонентов программного обеспечения. В следующей таблице перечислены различные компоненты программного обеспечения, для которых могут потребоваться специальные действия при откате:

Откат к версии Особое внимание к программному обеспечению
4.53.00 Zookeeper , Postgres , LDAP
4.52.02 Zookeeper , Cassandra , Postgres , LDAP

Вот сценарий, в котором вам может потребоваться выполнить откат:

Откат к предыдущей основной или второстепенной версии . Например, с версии 4.53.01 до 4.53.00.

Более подробную информацию см. в разделе Процесс выпуска Apigee Edge .

Порядок отката

Откат компонентов следует выполнять в порядке, обратном порядку их обновления, за исключением того, что серверы управления следует откатывать после Cassandra. Типичный порядок отката для Private Cloud 4.53.01 будет выглядеть следующим образом:

  1. Откат Qpid, других компонентов, связанных с аналитикой, и Postgres.
  2. Маршрутизаторы отката и обработчики сообщений
  3. Откат Кассандры, смотрителя зоопарка
  4. Сервер управления откатами
  5. Откат LDAP

Например, вы обновили весь кластер Cassandra, все серверы управления и несколько RMP с версии 4.52.02 до версии 4.53.01 и хотите выполнить откат. В этом случае вам нужно:

  • Откатить все RMP один за другим
  • Откат всего кластера Cassandra с использованием резервных копий
  • Откатить узлы сервера Edge Management один за другим

Кто может выполнить откат?

Пользователь, выполняющий откат, должен быть тем же пользователем, который изначально обновил Edge, или пользователем, работающим от имени root.

По умолчанию компоненты Edge запускаются от имени пользователя «apigee». В некоторых случаях компоненты Edge могут запускаться от имени разных пользователей. Например, если маршрутизатору требуется доступ к привилегированным портам, например, ниже 1000, необходимо запустить маршрутизатор от имени пользователя root или пользователя с доступом к этим портам. Или можно запустить один компонент от имени одного пользователя, а другой — от имени другого.

Компоненты с общим кодом

Следующие компоненты Edge используют общий код. Поэтому для отката любого из этих компонентов на узле необходимо откатить все компоненты, находящиеся на этом узле.

  • edge-management-server (сервер управления)
  • edge-message-processor (процессор сообщений)
  • edge-router (маршрутизатор)
  • edge-postgres-server (сервер Postgres)
  • edge-qpid-server (сервер Qpid)

Например, если на узле установлены сервер управления, маршрутизатор и процессор сообщений, то для отката любого из них необходимо выполнить откат всех трех.

Откат Кассандры

При выполнении крупного обновления Cassandra на определённом узле, Cassandra изменяет схему данных, хранящихся на этом узле. В результате прямой откат на месте невозможен.

Сценарии отката

Cassandra 4.0.X, доступная с Edge для Private Cloud 4.53.01, совместима с другими компонентами Private Cloud 4.52.02.

В таблице ниже приведен обзор различных стратегий отката, которые вы можете использовать:

Сценарий Стратегия отката
Один DC, некоторые узлы Cassandra модернизированы Используйте резервные копии
Один ЦОД, все узлы Cassandra обновлены Не откатывайте Cassandra. Остальные компоненты можно откатить.
Один ЦОД, все узлы (Кассандра и другие) обновлены Не откатывайте Cassandra. Остальные компоненты можно откатить.
Несколько ЦОД, некоторые узлы в одном ЦОД модернизированы Перестроить существующий ЦОД
Несколько ЦОД, все узлы Cassandra в некоторых ЦОД обновлены Перестроить существующий ЦОД
Несколько DC, узлы Cassandra последнего DC модернизируются Попробуйте завершить обновление. Если это невозможно, откатите один контроллер домена из резервной копии . Восстановите оставшиеся контроллеры домена с откачанного контроллера.
Несколько DC, все узлы Cassandra обновлены Не откатывайте Cassandra. Остальные компоненты можно откатить.
Несколько ЦОД, все узлы (Кассандра и другие) обновлены Не откатывайте Cassandra. Остальные компоненты можно откатить.

Общие соображения

При рассмотрении возможности отката имейте в виду следующее:

  • Откат компонентов среды выполнения или управления: если вы хотите откатить такие компоненты, как edge-management-server, edge-message-processor или любой компонент, не относящийся к Cassandra, до версии Private Cloud 4.52.02, рекомендуется НЕ откатывать Cassandra. Cassandra, поставляемая с Private Cloud 4.53.00, совместима со всеми компонентами Edge for Private Cloud 4.52.02, не относящимися к Cassandra. Вы можете откатить компоненты, не относящиеся к Cassandra, используя методологию, описанную здесь, пока Cassandra остаётся на версии 4.0.13.
  • Откат после обновления всего кластера Cassandra до версии 4.0.X: Если весь кластер Cassandra обновляется до версии 4.0.X в рамках обновления до версии Private Cloud 4.53.00, рекомендуется продолжить настройку кластера и НЕ откатывать Cassandra. Такие компоненты Private Cloud версии 4.52.02, как edge-management-server, edge-message-processor, edge-router и т. д., совместимы с Cassandra версии 4.0.X.
  • Откат Cassandra во время обновления: если у вас возникли проблемы во время обновления Cassandra, вы можете рассмотреть возможность отката. Стратегии отката, перечисленные в этой статье, можно применять в зависимости от текущего состояния процесса обновления.
  • Откат с использованием резервных копий: Резервные копии Cassandra 4.0.X несовместимы с резервными копиями Cassandra 3.11.X. Чтобы выполнить откат Cassandra с помощью восстановления из резервной копии, необходимо создать резервные копии Cassandra 3.11.X перед попыткой обновления.

Откат Cassandra с помощью пересборки

Предпосылки

  • Вы используете кластер Edge for Private Cloud 4.52.02 в нескольких центрах обработки данных.
  • Вы обновляете Cassandra с версии 3.11.X до 4.0.X и столкнулись с проблемами во время обновления.
  • У вас в кластере есть по крайней мере один полностью функциональный центр обработки данных, на котором все еще работает старая версия Cassandra (Cassandra 3.11.X).

Эта процедура основана на потоковой передаче данных из существующего центра обработки данных. Это может занять значительное время в зависимости от объёма данных, хранящихся в Cassandra. Будьте готовы перенаправить трафик среды выполнения из этого центра обработки данных во время отката.

Шаги высокого уровня

  1. Выберите один центр обработки данных (частично или полностью обновлённый), который вы хотите откатить. Перенаправьте трафик выполнения в другой работающий центр обработки данных.
  2. Определите начальный узел в центре обработки данных и начните с одного из начальных узлов.
  3. Остановите, удалите и очистите узел Cassandra.
  4. Установите на узел старую версию Cassandra и настройте ее по мере необходимости.
  5. Удалите дополнительные конфигурации, добавленные ранее.
  6. Повторите вышеуказанные шаги для всех начальных узлов в центре обработки данных, по одному.
  7. Повторите вышеуказанные шаги для всех оставшихся узлов Cassandra в центре обработки данных, по одному.
  8. По одному перестройте узлы существующего действующего центра обработки данных.
  9. Перезапустите все компоненты edge-* в центре обработки данных, подключенные к Cassandra.
  10. Проверьте и перенаправьте трафик обратно в этот центр обработки данных.
  11. Повторите шаги для каждого центра обработки данных, по одному.

Подробные шаги

  1. Выберите один центр обработки данных, в котором все или некоторые узлы Cassandra обновлены. Перенаправьте весь трафик прокси-сервера и управления из этого центра обработки данных на время отката узлов Cassandra в этом центре обработки данных. Убедитесь, что все узлы Cassandra находятся в состоянии UN (Up/Normal) при выполнении команды nodetool ring на узлах. Если некоторые узлы вышли из строя, устраните неполадку и восстановите их, прежде чем продолжить.

    Смотрите пример ниже:

    /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

    Вы можете запустить nodetool describecluster на узлах, чтобы оценить текущее состояние всего кластера. Например, ниже показан экземпляр кластера из двух центров обработки данных, где все узлы DC-1 работают на базе Cassandra версии 4, а все узлы DC-2 — на базе Cassandra версии 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]
  2. Определите начальные узлы в центре обработки данных: см. раздел «Как определить начальные узлы» в Приложении. Выполните следующие действия на одном из начальных узлов:
  3. Остановите, удалите и очистите данные с узла Cassandra. Выберите первый начальный узел Cassandra версии 4 в этом центре обработки данных. Остановите его. 
    # 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. Установите старую версию Cassandra на узел и настройте некоторые параметры. Запустите файл начальной загрузки Edge for Private Cloud 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
  5. Создайте или отредактируйте файл /opt/apigee/customer/application/cassandra.properties .
  6. Добавьте в файл следующее содержимое. ipOfNode — это IP-адрес узла, который Cassandra использует для связи с другими узлами Cassandra: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Убедитесь, что файл принадлежит пользователю apigee и доступен для чтения: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Установка и настройка Cassandra: 
    9. # Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Убедитесь, что узел запущен. Проверьте следующую команду на этом узле и других узлах кластера. Узел должен сообщить, что он находится в состоянии «UN» (включен/нормально): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Удалите дополнительные конфигурации, добавленные ранее из файла /opt/apigee/customer/application/cassandra.properties .
  11. Повторите шаги с 3 по 10 на всех начальных узлах Cassandra в центре обработки данных, один за другим.
  12. Повторите шаги с 3 по 10 на всех оставшихся узлах Cassandra в центре обработки данных, один за другим.
  13. Перестройте все узлы в центре обработки данных, используя центр обработки данных, работающий под управлением старой версии Cassandra. Выполняйте этот шаг по одному узлу за раз:
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Эта процедура может занять некоторое время. При необходимости можно настроить streamingthroughput . Проверьте статус завершения операции nodetool netstats .

  14. (Необязательно) Выполните команду восстановления в узле Cassandra, если данные не восстанавливаются. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Перезапустите все компоненты edge-* в центре обработки данных, один за другим: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. Проверьте и перенаправьте трафик обратно в этот центр обработки данных. Выполните несколько проверок трафика среды выполнения и API управления в этом центре обработки данных и начните перенаправлять трафик прокси-сервера и API управления обратно в него.
  17. Повторите указанные выше действия для каждого центра обработки данных, который вы хотите откатить.

Откат Cassandra с помощью резервной копии

Предпосылки

  1. Вы обновляете Cassandra с версии 3.11.X до 4.0.X и столкнулись с проблемами во время обновления.
  2. У вас есть резервные копии узла, к которому вы выполняете откат. Резервная копия была создана до попытки обновления с версии 3.11.X до 4.0.X.

Шаги

  1. Выберите один узел, который вы хотите откатить. Если вы откатываете все узлы в центре обработки данных с помощью резервных копий, начните с начальных узлов. См. раздел «Как определить начальные узлы» в Приложении.

  2. Остановите, удалите и очистите узел 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. Установите старую версию программного обеспечения Cassandra на узел и настройте ее:

    • Выполните файл начальной загрузки для Edge for Private Cloud 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
    • Создайте или отредактируйте файл /opt/apigee/customer/application/cassandra.properties : 
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Убедитесь, что файл принадлежит пользователю apigee и доступен для чтения: 
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Установка и настройка 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

    Убедитесь, что узел запущен. Проверьте следующую команду на этом узле и других узлах кластера. Узлы должны сообщить, что этот узел находится в состоянии «UN»: 

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

  4. Остановите службу Cassandra и восстановите резервную копию. Подробнее см. в документации по резервному копированию и восстановлению: 

    # 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. После восстановления резервной копии удалите дополнительные конфигурации:

    Удалите ранее добавленную конфигурацию из файла /opt/apigee/customer/application/cassandra.properties .

  6. Запустите службу Cassandra на узле: 

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

  7. Повторите эти шаги по одному на каждом узле Cassandra, который вы хотите откатить с помощью резервных копий.

  8. После восстановления всех узлов Cassandra перезапустите все компоненты edge-* один за другим: 

    /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

Оптимизация резервного копирования (расширенная опция)

Вы можете потенциально минимизировать (или полностью исключить) потерю данных при восстановлении из резервных копий, если у вас есть реплики с актуальными данными. Если реплики доступны, после восстановления резервной копии выполните восстановление на восстановленном узле.

Приложение

Как определить семенные узлы

На любом узле Cassandra в центре обработки данных выполните следующую команду: 

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

Команда выведет несколько строк. Найдите последнюю строку вывода. IP-адреса, указанные в последней строке, — это IP-адреса начальных узлов. В примере ниже DC-1-IP1 , DC-1-IP2 , DC-2-IP1 и DC-2-IP2 — это IP-адреса начальных узлов: 

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

Откатить обновление Zookeeper 3.8.4

Откат

В случае необходимости отката:

  1. Сначала выполните шаги отката для наблюдателей и последователей.
  2. Загрузите и запустите bootstrap версии, к которой вы откатываетесь — 4.52.02 или 4.53.00. Процесс, вероятно, будет зависеть от того, подключен ли узел к внешнему интернету или вы выполняете установку в автономном режиме.
  3. Остановите Zookeeper, если он запущен на узле: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. Удалите существующий Zookeeper: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Установите Zookeeper как обычно: 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. После того как все последователи и наблюдатели будут откатены, откатите узел-лидер, выполнив шаги 2–5 на узле-лидере.
  7. После отката всех узлов проверьте работоспособность кластера и убедитесь, что в кластере есть ведущий узел.

Восстановить резервную копию

См. раздел Восстановление из резервной копии . Обратите внимание, что резервные копии Zookeeper, созданные в более ранних версиях Edge для частного облака, таких как 4.52.02 или 4.53.00, должны быть совместимы с версией Zookeeper в Edge для частного облака 4.53.01.

Откатить обновление Postgres 17

Если вы выполнили обновление до 4.53.01 с версии 4.52.02 или 4.53.00, вам необходимо откатить обновление Postgres в дополнение к компонентам Edge.

Чтобы откатить обновление Postgres при обновлении Postgres в конфигурации «главный-резервный»:

  • Сделайте новый резервный узел главным сервером Postgres. Новый главный сервер Postgres будет иметь ту же версию, что и предыдущая установка Edge.
  • Настройте старый резервный узел как резервный узел нового главного сервера. Старый резервный узел будет той же версии, что и предыдущая установка Edge.
  • Зарегистрируйте новые главные и резервные узлы в группах аналитики и потребителей.

После завершения отката старый главный узел больше не понадобится. Вы можете вывести его из эксплуатации.

Прежде чем начать

Перед выполнением отката Postgres 17 до 14 выполните следующие действия на новом резервном хосте и старом резервном хосте, чтобы обновить свойство max_locks_per_transaction в apigee-postgresql :

  1. Если его нет, создайте файл /opt/apigee/customer/application/postgresql.properties
  2. Измените владельца этого файла на apigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Добавьте в файл следующее свойство: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Настройте apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. Перезапустите apigee-postgresql: 
    apigee-service apigee-postgresql restart
  1. Убедитесь, что новый резервный узел Postgres запущен:
    /opt/apigee/apigee-service/bin/apigee-all status

    Если Postgres не запущен, запустите его: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Убедитесь, что Postgres остановлен на старом главном узле и старом резервном узле:
    /opt/apigee/apigee-service/bin/apigee-all status

    Если Postgres запущен, остановите его: 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. Если установлено, запустите Qpid на старом резервном узле: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. Назначьте новый резервный узел главным узлом Postgres:
    1. Сделайте новый резервный узел новым главным :
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      При появлении запроса введите пароль Postgres для пользователя «apigee», который по умолчанию — «postgres».

    2. Отредактируйте файл конфигурации, который вы использовали для установки текущей версии Edge, указав следующее: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. Настройте новый мастер : 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Если вы уже обновили старый резервный узел до новой версии, сначала необходимо понизить версию программного обеспечения Apigee на старом резервном узле. Если на старом резервном узле всё ещё установлена ​​старая версия, вы можете пропустить этот шаг и перейти к шагу 6.
    1. Остановите Postgres на старом резервном узле: 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Удалите Postgres со старого резервного узла: 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
    3. Удалите каталог данных Postgres со старого резервного узла: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. Загрузите и запустите старую версию bootstrap (для версии Apigee, к которой вы откатываетесь) на старом резервном узле. Точные шаги могут различаться в зависимости от того, используете ли вы интернет- или офлайн-установку. Запуск старой версии Apigee bootstrap настроит yum-репозитории с данными старой версии Apigee.
    5. Настройте компоненты Postgres на старом резервном узле: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Проверьте и убедитесь, что компоненты Postgres на старом резервном узле были откатены до более старой версии: 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. Перестройте старый резервный узел:
    1. Отредактируйте файл конфигурации, который вы использовали для установки текущей версии Edge, указав следующее: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. Удалите каталог данных на старом резервном узле: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. Перенастройте старый резервный узел так, чтобы он стал резервным узлом нового главного узла: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Убедитесь, что Postgres работает на старом резервном узле:
      /opt/apigee/apigee-service/bin/apigee-all status

      Если Postgres не запущен, запустите его: 

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. Убедитесь, что новый резервный узел был добавлен, просмотрев файл /opt/apigee/apigee-postgresql/conf/pg_hba.conf на новом главном сервере.
  8. Просмотрите текущую аналитику и информацию о группах потребителей, выполнив следующую команду на сервере управления:
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Эта команда возвращает имя группы аналитики в поле name и имя группы потребителей в поле name в разделе consumer-groups . Она также возвращает UUID старого главного и резервного узлов Postgres в поле postgres-server и в поле datastores . Вывод должен выглядеть следующим образом: 

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. Получите адрес UUID старого главного узла, выполнив следующую команду curl на старом главном узле:
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    В конце вывода вы должны увидеть UUID узла в форме: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. Повторите предыдущий шаг, чтобы получить IP-адреса старого резервного узла и нового главного узла.
  11. Удалить старые главные и резервные узлы из группы потребителей:
    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

    Где axgroup-001 и consumer-group-001 — это имена групп аналитики и потребителей по умолчанию. masterUUID,standbyUUID расположены в том же порядке, в котором они были указаны выше при просмотре текущей информации об аналитике и группах потребителей. Возможно, вам потребуется указать их как standbyUUID,masterUUID .

    Свойство datastores для consumer-groups теперь должно быть пустым.

  12. Удалите старый главный и резервный узлы из аналитической группы:
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    Свойство postgres-server в разделе uuids теперь должно быть пустым.

  13. Зарегистрируйте новые главные и резервные узлы PG в аналитических и потребительских группах: 
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. Проверьте группу аналитики:
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Вы должны увидеть UUID нового главного и резервного узлов, перечисленные в группе аналитики и группе потребителей.

  15. Перезапустите сервер Edge Management: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. Перезапустите все серверы Qpid: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. Перезапустите все серверы Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. Проверьте состояние репликации, выполнив следующие скрипты на обоих серверах. Для подтверждения успешной репликации система должна выдать идентичные результаты на обоих серверах:

    На новом мастере выполните: 

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

    Убедитесь, что это главный узел. На старом резервном узле:

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

    Убедитесь, что он находится в режиме ожидания.

  19. Повторите предыдущий шаг, сделав несколько запросов API, чтобы убедиться, что узлы синхронизированы.
  20. Выведите из эксплуатации старый главный узел Postgres, следуя процедуре, описанной в разделе Вывод из эксплуатации узла Postgres .

    В качестве альтернативы вы можете удалить Qpid со старого главного узла и установить Qpid на новый главный узел . После удаления Qpid старый главный узел можно вывести из эксплуатации.

Откатить обновление LDAP 2.6

В этом разделе представлено подробное пошаговое руководство по откату установки LDAP к предыдущей версии. Откат должен быть выполнен для всего кластера LDAP и возможен только при использовании корректной резервной копии LDAP, созданной до обновления.

Основная цель — вернуть весь кластер LDAP в согласованное состояние из заведомо исправной резервной копии. Эта процедура одинакова для всех сценариев: один сервер, «активный-активный» и «активный-пассивный».

Предпосылки и соображения

  • Несовместимость резервных копий: используйте резервную копию более старой версии LDAP 2.4, которую вы использовали с Edge for Private Cloud 4.52.02 или 4.53.00. Эта резервная копия должна быть создана до попытки обновления. Резервные копии, созданные после обновления, несовместимы и не могут быть использованы.
  • Простой API управления: во время отката LDAP API управления будут недоступны, что может повлиять на административные задачи. Перед продолжением отката LDAP убедитесь, что все серверы edge-management-server и edge-ui отключены.
  • Риск потери данных: действия без действительной, совместимой резервной копии могут привести к необратимой потере данных.
  • Действительная резервная копия: требуется действительная резервная копия LDAP перед обновлением.

Процедура отката

  1. Перед продолжением обновления LDAP обязательно отключите все серверы edge-management-server и edge-ui. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. Резервное копирование существующих данных LDAP (перед остановкой LDAP)

    Получите общее количество записей для справки со всех серверов LDAP. (Количество записей должно совпадать на всех серверах LDAP.) 

          # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password. 
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. Остановите и удалите новый LDAP 2.6

    Остановите службу apigee-openldap и удалите её каталоги конфигурации и данных. Это необходимо выполнить на всех LDAP-серверах кластера, по одному узлу за раз, для обеспечения согласованности. 

    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. Установить старую версию LDAP 2.4
    • Установить старую версию LDAP: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • Проверьте версию LDAP: 
      source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
    • Повторите вышеуказанные шаги на каждом узле LDAP, по одному за раз.
  5. Очистить остаточные данные

    На всех серверах LDAP по одному остановите недавно установленную службу и очистите ее каталог данных, чтобы подготовиться к восстановлению из резервной копии. 

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. Восстановление данных LDAP

    Для настройки одного сервера перейдите сразу к шагу 5b. Для настройки нескольких серверов перейдите к шагу 5a.

    1. Определите активный сервер LDAP

      Перед восстановлением данных LDAP определите активный сервер (провайдера), выполнив эту команду. 

      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.
    2. Восстановите данные LDAP (перед восстановлением убедитесь, что шаг 4 выполнен на всех серверах.)
      • На единственном и активном сервере LDAP (определенном на шаге 5а) восстановите резервную копию. 
        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.
      • Запустите службу apigee-openldap. 
        apigee-service apigee-openldap start
  7. Запустить оставшиеся серверы LDAP

    Если у вас многосерверная конфигурация, запустите службу на каждом из серверов LDAP: 

    apigee-service apigee-openldap start
  8. Окончательная проверка
    • Последний шаг — убедиться, что откат прошел успешно и данные согласованы во всем кластере LDAP.
    • Выполните команду проверки на всех LDAP-серверах. Количество записей должно быть одинаковым на всех серверах и соответствовать количеству, полученному на шаге 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
    • После подтверждения корректности и согласованности данных откат LDAP завершён. Теперь вы можете приступить к запуску edge-management-server , edge-ui и любых других зависимых компонентов в соответствии со стандартной процедурой обновления вашей организации.

Откат к предыдущей основной или второстепенной версии

Чтобы вернуться к предыдущей основной или второстепенной версии, выполните следующие действия на каждом узле, на котором размещен компонент:

  1. Загрузите файл bootstrap.sh для версии, к которой вы хотите вернуться:

    • Чтобы вернуться к версии 4.52.02, скачайте bootstrap_4.52.02.sh
  2. Остановите компонент для отката:
    1. Чтобы откатить любой из компонентов с общим кодом на узле, необходимо остановить их все, как показано в следующем примере: 
      /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. Чтобы откатить любой другой компонент на узле, остановите только этот компонент: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Если вы откатываете монетизацию, удалите ее со всех узлов сервера управления и процессора сообщений: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Удалите компонент для отката на узле:
    1. Чтобы откатить любой из компонентов с общим кодом на узле, необходимо удалить их все, удалив группу компонентов edge-gateway и apigee-cassandra-client , как показано в следующем примере: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Чтобы откатить Nginx, выполните следующие действия: 
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
    3. Чтобы откатить любой другой компонент на узле, удалите только этот компонент, как показано в следующем примере:
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Где component — имя компонента.

    4. Чтобы откатить Edge Router, необходимо удалить содержимое файла /opt/nginx/conf.d в дополнение к удалению группы компонентов edge-gateway : 
      cd /opt/nginx/conf.d
rm -rf *
  5. Удалите версию 4.53.01 apigee-setup : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Установите версию 4.52.02 утилиты apigee-service и её зависимости. Следующий пример устанавливает версию 4.52.02 утилиты apigee-service :
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    Где uName и pWord — имя пользователя и пароль, полученные от Apigee. Если вы не укажете pWord , вам будет предложено ввести его.

    Если возникла ошибка, убедитесь, что вы загрузили файл bootstrap.sh на шаге 1.

  7. Установка apigee-setup : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Установите старую версию компонента:
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Где component — это устанавливаемый компонент, а configFile — ваш файл конфигурации для старой версии.

  9. Если вы откатываете Qpid, очистите iptables: 
    sudo iptables -F
  10. Повторите этот процесс для каждого узла, на котором размещен компонент, который вы откатываете.

Откат mTLS

Чтобы откатить обновление mTLS, выполните следующие действия на всех хостах:

  1. Остановить Апигее: 
    apigee-all stop
  2. Остановить mTLS: 
    apigee-service apigee-mtls uninstall
  3. Переустановите mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf