このページは Cloud Translation API によって翻訳されました。

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 の一般的なロールバック順序は次のようになります。

Qpid、その他の分析関連コンポーネント、Postgres をロールバックします。
ルーターと Message Processor をロールバックする
Cassandra、Zookeeper のロールバック
管理サーバーをロールバックする
LDAP のロールバック

たとえば、Cassandra クラスタ全体、すべての管理サーバー、いくつかの RMP をバージョン 4.52.02 からバージョン 4.53.01 にアップグレードし、ロールバックするとします。この場合は、次のようになります。

すべての RMP を 1 つずつロールバックする
バックアップを使用して Cassandra クラスタ全体をロールバックする
Edge Management Server ノードを 1 つずつロールバックする

ロールバックを実施できるユーザー

ロールバックを行うユーザーは、Edge を更新したユーザーか、root として実行するユーザーである必要があります。

デフォルトでは、Edge コンポーネントはユーザー「apigee」として動作します。ただし、場合によっては別のユーザーとして Edge コンポーネントを実行することもあります。たとえば、Router が特権付きポート（1000 未満のポート）にアクセスする必要がある場合、Router を root として実行するか、これらのポートに対するアクセス権限が割り当てられたユーザーとして実行しなければなりません。あるいは、あるコンポーネントをあるユーザーとして実行し、別のコンポーネントを別のユーザーとして実行することもできます。

共通のコードを使用するコンポーネント

次の Edge コンポーネントは共通のコードを共有します。したがって、ノード上でこれらのコンポーネントのいずれかをロールバックする場合は、そのノード上でこれらのコンポーネントをすべてロールバックする必要があります。

edge-management-server（Management Server）
edge-message-processor（Message Processor）
edge-router（ルーター）
edge-postgres-server（Postgres Server）
edge-qpid-server（Qpid Server）

たとえば、あるノードに Management Server、Router、Message Processor がインストールされている場合、このうちのいずれかをロールバックするとしたら、これら 3 つのコンポーネントのすべてをロールバックする必要があります。

Cassandra のロールバック

特定のノードで Cassandra のメジャーアップグレードが実行されると、Cassandra はそのノードに保存されているデータのスキーマを変更します。そのため、直接のインプレースロールバックは実現できません。

ロールバックのシナリオ

Edge for Private Cloud 4.53.01 で使用可能な Cassandra 4.0.X は、Private Cloud 4.52.02 の他のコンポーネントと互換性があります。

使用できるさまざまなロールバック戦略の概要については、以下の表をご覧ください。

シナリオ	ロールバック戦略
単一の DC、一部の Cassandra ノードがアップグレードされている	バックアップを使用する
単一の DC、すべての Cassandra ノードがアップグレードされている	Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。
単一の DC、すべてのノード（Cassandra など）がアップグレードされている	Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。
複数の DC、1 つの DC の一部のノードがアップグレードされた	既存の DC から再構築する
複数の DC、一部の DC のすべての Cassandra ノードがアップグレードされた	既存の DC から再構築する
複数の DC、最後の DC の Cassandra ノードがアップグレードされている	アップグレードを完了してみてください。実行できない場合は、バックアップを使用して 1 つの DC をロールバックします。ロールバックされた DC から残りの DC を再構築します。
複数の DC、すべての Cassandra ノードがアップグレードされている	Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。
複数の DC、すべてのノード（Cassandra など）がアップグレードされた	Cassandra をロールバックしないでください。他のコンポーネントはロールバックできます。

一般的な考慮事項

ロールバックを検討する際は、次の点に注意してください。

ランタイムコンポーネントまたは管理コンポーネントのロールバック: edge-management-server、edge-message-processor などのコンポーネントや、Cassandra 以外のコンポーネントを Private Cloud バージョン 4.52.02 にロールバックする場合は、Cassandra をロールバックしないことをおすすめします。Private Cloud 4.53.00 に付属の Cassandra は、Edge for Private Cloud 4.52.02 の Cassandra 以外のすべてのコンポーネントと互換性があります。Cassandra がバージョン 4.0.13 のままである間は、ここに記載されている方法を使用して Cassandra 以外のコンポーネントをロールバックできます。
Cassandra クラスタ全体が 4.0.X にアップグレードされた後のロールバック: Private Cloud バージョン 4.53.00 へのアップグレードの一環として Cassandra クラスタ全体がバージョン 4.0.X にアップグレードされた場合は、このクラスタ設定を続行し、Cassandra をロールバックしないことをおすすめします。Private Cloud バージョン 4.52.02 の edge-management-server、edge-message-processor、edge-router などのコンポーネントは、Cassandra バージョン 4.0.X と互換性があります。
Cassandra のアップグレード中の 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）をまだ実行している完全に機能するデータセンターが少なくとも 1 つある。

