7.5. 恢复系统数据库
通过缩减 pod(如 system-app
或禁用路由)来阻止记录创建。
使用以下步骤恢复 OpenShift secret 和系统数据库:
7.5.1. 恢复基于模板的部署
使用以下步骤恢复基于模板的部署。
步骤
- 在创建部署模板前恢复 secret:
oc apply -f system-smtp.json
模板参数将从复制的 secret 和 configmap 中读取:
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')
7.5.2. 恢复基于 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 自定义资源部署使用 Operator 的 3scale。
7.5.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 备份文件:
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'
7.5.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
7.5.5. 恢复 zync-database
恢复 zync-database
的具体方法取决于为 3scale 应用的部署类型。
7.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}
7.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}"'}}'
7.5.5.3. 使用 backend-redis 和 system-redis
恢复 3scale 选项
system-redis
通过恢复 3scale,您将恢复 backend-redis
和 system-redis
。这些组件具有以下功能:
*backend-redis
:在 3scale 中支持应用身份验证和速率限制的数据库。它还可用于统计存储和临时作业存储。*system-redis
:为 3scale 的后台作业提供临时存储,也用作 system-app
pod Ruby 流程的消息总线。
backend-redis
组件
backend-redis
组件有两个数据库,即 数据和
队列
。在默认的 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 的系统会维护每个恢复的作业的状态。在恢复完成后检查系统的完整性非常重要。
7.5.6. 确保 后端和系统
之间的信息一致性
恢复 backend-redis
后,应强制同步 系统的
配置信息,以确保 后端
中的信息与 系统中
的信息一致,这是事实的来源。
7.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
。零表示执行已经完成。
-
编辑
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
7.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'
将
备份
文件移到 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
7.5.7. 恢复 backend-worker
恢复到 backend-worker
的最新版本:
oc rollout latest dc/backend-worker
检查推出部署的状态,以确保它已完成:
oc rollout status dc/backend-worker
7.5.8. 恢复 system-app
恢复到最新版本的 system-app
:
oc rollout latest dc/system-app
检查推出部署的状态,以确保它已完成:
oc rollout status dc/system-app
7.5.9. 恢复 system-sidekiq
恢复到
system-sidekiq
的最新版本:oc rollout latest dc/system-sidekiq
检查推出部署的状态,以确保它已完成:
oc rollout status dc/system-sidekiq
7.5.9.1. 恢复 system-sphinx
恢复到最新版本的
system-sphinx
:oc rollout latest dc/system-sphinx
检查推出部署的状态,以确保它已完成:
oc rollout status dc/system-sphinx
7.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'