9.5. 시스템 데이터베이스 복원

중요

system-app 과 같은 Pod를 축소하거나 경로를 비활성화하여 레코드 생성을 방지합니다.

다음 절차에 따라 OpenShift 시크릿 및 시스템 데이터베이스를 복원하십시오.

9.5.1. 템플릿 기반 배포 복원

다음 단계를 사용하여 템플릿 기반 배포를 복원합니다.

절차

  1. 템플릿을 배포하기 전에 시크릿을 복원합니다. 
oc apply -f system-smtp.json

  1. 템플릿 매개변수는 복사된 보안 및 구성 맵에서 읽습니다. 

    oc new-app --file /opt/amp/templates/amp.yml \
    --param APP_LABEL=$(cat system-environment.json | jq -r '.metadata.labels.app') \
    --param TENANT_NAME=$(cat system-seed.json | jq -r '.data.TENANT_NAME' | base64 -d) \
    --param SYSTEM_DATABASE_USER=$(cat system-database.json | jq -r '.data.DB_USER' | base64 -d) \
    --param SYSTEM_DATABASE_PASSWORD=$(cat system-database.json | jq -r '.data.DB_PASSWORD' | base64 -d) \
    --param SYSTEM_DATABASE=$(cat system-database.json | jq -r '.data.URL' | base64 -d | cut -d '/' -f4) \
    --param SYSTEM_DATABASE_ROOT_PASSWORD=$(cat system-database.json | jq -r '.data.URL' | base64 -d | awk -F '[:@]' '{print $3}') \
    --param WILDCARD_DOMAIN=$(cat system-environment.json | jq -r '.data.THREESCALE_SUPERDOMAIN') \
    --param SYSTEM_BACKEND_USERNAME=$(cat backend-internal-api.json | jq '.data.username' -r | base64 -d) \
    --param SYSTEM_BACKEND_PASSWORD=$(cat backend-internal-api.json | jq '.data.password' -r | base64 -d) \
    --param SYSTEM_BACKEND_SHARED_SECRET=$(cat system-events-hook.json | jq -r '.data.PASSWORD' | base64 -d) \
    --param SYSTEM_APP_SECRET_KEY_BASE=$(cat system-app.json | jq -r '.data.SECRET_KEY_BASE' | base64 -d) \
    --param ADMIN_PASSWORD=$(cat system-seed.json | jq -r '.data.ADMIN_PASSWORD' | base64 -d) \
    --param ADMIN_USERNAME=$(cat system-seed.json | jq -r '.data.ADMIN_USER' | base64 -d) \
    --param ADMIN_EMAIL=$(cat system-seed.json | jq -r '.data.ADMIN_EMAIL' | base64 -d) \
    --param ADMIN_ACCESS_TOKEN=$(cat system-seed.json | jq -r '.data.ADMIN_ACCESS_TOKEN' | base64 -d) \
    --param MASTER_NAME=$(cat system-seed.json | jq -r '.data.MASTER_DOMAIN' | base64 -d) \
    --param MASTER_USER=$(cat system-seed.json | jq -r '.data.MASTER_USER' | base64 -d) \
    --param MASTER_PASSWORD=$(cat system-seed.json | jq -r '.data.MASTER_PASSWORD' | base64 -d) \
    --param MASTER_ACCESS_TOKEN=$(cat system-seed.json | jq -r '.data.MASTER_ACCESS_TOKEN' | base64 -d) \
    --param RECAPTCHA_PUBLIC_KEY="$(cat system-recaptcha.json | jq -r '.data.PUBLIC_KEY' | base64 -d)" \
    --param RECAPTCHA_PRIVATE_KEY="$(cat system-recaptcha.json | jq -r '.data.PRIVATE_KEY' | base64 -d)" \
    --param SYSTEM_REDIS_URL=$(cat system-redis.json | jq -r '.data.URL' | base64 -d) \
    --param SYSTEM_MESSAGE_BUS_REDIS_URL="$(cat system-redis.json | jq -r '.data.MESSAGE_BUS_URL' | base64 -d)" \
    --param SYSTEM_REDIS_NAMESPACE="$(cat system-redis.json | jq -r '.data.NAMESPACE' | base64 -d)" \
    --param SYSTEM_MESSAGE_BUS_REDIS_NAMESPACE="$(cat system-redis.json | jq -r '.data.MESSAGE_BUS_NAMESPACE' | base64 -d)" \
    --param ZYNC_DATABASE_PASSWORD=$(cat zync.json | jq -r '.data.ZYNC_DATABASE_PASSWORD' | base64 -d) \
    --param ZYNC_SECRET_KEY_BASE=$(cat zync.json | jq -r '.data.SECRET_KEY_BASE' | base64 -d) \
    --param ZYNC_AUTHENTICATION_TOKEN=$(cat zync.json | jq -r '.data.ZYNC_AUTHENTICATION_TOKEN' | base64 -d) \
    --param APICAST_ACCESS_TOKEN=$(cat system-master-apicast.json | jq -r '.data.ACCESS_TOKEN' | base64 -d) \
    --param APICAST_MANAGEMENT_API=$(cat apicast-environment.json | jq -r '.data.APICAST_MANAGEMENT_API') \
    --param APICAST_OPENSSL_VERIFY=$(cat apicast-environment.json | jq -r '.data.OPENSSL_VERIFY') \
    --param APICAST_RESPONSE_CODES=$(cat apicast-environment.json | jq -r '.data.APICAST_RESPONSE_CODES') \
    --param APICAST_REGISTRY_URL=$(cat system-environment.json | jq -r '.data.APICAST_REGISTRY_URL')

