7.5. 恢复系统数据库


重要

通过缩减 pod(如 system-app 或禁用路由)来阻止记录创建。

使用以下步骤恢复 OpenShift secret 和系统数据库:

7.5.1. 恢复基于模板的部署

使用以下步骤恢复基于模板的部署。

步骤

  1. 在创建部署模板前恢复 secret:
oc apply -f system-smtp.json
  1. 模板参数将从复制的 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 的部署。

步骤

  1. OpenShift 上安装 3scale operator
  2. 在创建 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
  3. 在创建 APIManager 资源前恢复 ConfigMap:

    oc apply -f system-environment.json
    oc apply -f apicast-environment.json
  4. 使用 APIManager 自定义资源部署使用 Operator 的 3scale

7.5.3. 恢复 system-mysql

步骤

  1. 将 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
  2. 解压缩备份文件:

    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'
  3. 恢复 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. 基于模板的部署

步骤

  1. 将 zync DeploymentConfig 缩减为 0 个 pod:

    oc scale dc zync --replicas=0
    oc scale dc zync-que --replicas=0
  2. 将 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/
  3. 解压缩备份文件:

    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'
  4. 恢复 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'
  5. 在以下命令中,通过将 ${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 实例。

步骤

  1. 通过将 ${DEPLOYMENT_NAME} 替换为您在创建 3scale 部署时定义的名称来存储副本数量:

    ZYNC_SPEC=`oc get APIManager/${DEPLOYMENT_NAME} -o json | jq -r '.spec.zync'`
  2. 将 zync DeploymentConfig 缩减为 0 个 pod:

    oc patch APIManager/${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync": {"appSpec": {"replicas": 0}, "queSpec": {"replicas": 0}}}}'
  3. 将 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/
  4. 解压缩备份文件:

    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'
  5. 恢复 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'
  6. 恢复到原始副本数:

    oc patch APIManager ${DEPLOYMENT_NAME} --type merge -p '{"spec": {"zync":'"${ZYNC_SPEC}"'}}'

7.5.5.3. 使用 backend-redis 和 system-redis 恢复 3scale 选项

通过恢复 3scale,您将恢复 backend-redissystem-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 的实例。

步骤

  1. 编辑 redis-config configmap:

    oc edit configmap redis-config
  2. 注释 redis-config configmap 中的 SAVE 命令:

     #save 900 1
     #save 300 10
     #save 60 10000
  3. redis-config configmap 中将 appendonly 设置为 no

    appendonly no
  4. 重新部署 backend-redis 以加载新配置:

    oc rollout latest dc/backend-redis
  5. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/backend-redis
  6. 重命名 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'
  7. 重命名 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'
  8. 将备份文件移到 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
  9. 重新部署 backend-redis 以加载备份:

    oc rollout latest dc/backend-redis
  10. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/backend-redis
  11. 创建 附加文件

    oc rsh $(oc get pods -l 'deploymentConfig=backend-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
  12. 片刻后,请确保完成 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。零表示执行已经完成。
  13. 编辑 redis-config configmap:

    oc edit configmap redis-config
  14. redis-config configmap 中取消注释 SAVE 命令:

     save 900 1
     save 300 10
     save 60 10000
  15. redis-config configmap 中将 appendonly 设置为 yes

    appendonly yes
  16. 重新部署 backend-redis 以重新载入默认配置:

    oc rollout latest dc/backend-redis
  17. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/backend-redis

7.5.6.2. 管理 system-redis的部署配置

这些步骤旨在运行 system-redis 实例。

步骤

  1. 编辑 redis-config configmap:

    oc edit configmap redis-config
  2. 注释 redis-config configmap 中的 SAVE 命令:

     #save 900 1
     #save 300 10
     #save 60 10000
  3. redis-config configmap 中将 appendonly 设置为 no

    appendonly no
  4. 重新部署 system-redis 以加载新配置:

    oc rollout latest dc/system-redis
  5. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/system-redis
  6. 重命名 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'
  7. 重命名 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'
  8. 备份 文件移到 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
  9. 重新部署 system-redis 以载入备份:

    oc rollout latest dc/system-redis
  10. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/system-redis
  11. 创建 附加文件

    oc rsh $(oc get pods -l 'deploymentConfig=system-redis' -o json | jq '.items[0].metadata.name' -r) bash -c 'redis-cli BGREWRITEAOF'
  12. 片刻后,请确保完成 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。零表示执行已经完成。
  13. 编辑 redis-config configmap:

    oc edit configmap redis-config
  14. redis-config configmap 中取消注释 SAVE 命令:

     save 900 1
     save 300 10
     save 60 10000
  15. redis-config configmap 中将 appendonly 设置为 yes

    appendonly yes
  16. 重新部署 system-redis 以重新载入默认配置:

    oc rollout latest dc/system-redis
  17. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/system-redis

7.5.7. 恢复 backend-worker

恢复到 backend-worker 的最新版本:

oc rollout latest dc/backend-worker
  1. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/backend-worker

7.5.8. 恢复 system-app

恢复到最新版本的 system-app

oc rollout latest dc/system-app
  1. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/system-app

7.5.9. 恢复 system-sidekiq

  1. 恢复到 system-sidekiq 的最新版本:

    oc rollout latest dc/system-sidekiq
  2. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/system-sidekiq

7.5.9.1. 恢复 system-sphinx

  1. 恢复到最新版本的 system-sphinx

    oc rollout latest dc/system-sphinx
  2. 检查推出部署的状态,以确保它已完成:

    oc rollout status dc/system-sphinx

7.5.9.2. 恢复由 Zync 管理的 OpenShift 路由

  1. 强制 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'
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.