6.6. 데이터베이스를 복원하는 절차
다음 명령을 사용하여 시스템 오류가 발생한 후 시스템 데이터베이스를 복원할 수 있습니다.
system-app 과 같은 Pod를 축소하거나 경로를 비활성화하여 레코드 생성을 방지합니다.
6.6.1. 템플릿 기반 배포 복원
다음 단계를 사용하여 템플릿 기반 배포를 복원합니다.
절차
템플릿을 배포하기 전에 ConfigMap을 복원합니다.
oc apply -f smtp.json
템플릿 매개변수는 복사된 보안 및 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 기반 배포를 복원합니다.
절차
- 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 을 배포합니다.
6.6.3. system-mysql복원
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
백업 파일의 압축을 풉니다.
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 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에 적용된 배포 유형에 따라 다릅니다.
템플릿 기반 배포
zync DeploymentConfig를 0 Pod로 축소합니다.
oc scale dc zync --replicas=0 oc scale dc zync-que --replicas=0
Zync 데이터베이스 덤프를
zync-databasePod에 복사합니다.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}
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-databasePod에 복사합니다.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}"'}}'
6.6.6. backend-redis 및 system-redis를 사용하여 3scale 옵션 복원
3scale을 복원하면 backend-redis 및 system-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 의 인스턴스를 실행하기 위한 것입니다.
redis-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령을 주석 처리하십시오.#save 900 1 #save 300 10 #save 60 10000
redis-configconfigmap에서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
appendonly파일을 생성합니다.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-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령 주석 처리를 해제합니다.save 900 1 save 300 10 save 60 10000
redis-configconfigmap에서appendonly를 yes 로 설정합니다.appendonly yes
backend-redis를 다시 배포하여 기본 구성을 다시 로드합니다.oc rollout latest dc/backend-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-redis
6.6.7.2. system-redis의 배포 구성 관리
이러한 단계는 system-redis 의 인스턴스를 실행하기 위한 것입니다.
redis-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령을 주석 처리하십시오.#save 900 1 #save 300 10 #save 60 10000
redis-configconfigmap에서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'백업파일을 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
appendonly파일을 생성합니다.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-configconfigmap을 편집합니다.oc edit configmap redis-config
redis-configconfigmap에서 192.0.2. 명령 주석 처리를 해제합니다.save 900 1 save 300 10 save 60 10000
redis-configconfigmap에서appendonly를 yes 로 설정합니다.appendonly yes
system-redis를 다시 배포하여 기본 구성을 다시 로드합니다.oc rollout latest dc/system-redis
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-redis
6.6.8. 백엔드 작업자복원
backend-worker의 최신 버전으로 복원 :oc rollout latest dc/backend-worker
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/backend-worker
6.6.9. system-app복원
최신 버전의
system-app으로 복원 :oc rollout latest dc/system-app
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-app
6.6.10. system-sidekiq복원
최신 버전의
system-sidekiq로 복원하십시오.oc rollout latest dc/system-sidekiq
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-sidekiq
6.6.11. system-sphinx복원
최신 버전의
system-sphinx로 복원 :oc rollout latest dc/system-sphinx
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-sphinx
6.6.12. 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'