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


중요

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

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

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

8.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 을 배포합니다.

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

8.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

8.5.5. zync-database복원

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

8.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}

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

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

3scale을 복원하면 backend-redissystem-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의 시스템은 복원된 각 작업의 상태를 유지합니다. 복원이 완료된 후 시스템의 무결성을 확인하는 것이 중요합니다.

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

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

8.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에서 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. 추가 전용 파일을 만듭니다.

    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에서 appendonlyyes 로 설정합니다.

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

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

    oc rollout status dc/backend-redis

8.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에서 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. 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에서 appendonlyyes 로 설정합니다.

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

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

    oc rollout status dc/system-redis

8.5.7. backend-worker복원

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

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

    oc rollout status dc/backend-worker

8.5.8. system-app복원

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

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

    oc rollout status dc/system-app

8.5.9. system-sidekiq복원

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

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

    oc rollout status dc/system-sidekiq

8.5.9.1. system-sphinx복원

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

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

    oc rollout status dc/system-sphinx

8.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'
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.