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

중요

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

다음 명령 및 스니펫 예제에서 ${DEPLOYMENT_NAME} 을 3scale 배포를 생성할 때 정의한 이름으로 교체합니다.

참고

출력에 중괄호 한 쌍 이상이 포함되어 있고 비어 있지 않은지 확인합니다.

절차

나중에 확장할 현재 복제본 수를 저장합니다.

SYSTEM_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o jsonpath='{.spec.system.appSpec}'`

이전 명령의 결과를 확인하고 $SYSTEM_SPEC:의 내용을 확인합니다.
```
echo $SYSTEM_SPEC
```
복제본 수를 0 으로 스케일링하는 다음 명령을 사용하여 APIManager CR을 패치합니다.
```
$ oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"system": {"appSpec": {"replicas": 0}}}}'
```
또는 system-app 을 축소하려면 기존 APIManager/${DEPLOMENT_NAME} 을 편집하고 다음 예와 같이 시스템 복제본 수를 0으로 설정합니다.
```
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: <DEPLOYMENT_NAME>
spec:
  system:
    appSpec:
       replicas: 0
```

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

9.5.1. 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 CR 을 사용하여 Operator와 함께 3scale 을 배포합니다.

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

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

9.5.4. zync-database 복원

3scale Operator 배포를 위해 zync-database 를 복원하는 지침입니다.

9.5.4.1. Operator 기반 배포

참고

Operator를 사용하여 3scale 배포 (특히 APIManager CR 배포)의 지침에 따라 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'

zync 데이터베이스 백업 파일을 복원합니다.

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

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

$ oc patch APIManager/${DEPLOYMENT_NAME} --type json -p '[{"op": "replace", "path": "/spec/zync", "value":'"$ZYNC_SPEC"'}]'

다음 명령의 출력에 replicas 키가 포함되어 있지 않은 경우:
```
$ echo $ZYNC_SPEC
```
그런 다음 다음 추가 명령을 실행하여 zync 를 확장합니다.
```
$ oc patch dc/zync -p '{"spec": {"replicas": 1}}'
```

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

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

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

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

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

절차

redis-config configmap을 편집합니다.
```
$ oc edit configmap redis-config
```
redis-config configmap에서 192.0.2. 명령을 주석 처리하십시오.
```
 #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
```

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-config configmap을 편집합니다.
```
$ oc edit configmap redis-config
```
redis-config configmap에서 192.0.2. 명령 주석 처리를 해제합니다.
```
 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
```

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

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

절차

redis-config configmap을 편집합니다.
```
$ oc edit configmap redis-config
```
redis-config configmap에서 192.0.2. 명령을 주석 처리하십시오.
```
 #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'

백업 파일을 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-config configmap을 편집합니다.
```
$ oc edit configmap redis-config
```
redis-config configmap에서 192.0.2. 명령 주석 처리를 해제합니다.
```
 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
```

9.5.6. 백엔드 작업자 복원

이러한 단계는 backend-worker 를 복원하기 위한 것입니다.

절차

backend-worker 의 최신 버전으로 복원 :
```
$ oc rollout latest dc/backend-worker
```
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
```
$ oc rollout status dc/backend-worker
```

9.5.7. system-app 복원

이 단계는 system-app 을 복원하기 위한 것입니다.

절차

system-app 을 확장하려면 기존 APIManager/${DEPLOYMENT_NAME} 을 편집하고 .spec.system.appSpec.replicas 를 원래 복제본 수로 다시 변경하거나 다음 명령을 실행하여 이전에 저장된 사양을 적용합니다.
```
$ oc patch APIManager/${DEPLOYMENT_NAME} --type json -p '[{"op": "replace", "path": "/spec/system/appSpec", "value":'"$SYSTEM_SPEC"'}]'
```
- 다음 명령의 출력에 replicas 키가 포함되어 있지 않은 경우:
```
$ echo $SYSTEM_SPEC
```
- 그런 다음 다음 추가 명령을 실행하여 system-app 을 확장합니다.
```
$ oc patch dc/system-app -p '{"spec": {"replicas": 1}}'
```
최신 버전의 system-app 으로 복원 :
```
$ oc rollout latest dc/system-app
```
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
```
$ oc rollout status dc/system-app
```

9.5.8. system-sidekiq 복원

이러한 단계는 system-sidekiq 를 복원하기 위한 것입니다.

절차

최신 버전의 system-sidekiq 로 복원하십시오.
```
$ oc rollout latest dc/system-sidekiq
```
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
```
$ oc rollout status dc/system-sidekiq
```

9.5.8.1. system-sphinx 복원

이러한 단계는 system-sphinx 를 복원하기 위한 것입니다.

절차

최신 버전의 system-sphinx 로 복원 :
```
$ oc rollout latest dc/system-sphinx
```
롤아웃 상태를 확인하여 완료되었는지 확인합니다.
```
$ oc rollout status dc/system-sphinx
```

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