9.5.2. Operator 기반 배포 복원

다음 단계를 사용하여 운영자 기반 배포를 복원합니다.

절차

  1. OpenShift에 3scale Operator를 설치합니다.

  2. APIManager 리소스를 생성하기 전에 보안을 복원합니다. 

    oc apply -f system-smtp.json
oc apply -f system-seed.json
oc apply -f system-database.json
oc apply -f backend-internal-api.json
oc apply -f system-events-hook.json
oc apply -f system-app.json
oc apply -f system-recaptcha.json
oc apply -f system-redis.json
oc apply -f zync.json
oc apply -f system-master-apicast.json

  3. APIManager 리소스를 생성하기 전에 ConfigMap을 복원합니다. 

    oc apply -f system-environment.json
oc apply -f apicast-environment.json
  4. APIManager 사용자 지정 리소스를 사용하여 Operator를 사용하여 3scale 을 배포합니다.

9.5.3. system-mysql복원

절차

  1. MySQL 덤프를 system-mysql 포드에 복사합니다. 

    oc cp ./system-mysql-backup.gz $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq '.items[0].metadata.name' -r):/var/lib/mysql

  2. 백업 파일 압축을 풉니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/system-mysql-backup.gz'

  3. MySQL DB 백업 파일을 복원합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-mysql' -o json | jq -r '.items[0].metadata.name') bash -c 'export MYSQL_PWD=${MYSQL_ROOT_PASSWORD}; mysql -hsystem-mysql -uroot system < ${HOME}/system-mysql-backup'

9.5.4. system-storage복원

Backup 파일을 system-storage에 복원합니다. 

oc rsync ./local/dir/system/ $(oc get pods -l 'deploymentConfig=system-app' -o json | jq '.items[0].metadata.name' -r):/opt/system/public/system

9.5.5. zync-database복원

zync-database 를 복원하는 지침은 3scale에 적용된 배포 유형에 따라 다릅니다.

9.5.5.1. 템플릿 기반 배포

절차

  1. zync DeploymentConfig를 0 Pod로 축소합니다. 

    oc scale dc zync --replicas=0
oc scale dc zync-que --replicas=0

  2. Zync 데이터베이스 덤프를 zync-database Pod에 복사합니다. 

    oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/

  3. 백업 파일 압축을 풉니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/zync-database-backup.gz'

  4. PostgreSQL DB 백업 파일을 복원합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'psql -f ${HOME}/zync-database-backup'

  5. 아래 명령에서 ${ZYNC_REPLICAS} 를 복제본 수로 교체하여 원래 복제본 수로 복원합니다. 

    oc scale dc zync --replicas=${ZYNC_REPLICAS}
oc scale dc zync-que --replicas=${ZYNC_REPLICAS}

9.5.5.2. Operator 기반 배포

참고

Operator를 사용하여 3scale 배포( 특히 APIManager 사용자 정의 리소스 배포)의 지침에 따라 3scale 인스턴스를 재배포합니다.

