6.6. 데이터베이스를 복원하는 절차

다음 명령을 사용하여 시스템 오류가 발생한 후 시스템 데이터베이스를 복원할 수 있습니다.

중요

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

6.6.1. 템플릿 기반 배포 복원

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

절차

  1. 템플릿을 배포하기 전에 ConfigMap을 복원합니다.

    oc apply -f smtp.json
  2. 템플릿 매개변수는 복사된 보안 및 configmaps에서 읽습니다.

    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')

6.6.2. Operator 기반 배포 복원

다음 단계를 사용하여 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 을 배포합니다.

6.6.3. system-mysql복원

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

    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 Backup 파일을 복원합니다.

    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'

6.6.4. system-storage복원

백업 파일을 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

6.6.5. zync-database복원

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

템플릿 기반 배포

  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}
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}"'}}'

6.6.6. backend-redissystem-redis를 사용하여 3scale 옵션 복원

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

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

backend-redis 구성 요소

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

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

이 시나리오에서는 /0 데이터베이스 인덱스에 다른 위치에 저장되지 않은 데이터가 포함되어 있으므로 백업을 복원해야 합니다. /0 데이터베이스 인덱스를 복원하면 다른 인덱스 없이 저장할 수 없으므로 /1 데이터베이스 인덱스도 복원해야 합니다.

서로 다른 인덱스에서 하나의 데이터베이스가 아닌 다른 서버에서 데이터베이스를 분리하도록 선택하면 큐의 크기가 약 0이므로 백업을 복원하지 않고 몇 가지 백그라운드 작업이 손실되는 것이 좋습니다. 이는 3scale Hosted 설정의 경우 둘 다에 대해 다른 백업 및 복원 전략을 적용해야 합니다.

'system-redis' 구성 요소

3scale 시스템 백그라운드 작업의 대부분은 멱등입니다. 즉, 동일한 요청은 실행하는 횟수에 관계없이 동일한 결과를 반환합니다.

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

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

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

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

backend-redis 를 복원한 후 시스템에서 구성 정보를 동기화해야 합니다. 백엔드 의 정보가 정보 소스인 시스템 내의 정보와 일치하도록 해야 합니다.

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

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

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

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

     #save 900 1
     #save 300 10
     #save 60 10000
  3. redis-config configmap에서 appendonlyno 로 설정합니다.

    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. appendonly 파일을 생성합니다.

    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에서 192.0.2. 명령 주석 처리를 해제합니다.

     save 900 1
     save 300 10
     save 60 10000
  15. redis-config configmap에서 appendonlyyes 로 설정합니다.

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

    oc rollout latest dc/backend-redis
  17. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/backend-redis

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

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

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

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

     #save 900 1
     #save 300 10
     #save 60 10000
  3. redis-config configmap에서 appendonlyno 로 설정합니다.

    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. 백업 파일을 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. appendonly 파일을 생성합니다.

    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에서 192.0.2. 명령 주석 처리를 해제합니다.

     save 900 1
     save 300 10
     save 60 10000
  15. redis-config configmap에서 appendonlyyes 로 설정합니다.

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

    oc rollout latest dc/system-redis
  17. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-redis

6.6.8. 백엔드 작업자복원

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

    oc rollout latest dc/backend-worker
  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/backend-worker

6.6.9. system-app복원

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

    oc rollout latest dc/system-app
  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-app

6.6.10. system-sidekiq복원

  1. 최신 버전의 system-sidekiq 로 복원하십시오.

    oc rollout latest dc/system-sidekiq
  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-sidekiq

6.6.11. system-sphinx복원

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

    oc rollout latest dc/system-sphinx
  2. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    oc rollout status dc/system-sphinx

6.6.12. 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'