9.5. システムデータベースの復元


重要

system-app のような Pod をスケールダウンしたり、ルートを無効にしたりして、レコードが作成されないようにします。

OpenShift シークレットおよびシステムデータベースを復元するには、以下の手順を使用します。

9.5.1. テンプレートベースのデプロイメントの復元

テンプレートベースのデプロイメントを復元するには、以下の手順に従います。

手順

  1. デプロイ用テンプレートを作成する前に、シークレットを復元します。
oc apply -f system-smtp.json
  1. テンプレートパラメーターは、コピーされたシークレットおよび 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')

9.5.2. operator ベースのデプロイメントの復元

operator ベースのデプロイメントを復元するには、以下の手順に従います。

手順

  1. 3scale Operator を OpenShift に インストールします。
  2. 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
  3. APIManager リソースを作成する前に、ConfigMaps を復元します。

    oc apply -f system-environment.json
    oc apply -f apicast-environment.json
  4. APIManager カスタムリソースを使用して、Operator で 3scale をデプロイします。

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

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

9.5.5. zync-database の復元

zync-database を復元する手順は、3scale に適用したデプロイメントタイプによって異なります。

9.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}

9.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}"'}}'

9.5.5.3. backend-redissystem-redis での 3scale オプションの復元

3scale を復元することで、backend-redissystem-redis が復元されます。これらのコンポーネントには、以下の機能があります。

*backend-redis: 3scale のアプリケーション認証とレート制限をサポートするデータベース。統計ストレージおよび一時ジョブストレージにも使用されます。*system-redis: 3scale のバックグラウンドジョブの一時ストレージを提供し、system-app Pod の Ruby プロセスのメッセージバスとしても使用されます。

backend-redis コンポーネント

backend-redis コンポーネントには、dataqueue の 2 つのデータベースがあります。デフォルトの 3scale デプロイメントでは、data および queues は、異なる論理データベースインデックス /0 および /1 で、Redis データベースにデプロイされます。data データベースの復元は問題なく実行されますが、queues データベースを復元すると、ジョブが重複してしまう可能性があります。

ジョブの重複に関して、3scale ではバックエンドワーカーがバックグラウンドジョブを処理します (ミリ秒単位)。最後のデータベーススナップショットの 30 秒後に backend-redis が失敗し、そのスナップショットを復元しようとすると、バックエンドには重複を防ぐためのシステムがないため、30 秒の間に発生したバックグラウンドジョブは 2 回実行されます。

このシナリオでは、/0 データベースインデックスにその他の場所に保存されないデータが含まれているため、バックアップを復元する必要があります。/0 データベースインデックスを復元すると、/1 データベースインデックスを復元する必要もあります。どちらか 1 つだけを復元することはできません。異なるインデックスの 1 つのデータベースではなく、異なるサーバー上のデータベースを分離することを選択した場合、キューのサイズはほぼゼロになるため、バックアップを復元せず、いくつかのバックグラウンドジョブを失うことが望ましくなります。これは、3scale のホスト型設定の場合であるため、両方に異なるバックアップおよび復元ストラテジーを適用する必要があります。

`system-redis` コンポーネント

3scale システムのバックグラウンドジョブの大半はべき等です。つまり、実行する回数に関係なく、同じリクエストが同じ結果を返します。

以下は、システムのバックグラウンドジョブによって処理されるイベントの例の一覧です。

  • プランの試用期間の有効期限がまもなく切れる、クレジットカードの有効期限がまもなく切れる、アクティベーションのリマインダー、プランの変更、請求書の状態の変更、PDF レポートなどの通知ジョブ。
  • インボイスや課金などの請求。
  • 複雑なオブジェクトの削除。
  • バックエンド同期ジョブ。
  • たとえば sphinx を使用したインデックス作成ジョブ。
  • 請求書 ID などのサニタイゼーションジョブ。
  • 監査、ユーザーセッション、期限切れのトークン、ログエントリーのパージ、非アクティブなアカウントを一時停止するなどの管理タスク。
  • トラフィックの更新。
  • プロキシーの設定変更の監視およびプロキシーのデプロイメント。
  • バックグラウンドのサインアップジョブ。
  • シングルサインオン (SSO) の同期、ルート作成などの Zync ジョブ。

上記のバックグラウンドジョブのリストを復元する場合には、3scale のシステムは復元された各ジョブの状態を維持します。復元の完了後にシステムの整合性を確認することが重要です。

9.5.6. バックエンドシステム 間の情報の一貫性確保

backend-redis の復元後、System からの設定情報と同期させ、Backend の情報と信頼できるソース である System の情報の一貫性を確保する必要があります。

9.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 の appendonlyno に設定します。

    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. appendonly ファイルを作成します。

    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 の appendonlyyes に設定します。

    appendonly yes
  16. backend-redis を再デプロイして、デフォルト設定を再読み込みします。

    oc rollout latest dc/backend-redis
  17. ロールアウトのステータスを表示し、読み込みが完了したことを確認します。

    oc rollout status dc/backend-redis

9.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 の appendonlyno に設定します。

    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. appendonly ファイルを作成します。

    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 の appendonlyyes に設定します。

    appendonly yes
  16. system-redis を再デプロイして、デフォルト設定を再読み込みします。

    oc rollout latest dc/system-redis
  17. ロールアウトのステータスを表示し、読み込みが完了したことを確認します。

    oc rollout status dc/system-redis

9.5.7. backend-worker の復元

最新バージョンの backend-worker に復元します。

oc rollout latest dc/backend-worker
  1. ロールアウトのステータスを表示し、読み込みが完了したことを確認します。

    oc rollout status dc/backend-worker

9.5.8. system-app の復元

最新バージョンの system-app に復元します。

oc rollout latest dc/system-app
  1. ロールアウトのステータスを表示し、読み込みが完了したことを確認します。

    oc rollout status dc/system-app

9.5.9. system-sidekiq の復元

  1. 最新バージョンの system-sidekiq に復元します。

    oc rollout latest dc/system-sidekiq
  2. ロールアウトのステータスを表示し、読み込みが完了したことを確認します。

    oc rollout status dc/system-sidekiq

9.5.9.1. system-sphinx の復元

  1. 最新バージョンの system-sphinx に復元します。

    oc rollout latest dc/system-sphinx
  2. ロールアウトのステータスを表示し、読み込みが完了したことを確認します。

    oc rollout status dc/system-sphinx

9.5.9.2. Zync が管理する OpenShift ルートの復元

  1. 不足している OpenShift ルートを再作成するように Zync に強制します。

    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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.