9.5. システムデータベースの復元
system-app
のような Pod をスケールダウンしたり、ルートを無効にしたりして、レコードが作成されないようにします。
OpenShift シークレットおよびシステムデータベースを復元するには、以下の手順を使用します。
9.5.1. テンプレートベースのデプロイメントの復元
テンプレートベースのデプロイメントを復元するには、以下の手順に従います。
手順
- デプロイ用テンプレートを作成する前に、シークレットを復元します。
oc apply -f system-smtp.json
テンプレートパラメーターは、コピーされたシークレットおよび 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 ベースのデプロイメントを復元するには、以下の手順に従います。
手順
- 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 カスタムリソースを使用して、Operator で 3scale をデプロイします。
9.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'
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. テンプレートベースのデプロイメント
手順
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}
9.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}"'}}'
9.5.5.3. 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.6. バックエンド
と システム
間の情報の一貫性確保
backend-redis
の復元後、System
からの設定情報と同期させ、Backend
の情報と信頼できるソース である System
の情報の一貫性を確保する必要があります。
9.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
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.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
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.7. backend-worker
の復元
最新バージョンの backend-worker
に復元します。
oc rollout latest dc/backend-worker
ロールアウトのステータスを表示し、読み込みが完了したことを確認します。
oc rollout status dc/backend-worker
9.5.8. system-app
の復元
最新バージョンの system-app
に復元します。
oc rollout latest dc/system-app
ロールアウトのステータスを表示し、読み込みが完了したことを確認します。
oc rollout status dc/system-app
9.5.9. system-sidekiq
の復元
最新バージョンの
system-sidekiq
に復元します。oc rollout latest dc/system-sidekiq
ロールアウトのステータスを表示し、読み込みが完了したことを確認します。
oc rollout status dc/system-sidekiq
9.5.9.1. system-sphinx
の復元
最新バージョンの
system-sphinx
に復元します。oc rollout latest dc/system-sphinx
ロールアウトのステータスを表示し、読み込みが完了したことを確認します。
oc rollout status dc/system-sphinx
9.5.9.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'