9.5. 恢复系统数据库
通过缩减 pod(如 system-app
或禁用路由)来阻止记录创建。
在下面的命令和代码片段示例中,将 ${DEPLOYMENT_NAME}
替换为您在创建 3scale 部署时定义的名称。
确保输出至少包含大括号 {}
的一对,且不为空。
流程
存储当前的副本数以便以后扩展:
SYSTEM_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o jsonpath='{.spec.system.appSpec}'`
验证上一命令的结果并检查
$SYSTEM_SPEC
的内容:echo $SYSTEM_SPEC
使用以下命令对 APIManager CR 进行补丁,将副本数扩展到
0
:$ oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"system": {"appSpec": {"replicas": 0}}}}'
另外,要缩减
system-app
,请编辑现有的APIManager/${DEPLOMENT_NAME}
,并将系统副本数设置为零,如下例所示:apiVersion: apps.3scale.net/v1alpha1 kind: APIManager metadata: name: <DEPLOYMENT_NAME> spec: system: appSpec: replicas: 0
使用以下步骤恢复 OpenShift secret 和系统数据库:
9.5.1. 恢复基于 Operator 的部署
使用以下步骤恢复基于 Operator 的部署。
流程
- 在 OpenShift 上安装 3scale operator。
在创建 APIManager 资源前恢复 secret:
$ 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 备份文件:
$ 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
组件有两个数据库,即 data
和 queues
。在默认的 3scale 部署中,数据
和队列
部署在 Redis 数据库中,但在不同的逻辑数据库索引 /0
和 /1
中。恢复 数据
数据库不会有任何问题,但恢复 队列
数据库可能会导致重复的作业。
关于作业重复,在 3scale 中,后端 worker 以毫秒为单位处理后台作业。如果 backend-redis
在最后一次数据库快照后 30 秒失败,并且您尝试恢复它,则在 30 秒内发生的后台作业会执行两次,因为后端没有系统来避免重复。
在这种情况下,您必须恢复备份,因为 /0
数据库索引包含没有在其它任何位置保存的数据。恢复 /0
数据库索引意味着您必须还原 /1
数据库索引,因为一个在没有数据库索引的情况下将无法存储。当您选择在不同的服务器中分隔数据库,而不是在不同的索引中分隔一个数据库时,队列的大小大约为零,因此最好不要恢复备份并丢失几个后台作业。在 3scale 托管设置中会出现这种情况,因此您需要为两者应用不同的备份和恢复策略。
'system-redis'component
大多数 3scale 系统后台作业是幂等的,也就是说,无论您运行它们多少次,相同的请求都会返回相同的结果。
以下是系统中由后台作业处理的事件示例:
- 通知作业,例如计划试用到期、即将到期的信用卡、激活提醒、计划更改、发票状态更改、PDF 报告.
- 例如开票和收费。
- 删除复杂对象。
- 后端同步作业。
- 索引作业,例如使用 sphinx。
- 清理工作,例如发票 ID。
- Janitorial 任务,如清除审计、用户会话、到期令牌、日志条目、暂停不活动帐户等。
- 流量更新。
- 代理配置更改监控和代理部署。
- 后台注册作业,
- Zync 作业,如单点登录(SSO)同步、路由创建。
如果您要恢复上述后台作业列表,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 中的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
。零表示执行已经完成。
-
编辑
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
9.5.5.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'
将
备份
文件移到 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
。零表示执行已经完成。
-
编辑
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
9.5.6. 恢复 backend-worker
这些步骤旨在恢复 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'