절차

  1. ${DEPLOYMENT_NAME} 을 3scale 배포를 만들 때 정의한 이름으로 대체하여 복제본 수를 저장합니다. 

    ZYNC_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o json | jq -r '.spec.zync'`

  2. zync DeploymentConfig를 0 Pod로 축소합니다. 

    oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync": {"appSpec": {"replicas": 0}, "queSpec": {"replicas": 0}}}}'

  3. Zync 데이터베이스 덤프를 zync-database Pod에 복사합니다. 

    oc cp ./zync-database-backup.gz $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq '.items[0].metadata.name' -r):/var/lib/pgsql/

  4. 백업 파일 압축을 풉니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'gzip -d ${HOME}/zync-database-backup.gz'

  5. PostgreSQL DB 백업 파일을 복원합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=zync-database' -o json | jq -r '.items[0].metadata.name') bash -c 'psql -f ${HOME}/zync-database-backup'

  6. 원래 복제본 수로 복원합니다. 

    oc patch APIManager ${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync":'"${ZYNC_SPEC}"'}}'

9.5.5.3. backend-redis 및 system-redis 를 사용하여 3scale 옵션 복원

3scale을 복원하면 backend-redis 및 system-redis 를 복원합니다. 이러한 구성 요소에는 다음과 같은 기능이 있습니다.

*backend-redis: 애플리케이션 인증 및 속도 제한을 3scale로 지원하는 데이터베이스입니다. 또한 통계 저장소 및 임시 작업 저장소에 사용됩니다. *system-redis: 3scale의 백그라운드 작업에 대한 임시 스토리지를 제공하며 system-app 포드의 Ruby 프로세스의 메시지 버스로도 사용됩니다.

backend-redis 구성 요소

backend-redis 구성 요소에는 두 개의 데이터베이스, 데이터 및 큐 가 있습니다. 기본 3scale 배포에서는 데이터 및 큐 가 Redis 데이터베이스에 배포되지만 논리적 데이터베이스 인덱스 /0 및 / 1 에 분산됩니다. 데이터 데이터베이스를 복원하면 문제 없이 실행되지만 대기열 데이터베이스를 복원하면 중복된 작업이 발생할 수 있습니다.

작업 복제와 관련하여 3scale에서 백엔드 작업자는 백그라운드 작업을 밀리초 단위로 처리합니다. 마지막 데이터베이스 스냅샷 후 30초 후에 backend-redis 가 실패하고 복원하려고 하면 백엔드에 중복을 방지하기 위한 시스템이 없으므로 30초 동안 발생한 백그라운드 작업이 두 번 수행됩니다.

이 시나리오에서는 /0 데이터베이스 인덱스에 다른 곳에 저장되지 않는 데이터가 포함되어 있으므로 백업을 복원해야 합니다. /0 데이터베이스 인덱스를 복원하면 /1 데이터베이스 인덱스도 복원해야 합니다. 이는 다른 데이터베이스 없이는 저장할 수 없기 때문입니다. 다른 색인에서 하나의 데이터베이스가 아닌 다른 서버에서 데이터베이스를 분리하면 대기열 크기가 약 0이 되므로 백업을 복원하지 않고 몇 가지 백그라운드 작업이 손실되지 않는 것이 좋습니다. 따라서 3scale Hosted 설정에서 서로 다른 백업 및 복원 전략을 적용해야 합니다.

'system-redis'component

대부분의 3scale 시스템 백그라운드 작업은 멱등입니다. 즉, 동일한 요청이 몇 번 실행해도 동일한 결과를 반환합니다.

다음은 시스템의 백그라운드 작업에서 처리하는 이벤트의 예입니다.

  • 계획 시험, 만료 예정인 신용 카드, 활성화 알림, 계획 변경, 송장 상태 변경, PDF 보고서 등의 알림 작업.
  • 송장 및 청구와 같은 청구.
  • 복잡한 오브젝트 삭제.
  • 백엔드 동기화 작업.
  • 색인화 작업(예: sphinx 포함).
  • Sanitisation 작업(예: 송장 ID).
  • 감사 제거, 사용자 세션, 만료된 토큰, 로그 항목, 비활성 계정 일시 중단 등의 재작성 작업.
  • 트래픽 업데이트.
  • 프록시 구성 변경 모니터링 및 프록시 배포.
  • 배경 등록 작업
  • SSO(Single Sign-On) 동기화와 같은 지연된 작업, 경로 생성.

위의 백그라운드 작업 목록을 복원하는 경우 3scale의 시스템은 복원된 각 작업의 상태를 유지합니다. 복원이 완료된 후 시스템의 무결성을 확인하는 것이 중요합니다.

9.5.6. 백엔드와 시스템간의 정보 일관성 보장

백엔드를 복원한 후 시스템에서 Config 정보를 동기화 한 후 백엔드 의 정보가 신뢰의 소스 인 System 과 일치하는지 확인해야 합니다.

9.5.6.1. backend-redis의 배포 구성 관리

이러한 단계는 backend-redis 의 인스턴스를 실행하기 위한 것입니다.

절차

  1. redis-config configmap을 편집합니다. 

    oc edit configmap redis-config

  2. redis-config configmap에서 SAVE 명령을 주석 처리하십시오. 

     #save 900 1
 #save 300 10
 #save 60 10000

  3. redis-config configmap에서 appendonly 를 no 로 설정합니다. 

    appendonly no

  4. backend-redis 를 재배포하여 새 구성을 로드합니다. 

    oc rollout latest dc/backend-redis

  5. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/backend-redis

  6. dump.rdb 파일의 이름을 변경합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/dump.rdb ${HOME}/data/dump.rdb-old'

  7. appendonly.aof 파일의 이름을 바꿉니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/appendonly.aof ${HOME}/data/appendonly.aof-old'

  8. 백업 파일을 POD로 이동합니다. 

    oc cp ./backend-redis-dump.rdb $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb

  9. backend-redis 를 재배포하여 백업을 로드합니다. 

    oc rollout latest dc/backend-redis

  10. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/backend-redis

  11. 추가 전용 파일을 만듭니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'

  12. 잠시 후에 AOF 재작성이 완료되었는지 확인합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli info' | grep aof_rewrite_in_progress
    • aof_rewrite_in_progress = 1 동안 실행이 진행 중입니다.
    • aof_rewrite_in_progress = 0 이 될 때까지 주기적으로 확인합니다. 0은 실행이 완료되었음을 나타냅니다.

  13. redis-config configmap을 편집합니다. 

    oc edit configmap redis-config

  14. redis-config configmap의 SAVE 명령 주석을 제거하십시오. 

     save 900 1
 save 300 10
 save 60 10000

  15. redis-config configmap에서 appendonly 를 yes 로 설정합니다. 

    appendonly yes

  16. 기본 구성을 다시 로드하려면 backend-redis 를 다시 배포합니다. 

    oc rollout latest dc/backend-redis

  17. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/backend-redis

9.5.6.2. system-redis의 배포 구성 관리

이러한 단계는 system-redis 의 인스턴스를 실행하기 위한 것입니다.

절차

  1. redis-config configmap을 편집합니다. 

    oc edit configmap redis-config

  2. redis-config configmap에서 SAVE 명령을 주석 처리하십시오. 

     #save 900 1
 #save 300 10
 #save 60 10000

  3. redis-config configmap에서 appendonly 를 no 로 설정합니다. 

    appendonly no

  4. system-redis 를 재배포하여 새 구성을 로드합니다. 

    oc rollout latest dc/system-redis

  5. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/system-redis

  6. dump.rdb 파일의 이름을 변경합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/dump.rdb ${HOME}/data/dump.rdb-old'

  7. appendonly.aof 파일의 이름을 바꿉니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'mv ${HOME}/data/appendonly.aof ${HOME}/data/appendonly.aof-old'

  8. Backup 파일을 POD로 이동합니다. 

    oc cp ./system-redis-dump.rdb $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r):/var/lib/redis/data/dump.rdb

  9. system-redis 를 재배포하여 백업을 로드합니다. 

    oc rollout latest dc/system-redis

  10. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/system-redis

  11. 추가 전용 파일을 만듭니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'

  12. 잠시 후에 AOF 재작성이 완료되었는지 확인합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli info' | grep aof_rewrite_in_progress
    • aof_rewrite_in_progress = 1 동안 실행이 진행 중입니다.
    • aof_rewrite_in_progress = 0 이 될 때까지 주기적으로 확인합니다. 0은 실행이 완료되었음을 나타냅니다.

  13. redis-config configmap을 편집합니다. 

    oc edit configmap redis-config

  14. redis-config configmap의 SAVE 명령 주석을 제거하십시오. 

     save 900 1
 save 300 10
 save 60 10000

  15. redis-config configmap에서 appendonly 를 yes 로 설정합니다. 

    appendonly yes

  16. system-redis 를 재배포하여 기본 구성을 다시 로드합니다. 

    oc rollout latest dc/system-redis

  17. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/system-redis

9.5.7. backend-worker복원

최신 버전의 backend-worker 로 복원 : 

oc rollout latest dc/backend-worker

  1. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/backend-worker

9.5.8. system-app복원

system-app 의 최신 버전으로 복원 : 

oc rollout latest dc/system-app

  1. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/system-app

9.5.9. system-sidekiq복원

  1. 최신 버전의 system-sidekiq 로 복원 : 

    oc rollout latest dc/system-sidekiq

  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/system-sidekiq

9.5.9.1. system-sphinx복원

  1. system-sphinx 의 최신 버전으로 복원 : 

    oc rollout latest dc/system-sphinx

  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다. 

    oc rollout status dc/system-sphinx

9.5.9.2. Zync에서 관리하는 OpenShift 경로 복원

  1. Zync가 누락된 OpenShift 경로를 다시 생성하도록 강제 적용합니다. 

    oc rsh $(oc get pods -l 'deploymentConfig=system-sidekiq' -o json | jq '.items[0].metadata.name' -r) bash -c 'bundle exec rake zync:resync:domains'