8.5. 시스템 데이터베이스 복원
system-app
과 같은 Pod를 축소하거나 경로를 비활성화하여 레코드 생성을 방지합니다.
다음 절차에 따라 OpenShift 시크릿 및 시스템 데이터베이스를 복원하십시오.
8.5.1. 템플릿 기반 배포 복원
다음 단계를 사용하여 템플릿 기반 배포를 복원합니다.
절차
- 템플릿을 배포하기 전에 시크릿을 복원합니다.
oc apply -f system-smtp.json
템플릿 매개변수는 복사된 보안 및 구성 맵에서 읽습니다.
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 기반 배포 복원
다음 단계를 사용하여 운영자 기반 배포를 복원합니다.
절차
- OpenShift에 3scale Operator를 설치합니다.
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
APIManager 리소스를 생성하기 전에 ConfigMap을 복원합니다.
oc apply -f system-environment.json oc apply -f apicast-environment.json
- APIManager 사용자 지정 리소스를 사용하여 Operator를 사용하여 3scale 을 배포합니다.
8.5.3. system-mysql
복원
절차
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
백업 파일 압축을 풉니다.
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'
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. 템플릿 기반 배포
절차
zync DeploymentConfig를 0 Pod로 축소합니다.
oc scale dc zync --replicas=0 oc scale dc zync-que --replicas=0
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/
백업 파일 압축을 풉니다.
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'
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'
아래 명령에서
${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 인스턴스를 재배포합니다.
절차
${DEPLOYMENT_NAME}
을 3scale 배포를 생성할 때 정의한 이름으로 교체하여 복제본 수를 저장합니다.ZYNC_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o json | jq -r '.spec.zync'`
zync DeploymentConfig를 0 Pod로 축소합니다.
oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync": {"appSpec": {"replicas": 0}, "queSpec": {"replicas": 0}}}}'
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/
백업 파일 압축을 풉니다.
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'
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'
복제본의 원래 수로 복원하십시오.
oc patch APIManager ${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync":'"${ZYNC_SPEC}"'}}'
8.5.5.3. backend-redis 및 system-redis
를 사용하여 3scale 옵션 복원
system-redis
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의 시스템은 복원된 각 작업의 상태를 유지합니다. 복원이 완료된 후 시스템의 무결성을 확인하는 것이 중요합니다.
8.5.6. 백엔드와 시스템
간의 정보
일관성 보장
시스템
간의 정보
백엔드를 복원한 후 시스템에서 Config 정보를 동기화
한 후 백엔드
의 정보가 신뢰의 소스 인 System
과 일치하는지 확인해야 합니다
.
8.5.6.1. backend-redis
의 배포 구성 관리
이러한 단계는 backend-redis
의 인스턴스를 실행하기 위한 것입니다.
절차
redis-config
configmap을 편집합니다.oc edit configmap redis-config
redis-config
configmap에서SAVE
명령을 주석 처리하십시오.#save 900 1 #save 300 10 #save 60 10000
redis-config
configmap에서appendonly
를 no 로 설정합니다.appendonly no
backend-redis
를 재배포하여 새 구성을 로드합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
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'
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'
백업 파일을 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
backend-redis
를 재배포하여 백업을 로드합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
추가 전용
파일을 만듭니다.oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
잠시 후에 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은 실행이 완료되었음을 나타냅니다.
-
redis-config
configmap을 편집합니다.oc edit configmap redis-config
redis-config
configmap의SAVE
명령 주석을 제거하십시오.save 900 1 save 300 10 save 60 10000
redis-config
configmap에서appendonly
를 yes 로 설정합니다.appendonly yes
기본 구성을 다시 로드하려면
backend-redis
를 다시 배포합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
8.5.6.2. system-redis
의 배포 구성 관리
이러한 단계는 system-redis
의 인스턴스를 실행하기 위한 것입니다.
절차
redis-config
configmap을 편집합니다.oc edit configmap redis-config
redis-config
configmap에서SAVE
명령을 주석 처리하십시오.#save 900 1 #save 300 10 #save 60 10000
redis-config
configmap에서appendonly
를 no 로 설정합니다.appendonly no
system-redis
를 재배포하여 새 구성을 로드합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
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'
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'
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
system-redis
를 재배포하여 백업을 로드합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
추가 전용
파일을 만듭니다.oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
잠시 후에 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은 실행이 완료되었음을 나타냅니다.
-
redis-config
configmap을 편집합니다.oc edit configmap redis-config
redis-config
configmap의SAVE
명령 주석을 제거하십시오.save 900 1 save 300 10 save 60 10000
redis-config
configmap에서appendonly
를 yes 로 설정합니다.appendonly yes
system-redis
를 재배포하여 기본 구성을 다시 로드합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
8.5.7. backend-worker
복원
최신 버전의 backend-worker
로 복원 :
oc rollout latest dc/backend-worker
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-worker
8.5.8. system-app
복원
system-app
의 최신 버전으로 복원 :
oc rollout latest dc/system-app
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-app
8.5.9. system-sidekiq
복원
최신 버전의
system-sidekiq
로 복원 :oc rollout latest dc/system-sidekiq
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-sidekiq
8.5.9.1. system-sphinx
복원
system-sphinx
의 최신 버전으로 복원 :oc rollout latest dc/system-sphinx
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-sphinx
8.5.9.2. Zync에서 관리하는 OpenShift 경로 복원
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'