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 ベースのデプロイメントを復元するには、以下の手順に従います。

手順

3scale Operator を OpenShift にインストールします。

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 リソースを作成する前に、ConfigMaps を復元します。
```
$ 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 と queue の 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.5. バックエンドとシステム間における情報の一貫性の確保

backend-redis の復元後、system からの Config 情報を強制的に同期させ、backend の情報と 信頼できるソース である system の情報の一貫性を確保する必要があります。

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
```

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 となるまで、定期的に確認します。ゼロは実行が完了したことを示します。
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
```

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 となるまで、定期的に確認します。ゼロは実行が完了したことを示します。
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 ルートの復元

不足している 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'