Kubernetes 環境でデータベースを復元する

注記

このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。

このガイドでは、ScalarDB または ScalarDL が Kubernetes 環境で使用するデータベースを復元する方法について説明します。 このガイドは、クラウド サービス プロバイダーのマネージド データベースを ScalarDB または ScalarDL のバックエンド データベースとして使用していることを前提としていることに注意してください。

データベースをリストアする手順

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

2. ポイントインタイムリカバリ (PITR) 機能を使用してデータベースを復元します。

   管理データベースに基づいてデータベースを復元する方法の詳細については、このガイドの 管理されたデータベースに基づいてデータを復元するための補足手順 セクションを参照してください。

   NoSQL または複数のデータベースを使用している場合は、Kubernetes 環境での NoSQL データベースのバックアップ のバックアップ手順に従うときに作成した一時停止期間の中間点を指定する必要があります。

3. 新しく復元されたデータベースに基づいて database.properties、ledger.properties、または auditor.properties を更新します。

   PITR 機能はデータベースを別のインスタンスとして復元するため、新しく復元されたデータベースにアクセスするには、ScalarDB または ScalarDL のカスタム値ファイル内のエンドポイント情報を更新する必要があります。 カスタム値ファイルの設定方法の詳細については、Configure a custom values file for Scalar Helm Charts を参照してください。

   Amazon DynamoDB を使用している場合、データは別のインスタンスではなく別のテーブル名で復元されることに注意してください。 つまり、データの復元後にエンドポイントは変更されません。 代わりに、Amazon DynamoDB 内のテーブルの名前を変更してデータを復元する必要があります。 同じテーブル名でデータを復元する方法の詳細については、このガイドの Amazon DynamoDB セクションを参照してください。

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

管理されたデータベースに基づいてデータを復元するための補足手順

Amazon DynamoDB

PITR 機能を使用すると、Amazon DynamoDB は別のテーブル名でデータを復元します。 したがって、同じテーブル名でデータを復元するには、追加の手順に従う必要があります。

ステップ

1. バックアップを作成します。

   1. 一時停止期間の中間点を復元ポイントとして選択します。
   2. PITR を使用してテーブル A をテーブル B に復元します。
   3. 復元されたテーブル B のバックアップを実行します。次に、バックアップの名前がバックアップ B に適切であることを確認します。
   4. テーブル B を取り外します。

   PITR を使用して DynamoDB テーブルを復元する方法、および DynamoDB テーブルのバックアップを手動で実行する方法の詳細については、Amazon の次の公式ドキュメントを参照してください。

   • Restoring a DynamoDB table to a point in time
   • Backing up a DynamoDB table

   この バックアップの作成 ステップは、Kubernetes 環境で NoSQL データベースをバックアップする のバックアップ操作の一部として実行できます。

2. バックアップから復元します。

   1. テーブル A を取り外します。
   2. バックアップ B を使用して、A という名前のテーブルを作成します。

3. 環境に応じて、必要に応じてテーブル構成を更新します。

   自動スケーリング ポリシーなどの一部の構成は復元後に設定されないため、必要に応じてこれらの構成を手動で設定する必要がある場合があります。 詳細については、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 は別のアカウントを使用してデータを復元します。 したがって、カスタム値ファイル内のエンドポイント構成を更新する必要があります。

ステップ

1. アカウントを復元します。 PITR を使用して Azure Cosmos DB アカウントを復元する方法の詳細については、Restore an Azure Cosmos DB account that uses continuous backup mode を参照してください。

2. 復元されたアカウントの デフォルトの整合性レベル をデフォルト値から Strong に変更します。 この値の変更方法の詳細については、Microsoft の公式ドキュメント Configure the default consistency level を参照してください。

3. 新しく復元されたアカウントに基づいて、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 を参照してください。

4. 次のように、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 を参照してください。

5. 環境に応じて、必要に応じてテーブル構成を更新します。 復元されたアカウントの構成については、Azure での ScalarDB/ScalarDL デプロイ用のデータベースのセットアップ (Azure Cosmos DB for NoSQL) を参照してください。

Amazon RDS

PITR 機能を使用する場合、Amazon RDS は別のデータベース インスタンスを使用してデータを復元します。 したがって、カスタム値ファイル内のエンドポイント構成を更新する必要があります。

ステップ

1. データベース インスタンスを復元します。 PITR を使用して Amazon RDS インスタンスを復元する方法の詳細については、Amazon の次の公式ドキュメントを参照してください。

   • Restoring a DB instance to a specified time
   • Restoring a Multi-AZ DB cluster to a specified time

2. 環境に応じて、必要に応じてテーブル構成を更新します。 復元されたデータベース インスタンスの構成については、AWS での ScalarDB/ScalarDL デプロイメント用のデータベースのセットアップ (Amazon RDS for MySQL、PostgreSQL、Oracle、および SQL Server) を参照してください。

Amazon Aurora

PITR 機能を使用する場合、Amazon Aurora は別のデータベースクラスターを使用してデータを復元します。 したがって、カスタム値ファイル内のエンドポイント構成を更新する必要があります。

ステップ

1. データベースクラスターを復元します。 PITR を使用して Amazon Aurora クラスターを復元する方法の詳細については。 Amazon の公式ドキュメント Restoring a DB cluster to a specified time を参照してください。

2. 環境に応じて、必要に応じてレプリカ (リーダー) を追加してデータベース クラスターをマルチ AZ クラスターにします。

   Amazon Aurora の PITR 機能は、マルチ AZ 構成を使用してデータベースクラスターを復元できません。 データベース クラスターをマルチ AZ クラスターとして復元する場合は、データベース クラスターの復元後にリーダーを追加する必要があります。 リーダーの追加方法の詳細については、Amazon の公式ドキュメント Adding Aurora Replicas to a DB cluster を参照してください。

3. 環境に応じて、必要に応じてテーブル構成を更新します。 復元されたデータベースクラスターの構成については、AWS での ScalarDB/ScalarDL デプロイメント用のデータベースのセットアップ (Amazon Aurora MySQL および Amazon Aurora PostgreSQL) を参照してください。

Azure Database for MySQL/PostgreSQL

PITR 機能を使用する場合、Azure Database for MySQL/PostgreSQL は別のサーバーを使用してデータを復元します。 したがって、カスタム値ファイル内のエンドポイント構成を更新する必要があります。

ステップ

1. データベースサーバーを復元します。 PITR を使用して Azure Database for MySQL/PostgreSQL サーバーを復元する方法の詳細については、次を参照してください。

   • Point-in-time restore of a Azure Database for MySQL Flexible Server using Azure portal
   • Backup and restore in Azure Database for PostgreSQL - Flexible Server

2. 環境に応じて、必要に応じてテーブル構成を更新します。 復元されたデータベース サーバーの構成については、次を参照してください。

   • Azure 上で ScalarDB/ScalarDL デプロイ用のデータベースをセットアップする (Azure Database for MySQL)
   • Azure 上で ScalarDB/ScalarDL デプロイ用のデータベースをセットアップする (Azure Database for PostgreSQL)