Kubernetes 環境でデータベースを復元する
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
このガイドでは、ScalarDB または ScalarDL が Kubernetes 環境で使用するデータベースを復元する方法について説明します。 このガイドは、クラウド サービス プロバイダーのマネージド データベースを ScalarDB または ScalarDL のバックエンド データベースとして使用していることを前提としていることに注意してください。
データベースをリストアする手順
-
ScalarDB または ScalarDL ポッドを 0 にスケールインして、バックエンド データベースへのリクエストを停止します。 Helm コマンドで
--set *.replicaCount=0
フラグを使用すると、ポッドを 0 にスケールインできます。- ScalarDB Server
helm upgrade <release name> scalar-labs/scalardb -n <namespace> -f /path/to/<your custom values file for ScalarDB Server> --set scalardb.replicaCount=0
- ScalarDL Ledger
helm upgrade <release name> scalar-labs/scalardl -n <namespace> -f /path/to/<your custom values file for ScalarDL Ledger> --set ledger.replicaCount=0
- ScalarDL Auditor
helm upgrade <release name> scalar-labs/scalardl-audit -n <namespace> -f /path/to/<your custom values file for ScalarDL Auditor> --set auditor.replicaCount=0
- ScalarDB Server
-
ポイントインタイムリカバリ (PITR) 機能を使用してデータベースを復元します。
管理データベースに基づいてデータベースを復元する方法の詳細については、このガイドの 管理されたデータベースに基づいてデータを復元するための補足手順 セクションを参照してください。
NoSQL または複数のデータベースを使用している場合は、Kubernetes 環境での NoSQL データベースのバックアップ のバックアップ手順に従うときに作成した一時停止期間の中間点を指定する必要があります。
-
新しく復元されたデータベースに基づいて database.properties、ledger.properties、または auditor.properties を更新します。
PITR 機能はデータベースを別のインスタンスとして復元するため、新しく復元されたデータベースにアクセスするには、ScalarDB または ScalarDL のカスタム値ファイル内のエンドポイント情報を更新する必要があります。 カスタム値ファイルの設定方法の詳細については、Configure a custom values file for Scalar Helm Charts を参照してください。
Amazon DynamoDB を使用している場合、データは別のインスタンスではなく別のテーブル名で復元されることに注意してください。 つまり、データの復元後にエンドポイントは変更されません。 代わりに、Amazon DynamoDB 内のテーブルの名前を変更してデータを復元する必要があります。 同じテーブル名でデータを復元する方法の詳細については、このガイドの Amazon DynamoDB セクションを参照してください。
-
Helm コマンドの
--set *.replicaCount=N
フラグを使用して、ScalarDB または ScalarDL ポッドを 1 以上にスケールアウトし、クライアントからのリクエストの受け入れを開始します。- ScalarDB Server
helm upgrade <release name> scalar-labs/scalardb -n <namespace> -f /path/to/<your custom values file for ScalarDB Server> --set scalardb.replicaCount=3
- ScalarDL Ledger
helm upgrade <release name> scalar-labs/scalardl -n <namespace> -f /path/to/<your custom values file for ScalarDL Ledger> --set ledger.replicaCount=3
- ScalarDL Auditor
helm upgrade <release name> scalar-labs/scalardl-audit -n <namespace> -f /path/to/<your custom values file for ScalarDL Auditor> --set auditor.replicaCount=3
- ScalarDB Server
管理されたデータベースに基づいてデータを復元するための補足手順
Amazon DynamoDB
PITR 機能を使用すると、Amazon DynamoDB は別のテーブル名でデータを復元します。 したがって、同じテーブル名でデータを復元するには、追加の手順に従う必要があります。
ステップ
-
バックアップを作成します。
- 一時停止期間の中間点を復元ポイントとして選択し ます。
- PITR を使用してテーブル A をテーブル B に復元します。
- 復元されたテーブル B のバックアップを実行します。次に、バックアップの名前がバックアップ B に適切であることを確認します。
- テーブル B を取り外します。
PITR を使用して DynamoDB テーブルを復元する方法、および DynamoDB テーブルのバックアップを手動で実行する方法の詳細については、Amazon の次の公式ドキュメントを参照してください。
この バックアップの作成 ステップは、Kubernetes 環境で NoSQL データベースをバックアップする のバックアップ操作の一部として実行できます。
-
バックアップから復元します。
- テーブル A を取り外します。
- バックアップ B を使用して、A という名前のテーブルを作成します。
-
環境に応じて、必要に応じてテーブル構成を更新します。
自動スケーリング ポリシーなどの一部の構成は復元後に設定されないため、必要に応じてこれらの構成を手動で設定する必要がある場合があります。 詳細につい ては、Amazon の公式ドキュメントBacking up and restoring DynamoDB tables with DynamoDB: How it works を参照してください。
たとえば、ScalarDB Schema Loader または ScalarDL Schema Loader を使用してテーブルを作成している場合、自動スケーリングはデフォルトで有効になります。 したがって、DynamoDB で復元されたテーブルの自動スケーリングを手動で有効にする必要があります。 DynamoDB で自動スケーリングを有効にする方法の詳細については、Amazon の公式ドキュメント Enabling DynamoDB auto scaling on existing tables を参照してください。
さらに、データベースを復元した後は、PITR 機能が無効になり、読み取り/書き込み容量モードがデフォルト値にリセットされます。 環境に応じて、必要に応じてこれらの構成を手動で設定する必要があります。 復元されたテーブルの一部の構成については、AWS (Amazon DynamoDB) での ScalarDB/ScalarDL デプロイメント用のデータベースのセットアップ を参照してください。
NoSQL 用 Azure Cosmos DB
PITR 機能を使用する場合、Azure Cosmos DB は別のアカウントを使用してデータを復元します。 したがって、カスタム 値ファイル内のエンドポイント構成を更新する必要があります。
ステップ
-
アカウントを復元します。 PITR を使用して Azure Cosmos DB アカウントを復元する方法の詳細については、Restore an Azure Cosmos DB account that uses continuous backup mode を参照してください。
-
復元されたアカウントの デフォルトの整合性レベル をデフォルト値から Strong に変更します。 この値の変更方法の詳細については、Microsoft の公式ドキュメント Configure the default consistency level を参照してください。
-
新しく復元されたアカウントに基づいて、ScalarDB Schema Loader または ScalarDL Schema Loader の database.properties を更新します。
ScalarDB は、ScalarDB Schema Loader または ScalarDL Schema Loader を使用してスキーマを作成するときにインストールされるストアド プロシージャを使用して Cosmos DB アダプターを実装します。 ただし、Cosmos DB の PITR 機能はストアド プロシージャを復元しないため、復元後にすべてのテーブルに必要なストアド プロシージャを再インストールする必要があります。 ScalarDB Schema Loader または ScalarDL Schema Loader の
--repair-all
オプションを使用して、必要なストアド プ ロシージャを再インストールできます。-
ScalarDB テーブル: ScalarDB Schema Loader の database.properties を構成する方法の詳細については、Configure ScalarDB for Cosmos DB for NoSQL を参照してください。
-
ScalarDL テーブル: ScalarDL Schema Loader のカスタム値ファイルの設定方法の詳細については、Configure a custom values file for ScalarDL Schema Loader を参照してください。
-
-
次のように、ScalarDB Schema Loader または ScalarDL Schema Loader で
--repair-all
フラグを使用してストアド プロシージャを再作成します。- ScalarDB テーブル
java -jar scalardb-schema-loader-<version>.jar --config /path/to/<your database.properties> -f /path/to/<your schema.json file> [--coordinator] --repair-all
- ScalarDL Ledger テーブル
helm install repair-schema-ledger scalar-labs/schema-loading -n <namespace> -f /path/to/<your custom values file for ScalarDL Schema Loader for Ledger> --set "schemaLoading.commandArgs={--repair-all}"
- ScalarDL Auditor テーブル
helm install repair-schema-auditor scalar-labs/schema-loading -n <namespace> -f /path/to/<your custom values file for ScalarDL Schema Loader for Auditor> --set "schemaLoading.commandArgs={--repair-all}"
ScalarDB Schema Loader でのテーブルの修復の詳細については、Repair tables を参照してください。
- ScalarDB テーブル
-
環境に応じて、必要に応じてテーブル構成を更新します。 復元されたアカウントの構成については、Azure での ScalarDB/ScalarDL デプロイ用のデータベースのセットアップ (Azure Cosmos DB for NoSQL) を参照してください。
Amazon RDS
PITR 機能を使用する場合、Amazon RDS は別のデータベース インスタンスを使用してデータを復元します。 したがって、カスタム値ファイル内のエンドポイント構成を更新する必要があります。