如果您在更新到 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。
- 回滚路由器和消息处理器
- 回滚 Cassandra、Zookeeper
- 回滚管理服务器
- 回滚 LDAP
例如,假设您已将整个 Cassandra 集群、所有管理服务器和部分 RMP 从版本 4.52.02 升级到版本 4.53.01,现在希望回滚。在这种情况下,您需要:
- 逐个回滚所有 RMP
- 使用备份回滚整个 Cassandra 集群
- 逐个回滚 Edge 管理服务器节点
谁可以执行回滚
执行回滚的用户应与最初更新 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 会修改存储在该节点上的数据的架构。因此,直接就地回滚是不可行的。
回滚场景
Edge for Private Cloud 4.53.01 随附的 Cassandra 4.0.X 与 Private Cloud 4.52.02 的其他组件兼容。
下表总结了您可以使用的各种回滚策略:
场景 | 回滚策略 |
---|---|
单个数据中心,部分 Cassandra 节点已升级 | 使用备份 |
单个 DC,所有 Cassandra 节点均已升级 | 请勿回滚 Cassandra。其他组件可以回滚。 |
单个数据中心,所有节点(Cassandra 和其他节点)均已升级 | 请勿回滚 Cassandra。其他组件可以回滚。 |
多个数据中心,其中一个数据中心中的部分节点已升级 | 从现有 DC 重新构建 |
多个数据中心,部分数据中心中的所有 Cassandra 节点已升级 | 从现有 DC 重新构建 |
多个 DC,正在升级最后一个 DC 的 Cassandra 节点 | 尝试完成升级。如果不可行,请使用备份回滚 1 个 DC。从回滚的 DC 重新构建其余 DC。 |
多个数据中心,所有 Cassandra 节点均已升级 | 请勿回滚 Cassandra。其他组件可以回滚。 |
多个数据中心,所有节点(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 组件,同时 Cassandra 仍保持在 4.0.13 版。
- 在整个 Cassandra 集群升级到 4.0.X 后回滚:如果您的整个 Cassandra 集群在升级到 Private Cloud 版本 4.53.00 的过程中升级到版本 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)。
此过程依赖于从现有数据中心流式传输数据。这可能需要相当长的时间,具体取决于 Cassandra 中存储的数据量。在回滚进行期间,您应准备好将运行时流量从该数据中心转移出去。
简要步骤
- 选择要回滚的数据中心(部分或完全升级)。将运行时流量分流到其他正常运行的数据中心。
- 确定数据中心内的种子节点,并从其中一个种子节点开始。
- 停止、卸载并清理 Cassandra 节点。
- 在节点上安装旧版 Cassandra,并根据需要进行配置。
- 移除之前添加的额外配置。
- 对数据中心中的所有种子节点逐个重复上述步骤。
- 对数据中心内的所有剩余 Cassandra 节点逐一重复上述步骤。
- 从现有的功能性数据中心逐个重建节点。
- 重启数据中心内连接到 Cassandra 的所有 edge-* 组件。
- 测试并将流量重新分流到此数据中心。
- 针对每个数据中心逐一重复上述步骤。
详细步骤
-
选择一个数据中心,其中所有或部分 Cassandra 节点已升级。在回滚此数据中心内的 Cassandra 节点时,将所有运行时代理流量和管理流量从此数据中心分流。
确保在节点上执行
nodetool ring
命令时,所有 Cassandra 节点都处于 UN(启动/正常)状态。如果某些节点处于关闭状态,请先排查问题并使这些节点恢复运行,然后再继续。请参见下面的示例:
/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] - 确定数据中心内的种子节点:请参阅附录中的如何确定种子节点部分。在其中一个种子节点上执行以下步骤:
- 停止、卸载并清理 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 datarm -rf /opt/apigee/data/apigee-cassandra
- 在节点上安装较早的 Cassandra 软件并设置一些配置。 执行 Edge Private Cloud 4.52.02 的引导加载程序文件。
- 创建或修改文件
/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:
- 验证节点是否已启动。在此节点和集群中的其他节点上检查以下命令。节点应报告其处于“UN”(启动/正常)状态:
/opt/apigee/apigee-cassandra/bin/nodetool status
- 从文件
/opt/apigee/customer/application/cassandra.properties
中移除之前添加的额外配置。 - 对数据中心内的所有 Cassandra 种子节点逐一重复执行第 3 步到第 10 步。
- 对数据中心内的所有剩余 Cassandra 节点逐一重复执行第 3 步到第 10 步。
- 从运行旧版 Cassandra 的数据中心重建数据中心中的所有节点。一次在一个节点上执行此步骤:
/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-* 组件:
/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 流量重新路由回该数据中心。
- 针对要回滚的每个数据中心重复上述步骤。
# Download bootstrap of 4.52.02curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord
# Execute bootstrap of 4.52.02sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
# 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
使用备份回滚 Cassandra
前提条件
- 您正在将 Cassandra 从 3.11.X 升级到 4.0.X,但在升级过程中遇到了问题。
- 您要回滚的节点有备份。备份是在尝试从 3.11.X 升级到 4.0.X 之前创建的。
步骤
选择要回滚的节点。如果您要使用备份回滚数据中心内的所有节点,请先从种子节点开始。请参阅附录中的“如何识别种子节点”部分。
停止、卸载并清理 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 datarm -rf /opt/apigee/data/apigee-cassandra
在节点上安装较旧的 Cassandra 软件并进行配置:
- 执行 Edge Private Cloud 4.52.02 的引导文件:
- 创建或修改
/opt/apigee/customer/application/cassandra.properties
文件: - 确保该文件归 apigee 用户所有,并且可供读取:
- 安装和设置 Cassandra:
# 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.02sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
# 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 restorerm -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 节点(一次一个)重复上述步骤。
恢复所有 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 地址是种子节点。在以下示例中,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 回滚领导者节点。
- 在所有节点都回滚后,验证集群健康状况,并确保集群中存在领导者节点。
恢复备份
请参阅从备份中恢复。 请注意,从 Edge for Private Cloud 的早期版本(例如 4.52.02 或 4.53.00)获取的 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 主节点:
- 将新的备用节点提升为新的主节点:
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
如果系统提示,请输入“apigee”用户的 Postgres 密码,该密码默认为“postgres”。
- 修改用于安装当前 Edge 版本的配置文件,以指定以下内容:
# IP address of the new master: PG_MASTER=new_standby_IP # IP address of the old standby node PG_STANDBY=old_standby_IP
- 配置新主设备:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
- 将新的备用节点提升为新的主节点:
- 如果您已将旧备用节点升级到较新版本,则必须先降级旧备用节点上的 Apigee 软件。如果您仍有旧版本位于旧备用节点上,则可以跳过此步骤,继续执行第 6 步。
- 在旧的备用节点上停止 Postgres:
apigee-service apigee-postgresql stop apigee-service edge-postgres-server stop
- 从旧的备用节点卸载 Postgres:
apigee-service apigee-postgresql uninstall apigee-service edge-postgres-server uninstall
- 从旧备用节点中删除 Postgres 数据目录:
cd /opt/apigee/data/apigee-postgresql/pgdata rm -rf *
- 在旧备用节点上下载并运行旧版引导加载程序(针对您要回滚到的 Apigee 版本)。具体步骤可能会因您使用的是基于网络的安装还是离线安装而有所不同。运行旧版 Apigee 引导加载程序将使用旧版 Apigee 数据设置 yum 仓库。
- 在旧备用节点上设置 Postgres 组件:
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
- 检查并验证旧备用节点上的 Postgres 组件是否已回滚到旧版本:
apigee-service apigee-postgresql version apigee-service edge-postgres-server version
- 在旧的备用节点上停止 Postgres:
- 重建旧备用节点:
- 修改用于安装当前 Edge 版本的配置文件,以指定以下内容:
# IP address of the new master: PG_MASTER=new_standby_IP # IP address of the old standby node PG_STANDBY=old_standby_IP
- 移除旧备用节点上的数据目录:
cd /opt/apigee/data/apigee-postgresql/pgdata rm -rf *
- 将旧的备用节点重新配置为新主节点的备用节点:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
- 确保 Postgres 在旧的备用节点上运行:
/opt/apigee/apigee-service/bin/apigee-all status
如果 Postgres 未运行,请启动它:
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
- 修改用于安装当前 Edge 版本的配置文件,以指定以下内容:
- 通过查看新主节点上的
/opt/apigee/apigee-postgresql/conf/pg_hba.conf
文件,验证是否已添加新的备用节点。 - 在管理服务器上运行以下命令,查看当前的分析和消费者群组信息:
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
此命令会在
name
字段中返回分析组名称,并在consumer-groups
下的name
字段中返回消费群组名称。它还在postgres-server
字段和datastores
字段中返回旧 Postgres 主节点和备用节点的 UUID。您应该会看到以下形式的输出:{ "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"
- 重复上一步,获取旧备用节点和新主节点的 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 主节点和备用节点:
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。卸载 Qpid 后,您可以停用旧的主节点。
回滚 LDAP 2.6 更新
本部分提供了一份全面的分步指南,用于将 LDAP 安装回滚到之前的 LDAP 版本。回滚必须在整个 LDAP 集群上执行,并且只能使用有效的升级前 LDAP 备份。
主要目标是将整个 LDAP 集群从已知良好的备份恢复到一致的状态。此过程适用于所有方案 - 单服务器、主动/主动和主动/被动。
前提条件和注意事项
- 备份不兼容:请使用您之前在 Edge for Private Cloud 4.52.02 或 4.53.00 中运行的旧版 2.4 LDAP 的备份。此备份必须是在尝试升级之前创建的。升级后创建的备份不兼容,无法使用。
- 管理 API 停机时间:在 LDAP 回滚期间,管理 API 将不可用,这可能会影响管理任务。在继续执行 LDAP 回滚之前,请务必关闭所有 edge-management-server 和 edge-ui。
- 数据丢失风险:在没有有效且兼容的备份的情况下继续操作,可能会导致数据丢失且无法恢复。
- 有效备份:必须提供有效的升级前 LDAP 备份。
回滚程序
- 请务必先关闭所有边缘管理服务器和边缘界面,然后再继续进行 LDAP 升级。
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 服务器上执行此操作,集群中一次只能在一个节点上执行此操作,以确保一致性。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 节点上重复上述步骤,一次一个节点
- 安装旧版 LDAP:
- 清理残留数据
在所有 LDAP 服务器上,一次停止一个新安装的服务,并清理其数据目录,以便为从备份恢复做好准备。
apigee-service apigee-openldap stop rm -rf /opt/apigee/data/apigee-openldap/*
- 恢复 LDAP 数据
对于单服务器设置,您可以直接跳到步骤 5b。对于多服务器设置,请继续执行步骤 5a。
- 确定有效的 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.
- 恢复 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 服务器(在第 5a 步中确定)上,恢复备份。
- 确定有效的 LDAP 服务器
- 启动其余 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
- 如需回滚到 4.52.02,请下载
- 停止要回滚的组件:
- 如需回滚节点上的任何具有通用代码的组件,您必须停止所有这些组件,如以下示例所示:
/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
- 如需回滚节点上的任何其他组件,请仅停止该组件:
/opt/apigee/apigee-service/bin/apigee-service component stop
- 如需回滚节点上的任何具有通用代码的组件,您必须停止所有这些组件,如以下示例所示:
- 如果您要回滚 Monetization,请从所有管理服务器和消息处理器节点中将其卸载:
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- 卸载组件以在节点上回滚:
- 如需回滚节点上的任何具有通用代码的组件,您必须通过卸载
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
- 如需回滚 Nginx,请执行以下操作:
###Find the apigee-nginx RPM rpm -qa | grep -i "apigee-nginx" ###Remove the apigee-nginx RPM dnf remove apigee-nginx-1.26.x
- 如需回滚节点上的任何其他组件,请仅卸载该组件,如以下示例所示:
/opt/apigee/apigee-service/bin/apigee-service component uninstall
其中,component 是组件名称。
- 如需回滚 Edge 路由器,您必须删除
/opt/nginx/conf.d
文件的内容,并卸载edge-gateway
组件组:cd /opt/nginx/conf.d
rm -rf *
- 如需回滚节点上的任何具有通用代码的组件,您必须通过卸载
- 卸载
apigee-setup
的 4.53.01 版本:/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