이 페이지는 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를 롤백합니다.
라우터 및 메시지 프로세서 롤백
Cassandra, Zookeeper 롤백
관리 서버 롤백
LDAP 롤백

예를 들어 전체 Cassandra 클러스터, 모든 관리 서버, 일부 RMP를 버전 4.52.02에서 버전 4.53.01로 업그레이드한 후 롤백하려고 한다고 가정해 보겠습니다. 이 경우 다음을 수행합니다.

모든 RMP를 하나씩 롤백
백업을 사용하여 전체 Cassandra 클러스터 롤백
Edge 관리 서버 노드를 하나씩 롤백

롤백을 실행할 수 있는 사용자

롤백을 실행하는 사용자는 원래 Edge를 업데이트한 사용자와 동일하거나 루트로 실행되는 사용자여야 합니다.

기본적으로 Edge 구성요소는 'apigee' 사용자로 실행됩니다. 경우에 따라 Edge 구성요소를 다른 사용자로 실행할 수 있습니다. 예를 들어 라우터가 1000 미만의 권한 있는 포트에 액세스해야 하는 경우 라우터를 루트로 실행하거나 해당 포트에 액세스할 수 있는 사용자로 실행해야 합니다. 또는 한 구성요소를 한 사용자로 실행하고 다른 구성요소를 다른 사용자로 실행할 수 있습니다.

공통 코드가 있는 구성요소

다음 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의 다른 구성요소와 호환됩니다.

사용할 수 있는 다양한 롤백 전략의 요약은 아래 표를 참고하세요.

시나리오	롤백 전략
단일 DC, 일부 Cassandra 노드 업그레이드	백업 사용
단일 DC, 모든 Cassandra 노드 업그레이드	Cassandra를 롤백하지 마세요. 다른 구성요소는 롤백할 수 있습니다.
단일 DC, 모든 노드 (Cassandra 및 기타) 업그레이드됨	Cassandra를 롤백하지 마세요. 다른 구성요소는 롤백할 수 있습니다.
여러 DC, 한 DC의 일부 노드가 업그레이드됨	기존 DC에서 다시 빌드
여러 DC, 일부 DC의 모든 Cassandra 노드가 업그레이드됨	기존 DC에서 다시 빌드
여러 DC, 마지막 DC의 Cassandra 노드가 업그레이드됨	업그레이드를 완료해 보세요. 불가능한 경우 백업을 사용하여 DC 1 롤백합니다. 롤백된 DC에서 나머지 DC를 다시 빌드합니다.
여러 DC, 모든 Cassandra 노드 업그레이드	Cassandra를 롤백하지 마세요. 다른 구성요소는 롤백할 수 있습니다.
여러 DC, 모든 노드 (Cassandra 및 기타) 업그레이드됨	Cassandra를 롤백하지 마세요. 다른 구성요소는 롤백할 수 있습니다.

일반적인 고려사항

롤백을 고려할 때는 다음 사항에 유의하세요.

런타임 또는 관리 구성요소 롤백: edge-management-server, edge-message-processor 또는 Cassandra가 아닌 구성요소를 프라이빗 클라우드 버전 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 롤백

기본 요건

여러 데이터 센터에서 프라이빗 클라우드 4.52.02 클러스터용 Edge를 운영하고 있습니다.
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에 있는 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 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 소프트웨어를 설치하고 일부 구성을 설정합니다. Private Cloud용 Edge 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

Cassandra 구성 설정

/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를 설치하고 설정합니다.

Cassandra 버전 3.11.X를 설치합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

표준 구성 파일을 전달하여 Cassandra를 설정합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

Cassandra 3.11.X가 설치되어 있고 서비스가 실행 중인지 확인합니다.

/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
```
이전에 추가된 추가 구성을 /opt/apigee/customer/application/cassandra.properties 파일에서 삭제합니다.
데이터 센터의 모든 Cassandra 시드 노드에서 3~6단계를 하나씩 반복합니다.
데이터 센터의 나머지 모든 Cassandra 노드에서 3~6단계를 하나씩 반복합니다.
이전 Cassandra 버전을 실행하는 데이터 센터에서 데이터 센터의 모든 노드를 다시 빌드합니다. 한 번에 하나의 노드에서 다음 단계를 실행합니다.
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
이 절차는 다소 시간이 걸릴 수 있습니다. 필요한 경우 streamingthroughput를 조정할 수 있습니다. 다음을 사용하여 상태를 확인합니다.
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```

데이터 센터에서 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 트래픽을 다시 라우팅합니다.
롤백하려는 각 데이터 센터에 대해 위 단계를 반복합니다.

백업을 사용하여 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 data
rm -rf /opt/apigee/data/apigee-cassandra

노드에 이전 Cassandra 소프트웨어를 설치하고 구성합니다.

프라이빗 클라우드용 Edge 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 노드에서 한 번에 하나씩 단계를 반복합니다.

모든 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단계를 따라 리더 노드를 롤백합니다.
모든 노드가 롤백된 후 클러스터 상태를 확인하고 클러스터에 리더 노드가 있는지 확인합니다.

백업 복원

백업에서 복원을 참고하세요. 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 노드가 실행 중인지 확인합니다.
```
/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 new_standby_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
```
이전 대기 노드를 다시 빌드합니다.
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 파일을 확인하여 새 대기 모드 노드가 추가되었는지 확인합니다.

관리 서버에서 다음 명령어를 실행하여 현재 분석 및 소비자 그룹 정보를 확인합니다.

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"
```
참고: edge-postgres-server 서비스가 실행 중이어야 합니다. Postgres 서버가 실행되고 있지 않으면 관리 서버에서 다음 명령어를 실행하여 UUID를 확인할 수 있습니다.
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
이 명령어의 출력에는 각 Postgres 노드의 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 마스터 및 대기 노드를 등록합니다.

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 관리 서버를 다시 시작합니다.

/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 버전의 백업을 사용합니다. 이 백업은 업그레이드를 시도하기 전에 생성된 것이어야 합니다. 업그레이드 후에 생성된 백업은 호환되지 않으며 사용할 수 없습니다.
관리 API 다운타임: LDAP 롤백 중에 관리 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 서버에서 한 번에 하나의 노드에 대해 이 작업을 실행해야 합니다.
```
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 서버에서 새로 설치된 서비스를 한 번에 하나씩 중지하고 데이터 디렉터리를 정리하여 백업에서 복원할 준비를 합니다.
```
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 서버 시작하기
다중 서버 설정이 있는 경우 각 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를 다운로드하세요.

롤백할 구성요소를 중지합니다.

노드에서 공통 코드가 있는 구성요소를 롤백하려면 다음 예와 같이 모든 구성요소를 중지해야 합니다.

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

수익 창출을 롤백하는 경우 모든 관리 서버 및 메시지 프로세서 노드에서 수익 창출을 제거합니다.
```
/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. 노드에서 다른 구성요소를 롤백하려면 다음 예와 같이 해당 구성요소만 제거합니다.
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  여기서 component은 구성요소 이름입니다.
3. Edge 라우터를 롤백하려면 edge-gateway 구성요소 그룹을 제거하는 것 외에도 /opt/nginx/conf.d 파일의 내용을 삭제해야 합니다.
```
cd /opt/nginx/conf.d
rm -rf *
```

apigee-setup 4.53.01 버전을 제거합니다.

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

apigee-service 유틸리티 버전 4.52.02와 종속 항목을 설치합니다. 다음 예에서는 apigee-service의 4.52.02 버전을 설치합니다.
```
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