この手順は、既存のデータセンターからのデータストリーミングに依存しています。Cassandra に保存されているデータの量によっては、かなりの時間がかかることがあります。ロールバックの進行中に、ランタイムトラフィックをこのデータセンターから転送できるように準備する必要があります。

手順の概要

ロールバックするデータセンター（部分的にアップグレードされたもの、完全にアップグレードされたもののいずれか）を 1 つ選択します。ランタイムトラフィックを別の機能しているデータセンターに転送します。
データセンター内のシードノードを特定し、いずれかのシードノードから開始します。
Cassandra ノードを停止、アンインストール、クリーンアップします。
ノードに古いバージョンの Cassandra をインストールし、必要に応じて構成します。
先ほど追加した余分な構成を削除します。
データセンター内のすべてのシードノードに対して、上記の手順を 1 つずつ繰り返します。
データセンター内の残りのすべての Cassandra ノードに対して、上記の手順を 1 つずつ繰り返します。
既存の機能するデータセンターからノードを 1 つずつ再構築します。
Cassandra に接続されているデータセンター内のすべての edge-* コンポーネントを再起動します。
トラフィックをテストして、このデータセンターにリダイレクトします。
データセンターごとに、上記の手順を 1 つずつ繰り返します。

詳細な手順

すべての Cassandra ノードまたは一部の Cassandra ノードがアップグレードされるデータセンターを 1 つ選択します。このデータセンターの Cassandra ノードがロールバックされている間、このデータセンターからのすべてのランタイムプロキシトラフィックと管理トラフィックを転送します。ノードで nodetool ring コマンドを実行したときに、すべての Cassandra ノードが UN（Up/Normal）状態であることを確認します。特定のノードがダウンしている場合は、問題をトラブルシューティングし、それらのノードを復元してから続行します。

下記の例をご覧ください。

/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 である 2 つのデータセンタークラスタのインスタンスを示しています。

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

データセンター内のシードノードを特定します。付録のシードノードを特定する方法のセクションを参照してください。シードノードのいずれかで次の手順を実行します。

Cassandra のノードからデータを停止、アンインストール、クリーンアップします。このデータセンターの Cassandra バージョン 4 の最初のシードノードを選択します。Stop it.

# 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

ノードに古い Cassandra ソフトウェアをインストールし、いくつかの構成を設定します。Edge for Private Cloud 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

/opt/apigee/customer/application/cassandra.properties ファイルを作成または編集します。
ファイルに次の内容を追加します。ipOfNode は、Cassandra が他の Cassandra ノードとの通信に使用するノードの IP アドレスです。
```
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
# 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

ノードが起動したことを確認します。このノードとクラスタ内の他のノードで次のコマンドを確認します。ノードが「UN」（Up/Normal）状態であることを報告する必要があります。
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
以前に追加した余分な構成をファイル /opt/apigee/customer/application/cassandra.properties から削除します。
データセンター内のすべての Cassandra シードノードで、ステップ 3 ～ 10 を 1 つずつ繰り返します。
データセンター内の残りのすべての Cassandra ノードで、ステップ 3 ～ 10 を 1 つずつ繰り返します。
古い Cassandra バージョンを実行しているデータセンターから、データセンター内のすべてのノードを再構築します。この手順は、一度に 1 つのノードで実行します。
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
この手順には時間がかかることがあります。必要に応じて streamingthroughput を調整できます。nodetool netstats でオペレーションの完了ステータスを確認します。
（省略可）データが再構築されない場合は、Cassandra ノードで修復コマンドを実行します。
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

データセンター内のすべての edge-* コンポーネントを 1 つずつ再起動します。

/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

トラフィックを検証して、このデータセンターにリダイレクトします。このデータセンターでランタイムトラフィックと管理 API の検証を実行し、プロキシと管理 API のトラフィックをこのデータセンターにリダイレクトします。
ロールバックするデータセンターごとに上記の手順を繰り返します。

バックアップを使用して Cassandra をロールバックする

前提条件

Cassandra を 3.11.X から 4.0.X にアップグレードするプロセスで、アップグレード中に問題が発生しました。
ロールバックするノードのバックアップがある。バックアップは、3.11.X から 4.0.X へのアップグレードを試みる前に作成されました。

手順

ロールバックするノードを 1 つ選択します。バックアップを使用してデータセンター内のすべてのノードをロールバックする場合は、まずシードノードから開始します。付録の「シードノードを特定する方法」のセクションを参照してください。

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

ノードに古い 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

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

バックアップが復元されたら、追加の構成を削除します。

以前に追加した構成を /opt/apigee/customer/application/cassandra.properties ファイルから削除します。

ノードで Cassandra サービスを起動します。

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

バックアップを使用してロールバックする Cassandra ノードごとに、手順を 1 つずつ繰り返します。

すべての Cassandra ノードが復元されたら、edge-* コンポーネントを 1 つずつ再起動します。

/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 アドレスはシードノードです。次の例では、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 アップデートをロールバックする

ロールバック

ロールバックが必要な場合:

オブザーバーとフォロワーでロールバック手順を最初に実行します。
ロールバック先のバージョン（4.52.02 または 4.53.00）のブートストラップをダウンロードして実行します。このプロセスは、ノードに外部インターネット接続があるかどうか、またはオフラインインストールを行っているかどうかによって異なる場合があります。
ノードで ZooKeeper が実行されている場合は、停止します。
```
  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
```

既存の zookeeper をアンインストールします。

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

通常どおり Zookeeper をインストールします。

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

すべてのフォロワーとオブザーバーがロールバックされたら、リーダーノードでステップ 2 ～ 5 に沿ってリーダーノードをロールバックします。
すべてのノードがロールバックされたら、クラスタの健全性を確認し、クラスタにリーダーノードがあることを確認します。

バックアップを復元

バックアップからの復元を参照してください。4.52.02 や 4.53.00 などの以前のバージョンの Edge for Private Cloud から取得した Zookeeper のバックアップは、Edge for Private Cloud 4.53.01 の Zookeeper のバージョンと互換性があるはずです。

Postgres 17 更新のロールバック

4.52.02 または 4.53.00 から 4.53.01 にアップグレードした場合、Edge コンポーネントだけでなく Postgres 更新もロールバックする必要があります。

マスター / スタンバイ構成で Postgres を更新している場合は、次の手順に沿って Postgres 更新をロールバックします。

新しいスタンバイノードを Postgres マスターに昇格させます。新しい Postgres マスターのバージョンは、前の Edge インストール環境でのバージョンと同じです。
旧スタンバイノードを構成して、新しいマスターのスタンバイノードにします。旧スタンバイノードのバージョンは、前の Edge インストール環境でのバージョンと同じです。
新しいマスターノードとスタンバイノードをアナリティクスグループとコンシューマグループに登録します。

ロールバックが完了した後、旧マスターノードは不要になります。したがって、旧マスターノードを廃止できます。

始める前に

Postgres 17 から 14 へのロールバックを実行する前に、新しいスタンバイホストと古いスタンバイの両方で次の手順を行い、apigee-postgresql の max_locks_per_transaction プロパティを更新します。

存在しない場合は、/opt/apigee/customer/application/postgresql.properties ファイルを作成します。

このファイルの所有者を apigee に変更します。

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

ファイルに次のプロパティを追加します。
```
conf/postgresql.conf+max_locks_per_transaction=30000
```

apigee-postgresql を構成します。

apigee-service apigee-postgresql configure

apigee-postgresql を再起動します。
```
apigee-service apigee-postgresql restart
```

新しいスタンバイ Postgres ノードが稼働していることを確認します。
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Postgres が稼働していない場合は、起動します。
```
/opt/apigee/apigee-service/bin/apigee-all start
```

旧マスターノードと旧スタンバイノード上で 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

Qpid がインストールされている場合は、旧スタンバイノードで起動します。
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
注: 多くの構成では、旧スタンバイノードは Postgres のみをホストし、Qpid はホストしません。
新しいスタンバイノードを Postgres マスターとして昇格させます。
1. 新しいスタンバイノードを新しいマスターに昇格させます。
```
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
```
  プロンプトが表示されたら、「apigee」ユーザーの Postgres パスワードを入力します。デフォルトのパスワードは「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
```
古いスタンバイノードを新しいバージョンにすでにアップグレードしている場合は、まず古いスタンバイノードの 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. 古いスタンバイノードで、古いバージョンのブートストラップ（ロールバック先の Apigee バージョン用）をダウンロードして実行します。正確な手順は、インターネットベースのインストールを使用しているか、オフラインインストールを使用しているかによって異なります。古いバージョンの Apigee ブートストラップを実行すると、古いバージョンの Apigee データで yum リポジトリが設定されます。
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
```

注: rpm postgresql17-libs-17.4-1PGDG がまだ存在する場合は、必ず削除してください。

旧スタンバイノードを再ビルドします。
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
```
新しいマスターの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイノードが追加されたことを確認します。

Management Server で次のコマンドを実行して、現在のアナリティクスグループとコンシューマグループを表示します。

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

このコマンドの出力結果から、分析グループの名前（name フィールド）とコンシューマグループの名前（consumer-groups の name フィールド）がわかります。また、旧 Postgres マスターノードと旧 Postgres スタンバイノードの UUID を、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" : {
  }
}

旧マスターノードで次の curl コマンドを実行して、旧マスターの UUID アドレスを取得します。
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
出力結果の最後の行に、次の形式でノードの UUID が表示されます。
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
注: edge-postgres-server サービスが実行されている必要があります。Postgres サーバーが稼働していない場合は、Management Server で次のコマンドを実行すると、UUID を確認できます。
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
このコマンドの出力には、各 Postres ノードの IP アドレスに対応する UUID のリストが表示されます。
上記の手順を繰り返して、旧スタンバイノードと新しいマスターノードの IP アドレスを取得します。
旧マスターノードと旧スタンバイノードをコンシューマグループから削除します。
```
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 として指定する必要があります。

この時点で、consumer-groups の datastores プロパティは空です。
旧マスターノードと旧スタンバイノードを分析グループから削除します。
```
curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
```
この時点で、uuids の postgres-server プロパティは空です。

新しい PG マスターノードと 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

分析グループを確認します。
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
分析グループとコンシューマグループに、新しいマスターノードとスタンバイノードの UUID がリストされるはずです。

Edge Management Server を再起動します。

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

すべての Qpid サーバーを再起動します。

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

すべての Postgres サーバーを再起動します。

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

両方のサーバーで、次のスクリプトを実行してレプリケーションステータスを確認します。両方のサーバーで同じ結果が表示された場合、レプリケーションは成功しています。
新しいマスターで次のコマンドを実行します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
マスターであることを確認します。旧スタンバイノードで次のスクリプトを実行します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
スタンバイであることを確認します。
いくつかの API リクエストを実行してノードが同期していることを確認してから、前のステップを繰り返します。
Postgres ノードを廃止するの手順に沿って、旧 Postgres マスターを廃止します。
注: 旧マスターノードで Qpid が実行されていた場合は、Qpid を実行するためにそのサーバーを稼働したままにできます。サーバーが稼働していることを確認してください。そうでない場合は、起動します。
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-server start
```
または、旧マスターノードから Qpid をアンインストールし、新しいマスターノードに Qpid をインストールすることもできます。Qpid をアンインストールした後、旧マスターノードを廃止できます。

LDAP 2.6 アップデートをロールバックする

このセクションでは、LDAP インストールを以前の LDAP バージョンにロールバックするための包括的な手順を説明します。ロールバックは LDAP クラスタ全体で実行する必要があり、アップグレード前の有効な LDAP バックアップを使用した場合にのみ可能です。

主な目的は、既知の正常なバックアップから LDAP クラスタ全体を一貫性のある状態に戻すことです。この手順は、単一サーバー、アクティブ - アクティブ、アクティブ - パッシブのすべてのシナリオで同じです。

前提条件と考慮事項

バックアップの非互換性: Edge for Private Cloud 4.52.02 または 4.53.00 で実行していた古い 2.4 LDAP バージョンのバックアップを使用します。このバックアップは、アップグレードを試みる前に作成されている必要があります。アップグレード後に作成されたバックアップは互換性がなく、使用できません。
Management API のダウンタイム: LDAP のロールバック中、Management API は使用できなくなります。これにより、管理タスクに影響が生じる可能性があります。LDAP ロールバックを続行する前に、必ずすべての edge-management-server と edge-ui をシャットダウンしてください。
データ損失のリスク: 有効で互換性のあるバックアップなしで続行すると、不可逆的なデータ損失のリスクがあります。
有効なバックアップ: アップグレード前の有効な LDAP バックアップが必要です。

ロールバック手順

LDAP のアップグレードを続行する前に、すべての edge-management-server と edge-ui をシャットダウンしてください。
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
既存の 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
```
新しい LDAP 2.6 を停止してアンインストールする
apigee-openldap サービスを停止し、構成ディレクトリとデータディレクトリを削除します。整合性を確保するため、クラスタ内のすべての LDAP サーバーで一度に 1 つのノードに対して実行する必要があります。
```
apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
```
古い 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 ノードで上記の手順を 1 つずつ繰り返します
残存データをクリーンアップする
すべての LDAP サーバーで、新しくインストールしたサービスを 1 つずつ停止し、そのデータディレクトリをクリーンアップして、バックアップからの復元を準備します。
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```
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 サーバー（ステップ 5a で決定）で、バックアップを復元します。
```
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
```
残りの LDAP サーバーを起動する
マルチサーバー設定の場合は、各 LDAP サーバーでサービスを開始します。
```
apigee-service apigee-openldap start
```
注: これらのピアサーバーでデータを手動で復元する必要はありません。起動すると、最初のサーバー（復元されたデータを含む）に接続し、レプリケーションを介してディレクトリ全体を自動的に同期します。
最終検証
- 最後のステップは、ロールバックが成功し、データが 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、その他の依存コンポーネントの起動に進むことができます。

以前のメジャーリリースまたはマイナーリリースにロールバックする

以前のメジャーリリースまたはマイナーリリースにロールバックするには、該当するコンポーネントをホストしている各ノード上で、次の手順を行います。

ロールバック先のバージョンの bootstrap.sh ファイルをダウンロードします。
- 4.52.02 にロールバックする場合は、bootstrap_4.52.02.sh をダウンロードします。
ロールバックするコンポーネントを停止します。
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
```
Monetization をロールバックする場合は、すべての Management Server ノードと Message Processor ノードから Monetization をアンインストールします。
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
ロールバックするコンポーネントをノードからアンインストールします。
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 をロールバックする場合、edge-gateway コンポーネントグループをアンインストールするだけでなく、/opt/nginx/conf.d ファイルの内容を削除する必要もあります。
```
cd /opt/nginx/conf.d
rm -rf *
```
4.53.01 バージョンの apigee-setup をアンインストールします。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
```
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 を省略すると、パスワードの入力を求められます。

エラーが発生した場合は、手順 1 で bootstrap.sh ファイルをダウンロードしたことを確認してください。

apigee-setup をインストールします。

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

古いバージョンのコンポーネントをインストールします。
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
ここで、component はインストールするコンポーネント、configFile は古いバージョンの構成ファイルです。
Qpid をロールバックしている場合は、iptables を消去します。
```
sudo iptables -F
```
ロールバックするコンポーネントをホストしているノードのそれぞれで、上記のプロセスを繰り返します。

mTLS をロールバックする

mTLS 更新をロールバックするには、すべてのホストで次の手順を行います。

Apigee を停止します。
```
apigee-all stop
```
mTLS を停止します。
```
apigee-service apigee-mtls uninstall
```

mTLS を再インストールします。

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

Apigee Edge 4.53.01 のロールバック

ロールバックの順序

ロールバックを実施できるユーザー

共通のコードを使用するコンポーネント

Cassandra のロールバック

ロールバックのシナリオ

一般的な考慮事項

再構築を使用して Cassandra をロールバックする

前提条件

手順の概要

詳細な手順

バックアップを使用して Cassandra をロールバックする

前提条件

手順

バックアップの最適化（詳細オプション）

付録

シードノードを特定する方法

Zookeeper 3.8.4 アップデートをロールバックする

ロールバック

バックアップを復元

Postgres 17 更新のロールバック

始める前に

LDAP 2.6 アップデートをロールバックする

前提条件と考慮事項

ロールバック手順

以前のメジャー リリースまたはマイナー リリースにロールバックする

mTLS をロールバックする

以前のメジャーリリースまたはマイナーリリースにロールバックする