本文へジャンプ

リージョン間ディザスタリカバリの設定ガイド

Revision: 5.5.0-902

1 はじめに

1.1 本書の目的と構成

本書では、GridDBのリージョン間ディザスタリカバリ（以降、リージョン間DR）を実現するためのバックアップの手順、リカバリ時の作業手順について説明します。

本書の構成のとおりです。

  • リージョン間DRとは
  • 必要な検討項目とスキル
  • リージョン間DRの方式
  • 作業手順（バックアップの設定手順、復旧の手順）

2 リージョン間DRとは

クラウド上でサービスを構築する場合、リージョンと呼ばれる地域ごとに設置されたデータセンターにVMを配置し、サービスを提供します。
Amazon Web Service（以降、AWS）やMicrosoft Azure（以降、Azure）などのクラウドサービスはこのリージョンを東京や大阪、ソウルなど様々な地域や国に設定しています。
リージョンで障害が発生した場合、そこで稼働しているVMが停止し、サービスの停止が発生してしまいます。
2019年8月 AWSの東京リージョン障害の際には、リージョン障害により多くのサービス停止が発生しました。
通常、リージョンで障害が発生した際、バックアップを取っていなかった場合、リージョンが復旧するまでサービスの復旧ができない状態に陥ってしまいます。
そこでリージョンで障害が発生した際に早期にサービスを復旧できるようにディザスタリカバリ（災害復旧）の対策が必要です。
本書では、GridDBをAWSのリージョン内のVMに配置してサービスを提供する際のディザスタリカバリについて説明します。
GridDBのリージョン間DRでは、通常の運用時にはバックアップのGridDBは稼働せず、災害があった際にバックアップのGridDBを稼働させサービスを復旧させるコールド／スタンバイ方式を取ります。

3 必要な検討項目とスキル

GridDBでリージョン間DRを実現する場合、以下の検討が必要となります。

  • データのバックアップ時間
    蓄積するデータ容量によりバックアップ時間が変わるため、事前にデータ容量の想定が必要となります。
  • バックアップからサービス復旧までの時間
    蓄積するデータ容量によりに変わりますが、本書では復旧までに最大１日程度かかるサービスレベルを想定しています。
  • クラウド環境
    リージョン間DRを実現するにはクラウドサービスを利用するのが一般的です。提供するサービスの要件に応じてクラウドサービスを選択する必要があります。
  • バックアップするリージョン
    提供するサービスの要件に応じて、稼働させるリージョン、バックアップ先のリージョンを選択する必要があります。

本書に記載するバックアップの設定、復旧作業に際しては、GridDBの他にAWSのスキルが必要となります。

  • AWSコンソールでの操作
    • EC2やS3バケットの作成
    • EBSのスナップショット作成
  • AWS CLIでの操作
    • S3へのデータコピー

通常時は特定の一つのリージョン（リージョン１）でGridDBが稼働し、その他のリージョン（リージョン２）のGridDBは起動せず、バックアップファイルのみ保持します。
アプリケーションはリージョン１のGridDBに接続して、サービスを提供します。
災害が発生して、リージョン１が停止し、サービスが停止してしまった際には、リージョン２のGridDBを稼働させて、アプリケーションの接続をリージョン２のGridDBに切り替えてサービスを再開します。
これによりリージョン１が障害により停止している状態でも、サービスを再開できます。

4 リージョン間DRの方式

稼働系をリージョン1、バックアップ系をリージョン2とします。
通常はリージョン1でGridDBが稼働させ、災害が発生したとき、リージョン2に新たにGridDBを立ち上げ、サービスを再開させます。通常時はリージョン2にはバックアップデータしか置かないため、EC2インスタンスなどの費用は発生しません。
リージョン1からリージョン2へは定期的にバックアップデータを転送しますが、方式には、自動ログバックアップを利用するものと、EBSスナップショットを利用するもので2種類あります。以降で2つの方式ついて解説します。

4.1 方式1. 自動ログバックアップを利用したリージョン間DR

方式1は、まず、GridDBのフルバックアップをリージョン2のS3にコピーし、次にGridDBの自動ログバックアップ機能を使い、差分データをリージョン2のS3にコピーしていきます。自動ログバックアップとは、フルバックアップ以降に発生したトランザクション処理1つ1つのログファイルをローカルのハードディスクにバックアップする機能です。

復旧時は、リージョン2にGridDBのEC2インスタンスを作成し、フルバックアップとトランザクションログを、GridDBのデータディレクトリに配置し起動すると、自動的にフルバック以降に発生したトランザクション処理が復元されます。
EC2インスタンスはOSから作成するのではなく、リージョン1で予めGridDBがインストールされた状態のAMIをバックアップし、AMIからEC2インスタンスを作成します。これにより、稼働系のGridDBの設定がすべて、バックアップ系に引き継がれます。ただし、IPアドレスはリージョン2では変わってしまうため再設定が必要です。

フルバックアップは週1回、自動ログバックアップは日1回が目安です。スケジュール実行にはLinuxのCRONを利用します。CRONの設定、バックアップのスクリプトについては5章で解説します。また、サンプルスクリプトでは、フルバックアップと自動ログバックアップをセットに3世代分保持するようなっています。復旧にはフルバックアップと自動ログバックアップが必要になります。保持する世代数については、提供するサービスの要件に応じて調整します。

4.2 方式2. EBSスナップショットを利用したリージョン間DR

方式2はGridDBのフルバックアップをEBSのスナップショット機能を使い、スナップショットをリージョン2にコピーします。

復旧時は、リージョン2にGridDBのEC2インスタンスを作成し、スナップショットからEBSを復元します。EC2インスタンスの作成については方式1と同様です。

EBSのスナップショットは日1回が目安です。
方式1同様にスケジュール実行にはLinuxのCRONを利用します。CRONの設定、バックアップのスクリプトについては5章で解説します。また、サンプルスクリプトでは、スナップショットに3世代分保持するようなっています。保持する世代数については、提供するサービスの要件に応じて調整します。
EBSはGridDBのデータベース領域とOS領域を分けてアタッチ作成します。スナップショットをとるのはデータベース領域のEBSのみです。

4.3 方式によるサービスレベルの違いについて

2つの方式よるサービスレベルの違いについて記述します。
1ノードあたり約1,200GB、3ノード構成のクラスタで合計約3,600GBのデータ容量でリージョン間DRを設定した場合、復旧時間と費用の目安は下表となります。
どちらの方式も、日1回のバックアップになるので、災害時は最大で1日分のデータをロストする可能性があります。

比較項目 方式1. S3にバックアップ 方式2. EBSスナップショット
復旧時間 (※1) 600分 150分
費用の比較 (※2) 254万円／年 93万円／年

※1 復旧時間のうち、EC2インスタンスの作成や、IPアドレスの変更などの手作業の時間は両方式共通で120分として試算しています。
※2 毎日各ノードに10GBのデータ更新が発生するものとして試算しています。

上記は、EC2インスタンスタイプをt3.mediumとした場合の値です。EC2のインスタンスタイプにより値は変化します。
インスタンスタイプが小さいとネットワーク帯域が大きく制限され、復旧に時間がかかるので注意が必要です。詳しくはAWSのドキュメント Linux インスタンス用ユーザーガイド 汎用インスタンスより、ネットワークパフォーマンスを参照ください。

4.4 GridDBのバックアップに関連する用語とファイルの説明

GridDBのバックアップに関連する用語およびファイルについて以下に記述します。

4.4.1 ファイルの種類

GridDBのバックアップの対象となるファイルの種類について以下に記述します。

  • データベースファイル
    クラスタを構成するノードの保有するデータをディスクやSSDに書き込んだファイル群の総称です。
    データベースファイルについてはGridDB データベース管理者ガイドにも記述がありますので参照願います。
    データベースファイルには、以下の3種類のファイルがあります。

    • データファイル
      データを格納するファイルです。
      GridDBの設定がデフォルトの場合、/var/lib/gridstore/data の下に、以下のようなファイル名で配置されます。 
      /<PartitionID>/<PartitionID>_part_<n>.dat   
（n：0からの連番）
    • チェックポイントログファイル
      パーティションのブロック管理情報をディスクに書き込んだファイルです。
      GridDBの設定がデフォルトの場合、/var/lib/gridstore/data の下に、以下のようなファイル名で配置されます。 
      /<PartitionID>/<PartitionID>_<CheckpointNumber>.cplog
    • トランザクションログファイル
      トランザクションの更新情報がログとしてシーケンシャルに保存されるファイルです。ひとつのファイルには、前回のチェックポイント開始から次のチェックポイント開始までに実行されたトランザクションログを格納します。
      GridDBの設定がデフォルトの場合、/var/lib/gridstore/txnlog の下に、以下のようなファイル名で配置されます。 
      /<PartitionID>/<PartitionID>_<CheckpointNumber>.xlog

  • シーケンス番号ファイル
    パーティション更新のシーケンス番号を示すファイルです。
    GridDBの設定がデフォルトの場合、/var/lib/gridstore/data の下に、以下のようなファイル名で配置されます。

    gs_lsn_info.json

4.4.2 バックアップ方法を示す用語

GridDBのバックアップ方法を示す用語について以下に記述します。

  • ファイルコピーによるフルバックアップ
    すべてのデータベースファイル、およびシーケンス番号ファイルのデータをコピーするバックアップ方法です。

  • GridDBの自動ログバックアップ
    フルバックアップ採取以降、トランザクションログがバックアップディレクトリに、自動的にが採取されるバックアップ方法です。
    自動ログバックアップはGridDBの運用コマンドにて、採取を行います。
    自動ログバックアップ の採取を行うと、バックアップディレクトリに以下の種類のファイルが作成されます。

    • シーケンス番号ファイル
      パーティション更新のシーケンス番号を示すファイルです。
      自動ログバックアップはGridDBの運用コマンドにて採取を行いますが、その際に、バックアップ名を指定します。
      バックアップディレクトリ/<バックアップ名>の下に、以下のようなファイル名で配置されます。 
      gs_lsn_info.json
    • トランザクションログファイル
      トランザクションの更新情報がログとしてシーケンシャルに保存されるファイルです。
      バックアップディレクトリ/<バックアップ名>の下に、以下のようなファイル名で配置されます。 
      /txnlog/<PartitionID>/<PartitionID>_<CheckpointNumber>.xlog

5 作業手順

各方式における作業手順を記述します。

以下の作業手順にスクリーンショットを記載しますが、以下のリージョンを使用したスクリーンショットとなっています。

バックアップ元リージョン バックアップ先リージョン
東京リージョン 大阪リージョン

5.1 方式1. 別のリージョンのAmazon S3にバックアップ

GridDBのバックアップファイルをバックアップ先のリージョンにあるAmazon S3に配置する方式です。

この方式を実施するために、バックアップ先として使用するAmazon S3の設定、バックアップを行うためのスクリプトの設定、バックアップを定期的に行うためのCRONの設定を行います。

5.1.1 バックアップ設定

5.1.1.1 バックアップ設定の概要

バックアップ設定の概要は以下の通りです。

  1. AMIの作成
    バックアップ先のリージョンにGridDBインストール済みのEC2のAMIを配置します。
    このAMIは復元作業時にEC2を作成する際に使用します。
  2. S3のバケットを作成
    バックアップ先のAmazon S3として使用するために、バックアップ先のリージョンにて、Amazon S3のバケットを作成します。
  3. バックアップ元リージョンのEC2からバックアップ先リージョンのS3を使用するための設定
    バックアップ先リージョンのS3を使用するために必要な設定を行います。
  4. S3使用許可設定
    S3を使用するために必要な権限の設定を行います。
  5. GridDBの設定を変更（自動ログバックアップ）
    自動ログバックアップのファイルが作成される場所を指定するために、バックアップ元のリージョンにて、GridDBに自動ログバックアップ先の設定を行います。
  6. スクリプトを設定（サンプルを提供）
    バックアップを実施するスクリプトが動作できるようにするために、バックアップ元のリージョンにて、自動ログバックアップおよびファイルコピーによるフルバックアップを実施するスクリプトの設定を行います。
  7. 定期実行の設定（CRONによる設定）
    バックアップが定期的に実施されるようにするために、バックアップ元のリージョンにて、自動ログバックアップおよびファイルコピーによるフルバックアップを実施するスクリプトを定期的に実行するための設定を行います。

5.1.1.2 手順1 AMIの作成

EC2に既にGridDBはインストール済みであるとします。また、EC2インスタンスのGridDBはまだ一度も起動していないものとします。

GridDBインストール済みのEC2のAMIを作成します。このAMIは復旧作業実施時に、ディザスタリカバリ先でEC2インスタンスを作成する際に使用します。

注：AMI作成時に、EC2インスタンスを停止します。EC2インスタンスを停止しても問題ない状態で作業実施してください。

  • AWS マネジメントコンソール「EC2」より「インスタンス」をクリックします。
  • AMIを作成する対象のEC2を選択してください。
    その後、右クリック->[アクション]->[イメージ]->[イメージの作成]クリックを行います。

  • 以下の入力を行います。

    入力項目 入力値
    イメージ名 名前を入力（入力値は任意）（例：ami-griddb-node-11）
    イメージの説明 説明を入力
    復旧作業実施時には、このAMIからEC2の作成を行います。
    どのEC2インスタンスのAMIであるかわかる情報を入力してください。

  • [イメージの作成]をクリックします。

  • [イメージの作成]を行ったメッセージが表示されます。
  • AWS マネジメントコンソール「EC2」より「AMI」をクリックします。
    先の手順で作成したAMIのステータスがavailableになるまで待ちます。
  • 先の手順で作成したAMIを選択します。その後、[アクション]->[AMIのコピー]クリックを行います。

  • 以下の入力を行います。

    入力項目 入力値
    送信先リージョン バックアップ先リージョン
    名前 名前を入力（入力値は任意）（例：ami-griddb-node-11）
    説明 説明を入力

    [AMIのコピー]をクリックします。

  • [AMIのコピー]を行ったメッセージが表示されます。
  • [完了]をクリックします。
  • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。コピーしたAMIが存在していることを確認します。

5.1.1.3 手順2 S3のバケットを作成

バックアップ先リージョンにバックアップ作成先として使用するS3バケットを作成します。

  • AWS マネジメントコンソール「Amazon S3」より「バケット」をクリックします。
  • [バケットを作成]をクリックします。

  • 以下の入力を行います。

    入力項目 入力値
    バケット名 名前を入力（入力値は任意）
    AWSリージョン バックアップ先リージョン

  • [バケットを作成]をクリックします。

  • [バケットを作成]を行ったメッセージが表示されます。
  • バックアップ元リージョンのEC2からバックアップ先リージョンのS3バケットを使用可能とするために、バックアップ先リージョンにVPCを作成します。

5.1.1.4 手順3 バックアップ元リージョンのEC2からバックアップ先リージョンのS3を使用するための設定

バックアップ元リージョンのEC2からバックアップ先リージョンのS3を使用できるようにするために、バックアップ先リージョンにVPC、サブネットを作成します。

  • バックアップ先リージョンにVPCを作成します。

    • AWS マネジメントコンソール「VPC」より「VPC」をクリックします。
    • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。
    • [VPCを作成]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      名前 名前を入力（入力値は任意）（例：vpc-griddb-dr-bkup）
      IPv4 CIDR バックアップ先リージョンのVPCのCIDR（例：10.6.0.0/16）

      [VPCを作成]をクリックします。

    • VPCの作成を行ったメッセージが表示されます。

  • バックアップ先リージョンにサブネットを作成します。
    ここではpublicサブネット用とprivateサブネット用にサブネットを2つ作成します。

    • AWS マネジメントコンソール「VPC」より「サブネット」をクリックします。
    • [サブネットを作成]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      VPC ID バックアップ先リージョンのVPC
      サブネット名 名前を入力（入力値は任意）（例：subnet-griddb-bkup-public）
      アベイラビリティゾーン バックアップ先リージョンのアベイラビリティゾーンを選択
      IPv4 CIDR ブロック バックアップ先リージョンのVPCのCIDR（例：10.6.10.0/24）

      [新しいサブネットを追加]をクリックします。

    • 「サブネット2」に以下の入力を行います。

      入力項目 入力値
      サブネット名 名前を入力（入力値は任意）（例：subnet-griddb-bkup-private）
      アベイラビリティゾーン 「サブネット1」と同じアベイラビリティゾーンを選択
      IPv4 CIDR ブロック バックアップ先リージョンのVPCのCIDR（例：10.6.100.0/24）

      [サブネットを作成]をクリックします。

    • サブネットを作成したことを示すメッセージが表示されます。

    • サブネットと関連付けるルートテーブルを作成します。
      ここではpublicサブネット用とprivateサブネット用にルートテーブルを2つ作成します。

    • AWS マネジメントコンソール「VPC」より「ルートテーブル」をクリックします。
      [ルートテーブルを作成]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      名前 名前を入力（入力値は任意）（例：rtb-subnet-griddb-bkup-01）
      VPC バックアップ先リージョンのVPC

    [ルートテーブルを作成]をクリックします。

    • ルートテーブルを作成したことを示すメッセージが表示されます。
      「サブネットの関連付け」をクリックします。
      [サブネットの関連付けを編集]をクリックします。
    • publicサブネットのサブネットを選択します。
    • [関連付けを保存]をクリックします。
    • 関連付けが行われたことを示すメッセージが表示されます。
    • 再度「ルートテーブル」をクリックした後、[ルートテーブルを作成]をクリックし、同様にprivateサブネット用のルートテーブルを作成します。
    • ルートテーブル作成後、[サブネットの関連付けを編集]をクリックします。
    • privateサブネットのサブネットを選択します。
    • [関連付けを保存]をクリックします。
    • 関連付けが行われたことを示すメッセージが表示されます。

バックアップ元リージョンのEC2からバックアップ先リージョンのS3を使用できるようにするための設定を行います。

  • バックアップ元リージョンのVPCとバックアップ先リージョンのVPC間のピアリング設定を行います。

    • AWS マネジメントコンソール「VPC」より「ピアリング接続」をクリックします。

    • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ元リージョン（例：東京）を選択します。

    • [ピアリング接続を作成]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      名前 名前を入力（入力値は任意）（例：peering-vpc-griddb-dr-01）
      VPC ID バックアップ元リージョンのVPCを選択
      リージョン 「別のリージョン」を選択
      別のリージョン バックアップ先リージョン
      VPC ID バックアップ先リージョンのVPC IDを入力

    • [ピアリング接続を作成]をクリックします。

    • ピアリング接続承認がリクエストされたことを示すメッセージが表示されます。

    • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。

    • 許諾の保留中であるこを示すメッセージが表示されます。
      [アクション]->[リクエストを承諾]をクリックします。

    • [リクエストを承諾]をクリックします。
      VPCピアリングが作成されます。

  • バックアップ元リージョンのVPCとバックアップ先リージョンのVPC間の通信を行うためにルートテーブルの設定を行います。

    • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ元リージョン（例：東京）を選択します。
      AWS マネジメントコンソール「VPC」より「ルートテーブル」をクリックします。

    • バックアップ元リージョンのVPCで使われているルートテーブルを選択します。
      「ルート」をクリックします。

    • [ルートを編集]をクリックします。

    • [ルートを追加]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      送信先 バックアップ先リージョンのVPCのCIDR（例：10.6.0.0/16）
      ターゲット 「ピアリング接続」を選択した後、作成したVPCピアリングを選択

    • [変更を保存]をクリックします。

    • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。

    • バックアップ先リージョンのVPCでprivateサブネットで使われているルートテーブルを選択します。
      「ルート」をクリックします。

    • [ルートを編集]をクリックします。

      [ルートを追加]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      送信先 バックアップ元リージョンのVPCのCIDR（例：10.5.0.0/16）
      ターゲット 「ピアリング接続」を選択した後、作成したVPCピアリングを選択

    • [変更を保存]をクリックします。

  • バックアップ先リージョンにエンドポイントの作成を行います。

    • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。
      AWS マネジメントコンソール「VPC」より「エンドポイント」をクリックします。

    • [エンドポイントを作成]クリックします。

    • 以下の入力を行います。

      入力項目 入力値
      名前 名前を入力（入力値は任意）（例：endpoint-griddb-dr-bkup）
      サービス バックアップ先リージョン Interface
      VPC バックアップ先リージョンのVPCを選択
      「追加設定」をクリックし「DNS名を有効化」をOFF
      サブネット アベイラビリティゾーンを選択 バックアップ先リージョンのprivateサブネットを選択
      IPアドレスタイプ IPv4
      セキュリティグループ 既存のセキュリティグループ（デフォルトのセキュリティグループ）を選択

    • [エンドポイントを作成]をクリックします。

      エンドポイントが作成されます。

    • 「エンドポイント」から作成したエンドポイントを選択し、「詳細」を確認します。
      ここに表示されるDNS名を後で使用するので、メモしておきます。

  • バックアップ先リージョンにHTTPS通信許可の設定を行います。

    • バックアップ先リージョンのVPCに紐づいているセキュリティグループを選択します。

    • [インバウンドのルールを編集]をクリックします。

    • [ルールを追加]をクリックします。

    • 以下の入力を行います。

      入力項目 入力値
      タイプ HTTPS
      ソース バックアップ元リージョンのVPCのCIDR（例：10.5.0.0/16）

    • [ルールを保存]をクリックします。

5.1.1.5 手順4 S3使用許可設定

  • AWS マネジメントコンソール「EC2」よりインスタンスをクリックします。 IAMロールをクリックします。

  • [許可を追加]->[ポリシーをアタッチ]をクリックします。

  • 「AmazonS3FullAccess」のチェックをオンにして、[ポリシーをアタッチ]をクリックします。

  • ロールのアタッチが行われたことを示す画面が表示されます。

5.1.1.6 手順5 GridDBの設定を変更（自動ログバックアップ）

バックアップ元リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

自動ログバックアップの作成先の設定を行います。

  • gs_node.json に自動ログバックアップの作成先の設定を行います。

    • 以下の値を設定します。

      設定項目 入力値
      /dataStore/backupPath 自動ログバックアップの作成先ディレクトリ

5.1.1.7 手順6 スクリプトを設定（サンプルを提供）

バックアップ元リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

バックアップを行うスクリプトのサンプルを提供します。サンプルはこちらからダウンロードできます。
以下、このスクリプトの設定方法について記述します。

  • dr_full_bkup_to_S3.sh

    • 処理概要
      以下の処理を行うスクリプトです。

      • 自動ログバックアップの開始
      • S3をコピー先として、ファイルコピーによるフルバックアップを採取

    • 設定方法

      • 以下の入力を行います。
      設定項目 説明 入力値
      ENDPOINT_DNS バックアップ先のS3のエンドポイントDNS名 AWS マネジメントコンソール「エンドポイント」「詳細」に表示された
      DNS名を設定してください。
      S3BUCKET_NAME S3バケット名 バックアップ先リージョンに作成したS3バケット名を設定してください。
      BACKUP_REGION バックアップ先リージョン バックアップ先を設定してください。
      NODE_NAME ノードを識別するための名前 GridDBのクラスタを構成する各ノードを識別するための名前を設定します。
      各ノードで異なる値となるよう設定してください。
      ADMIN_PASS adminユーザのパスワード GridDB管理者ユーザであるadminユーザのパスワードを設定してください。
      TXNLOG_PATH txnlogのディレクトリ txnlogのディレクトリのパスを設定してください。
      DATA_PATH dataのディレクトリ dataのディレクトリのパスを設定してください。
      LOCAL_BACKUP_PATH 自動ログバックアップの作成先ディレクトリ 自動ログバックアップの作成先ディレクトリのパスを設定してください。

  • dr_auto_bkup_to_S3.sh

    • 処理概要
      以下の処理を行うスクリプトです。

      • 自動ログバックアップで作成されたファイルをS3へコピー

    • 設定方法

      • 以下の入力を行います。
      設定項目 説明 入力値
      ENDPOINT_DNS バックアップ先のS3のエンドポイントDNS名 AWS マネジメントコンソール「エンドポイント」「詳細」に表示された
      DNS名を設定してください。
      S3BUCKET_NAME S3バケット名 バックアップ先リージョンに作成したS3バケット名を設定してください。
      BACKUP_REGION バックアップ先リージョン バックアップ先を設定してください。
      NODE_NAME ノードを識別するための名前 GridDBのクラスタを構成する各ノードを識別するための名前を設定します。
      各ノードで異なる値となるよう設定してください。
      ADMIN_PASS adminユーザのパスワード GridDB管理者ユーザであるadminユーザのパスワードを設定してください。
      LOCAL_BACKUP_PATH 自動ログバックアップの作成先ディレクトリ 自動ログバックアップの作成先ディレクトリのパスを設定してください。

5.1.1.8 手順7 定期実行の設定（CRONによる設定）

バックアップ元リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

先の手順のスクリプトを定期実行する設定を行います。

  • 前提
    スクリプトは下記のパスにあるものとします。
    また、実行属性が付与されているものとします。

    • /var/lib/gridstore/dr_backup/dr_full_bkup_to_S3.sh
    • /var/lib/gridstore/dr_backup/dr_auto_bkup_to_S3.sh

  • 設定ファイルの準備設定ファイル cron.conf を準備します。
    EC2にcron.confを作成します。内容は以下とします。

0 10 * * 6 /var/lib/gridstore/dr_backup/dr_full_bkup_to_S3.sh 1> /dev/null;/var/lib/gridstore/dr_backup/dr_auto_bkup_to_S3.sh 1> /dev/null
0 5 * * * /var/lib/gridstore/dr_backup/dr_auto_bkup_to_S3.sh 1> /dev/null

ここに示した例は以下のような内容となっています。

  • 毎週土曜の午前10:00にdr_full_bkup_to_S3.shとdr_auto_bkup_to_S3.shを実行。
    ファイルコピーによるフルバックアップと自動ログバックアップのコピーを行う。

  • 午前05:00にdr_auto_bkup_to_S3.shを実行。
    自動ログバックアップのコピーを行う。

  • 設定ファイルの登録設定ファイル cron.conf の内容を反映させるために以下を実行します。

crontab cron.conf

5.1.2 復旧作業

5.1.2.1 復旧作業の概要

復旧時の作業の概要は以下の通りです。

  1. AMIからEC2を復元
    GridDBを稼働させるEC2を作成するために、AMIよりEC2を作成します。
  2. GridDBの設定変更
    復旧先の環境に合わせるためにGridDBの設定変更を行います。
  3. ファイルコピーによるフルバックアップからの復元
    フルバックアップからGridDBのデータファイルの復元を行います。
  4. 自動ログバックアップからの復元
    自動ログバクアップからGridDBのデータファイルの復元を行います。
  5. GridDBクラスタを起動
    GridDBを起動します。
  6. アプリの接続先を変更
    復旧先の環境に合わせるためにGridDBを使用するアプリの設定変更を行います。

5.1.2.2 手順1 AMIからEC2を復元

AMIよりEC2を作成します。

  • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。

  • バックアップ先リージョンのEC2にて使用するキーペアがない場合、キーペアを作成します。
    AWS マネジメントコンソール「EC2」より「キーペア」をクリックします。

  • [キーペアを作成]をクリックします。

  • 以下の入力を行います。

入力項目 入力値
名前 名前を入力（入力値は任意）（例：key-osk）
プライベートキーファイル形式 .pem

  • [キーペアを作成]をクリックします。

  • キーペアが作成されたことを示すメッセージが表示されます。
    また、.pem のダウンロードが始まりますので、これを保存します。

  • AWS マネジメントコンソール「EC2」より「AMI」をクリックします。

  • バックアップ元リージョンからコピーしたAMIを選択します。
    該当するAMIがどれかはAMI作成時に入力した「説明」を参考に判断します。

  • [起動]クリックします。

  • 以下の入力を行います。

入力項目 入力値
名前 名前を入力（入力値は任意）（例：griddb-node-11）
インスタンスタイプ 任意
キーペア 既存のキーペアを選択
VPC バックアップ先リージョンのVPCを選択
サブネット バックアップ先リージョンのVPCのサブネットを選択
ファイアウォール (セキュリティグループ) 「既存のセキュリティグループを選択する」を選択
バックアップ先リージョンのセキュリティグループを選択
高度な詳細
IAMインスタンスプロフィール		 既存のIAMインスタンスプロフィールを選択
（バックアップ元リージョンのEC2で使用していたものと同じIAMインスタンスプロフィールを選択）

  • [インスタンスを起動]をクリックします。

  • [インスタンスの起動]を開始したことを示すメッセージが表示されます。

5.1.2.3 手順2 GridDBの設定変更

バックアップ先リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

先の手順で復旧したEC2のIPアドレスは、復旧元のEC2のIPアドレスとは異なるものになります。
そのため、復旧したEC2のIPアドレスに合わせるためにGridDBの設定変更を行います。

  • gs_cluster.json

    • 以下の値を設定します。
    設定項目 入力値
    /cluster/notificationMember[]/cluster/address 復旧したEC2のIPアドレス
    /cluster/notificationMember[]/sync/address （同上）
    /cluster/notificationMember[]/system/address （同上）
    /cluster/notificationMember[]/transaction/address （同上）
    /cluster/notificationMember[]/sql/address （同上）

5.1.2.4 手順3 ファイルコピーによるフルバックアップからの復元

バックアップ先リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

フルバックアップからGridDBのデータファイルの復元を行います。

  • 復元を行う前に、dataディレクトリ txnlogディレクトリが空になっている必要があります。
    dataディレクトリ txnlogディレクトリが空であるか確認します。
    作業例：

    ls -al /var/lib/gridstore/data/*
ls -al /var/lib/gridstore/txnlog/*

  • 既にdataディレクトリ txnlogディレクトリにファイルがある場合、このファイルを削除します。
    作業例：

    rm -rf /var/lib/gridstore/data/*
rm -rf /var/lib/gridstore/txnlog/*

  • S3上のバックアップを確認します。
    復旧したEC2にて以下を実行します。

aws s3 ls s3://<S3バケット名>/<ノードを識別するための名前>/

以下ような結果が得られます。

-bash-4.2$ aws s3 ls s3://XXXXXX/NODE01/
                           PRE dr_backup56/
                           PRE dr_backup57/
                           PRE dr_backup58/
-bash-4.2$

dr_backupnn のうち数値が最大のものが一番新しいバックアップになります。
ここでは例として
dr_backup58
から復旧を行うものとします。

  • S3上のバックアップからコピーを行います。
  • dataディレクトリのファイルをコピー
    復旧したEC2にて以下を実行します。
aws s3 cp s3://<S3バケット名>/<ノードを識別するための名前>/dr_backup58/fullbackup/data/ <dataディレクトリ>  --recursive
例：
aws s3 cp s3://XXXXXX/NODE01/dr_backup58/fullbackup/data/ /var/lib/gridstore/data  --recursive
  • txnlogディレクトリのファイルをコピー
    復旧したEC2にて以下を実行します。
aws s3 cp s3://<S3バケット名>/<ノードを識別するための名前>/dr_backup58/fullbackup/txnlog/ <txnlogディレクトリ>  --recursive
例：
aws s3 cp s3://XXXXXX/NODE01/dr_backup58/fullbackup/txnlog/ /var/lib/gridstore/txnlog  --recursive

5.1.2.5 手順4 自動ログバックアップからの復元

バックアップ先リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

自動ログバックアップからGridDBのデータファイルの復元を行います。

  • 自動ログバックアップのファイルをコピー
    復旧したEC2にて以下を実行します。
aws s3 cp s3://<S3バケット名>/<ノードを識別するための名前>/dr_backup58/autobackup/drautobkup/txnlog/ <txnlogディレクトリ>  --recursive
例：
aws s3 cp s3://XXXXXX/NODE01/dr_backup58/autobackup/drautobkup/txnlog/ /var/lib/gridstore/txnlog  --recursive

5.1.2.6 手順5 GridDBクラスタを起動

バックアップ先リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

GridDBを起動します。

  • GridDBのノード起動を行います。起動方法は通常のノード起動の方法と同じです。
  • GridDBのクラスタへの参加を行います。参加方法は通常のクラスタ参加の方法と同じです。

5.1.2.7 手順6 アプリの接続先を変更

復旧したEC2のIPアドレスは、復旧元のEC2のIPアドレスとは異なるものになります。
そのため、GridDBへ接続を行うアプリはGridDBの接続先の設定を、復旧したEC2のアドレスに変更する必要があります。

（例）
JDBC接続先設定の
notificationMember=10.5.100.102:20001,10.5.131.249:20001,10.5.251.145:20001
を
notificationMember=<復元したEC2(1つ目)のIPアドレス>:20001,<復元したEC2(2つ目)のIPアドレス>:20001,<復元したEC2(3つ目)のIPアドレス>:20001
に変更

5.2 方式2. データベースファイルを配置したEBSのスナップショットを別のリージョンに配置

5.2.1 バックアップ設定

5.2.1.1 バックアップ設定の概要

バックアップ設定の概要は以下の通りです。

  1. データベースファイル配置用のEBS作成
    GridDBが使用するデータベースファイル配置用のEBSとして使用するために、バックアップ元のリージョンにて、EBSを作成し、EC2にアタッチします。
  2. GridDBの設定変更
    GridDBがデータベースファイル配置用のEBSを使用するよう、バックアップ元のリージョンにて、GridDBの設定を変更します。
  3. AMIの作成
    GridDBインストール済みのEC2のAMIを作成します。このAMIは復元作業時にEC2を作成する際に使用します。
  4. スナップショット使用許可設定
    スナップショットを使用するために必要な権限の設定を行います。
  5. スクリプトを設定（サンプルを提供）
    スナップショットの作成およびスナップショットのコピーを行うスクリプトが動作できるようにするために、バックアップ元のリージョンにて、スナップショットを作成するスクリプトの設定を行います。
  6. 定期実行の設定（CRONによる設定）
    スナップショットの作成が定期的に行われるようにするために、バックアップ元のリージョンにて、データベースファイル配置用のEBSのスナップショットを作成するスクリプトを定期的に実行するための設定を行います。

5.2.1.2 手順1 データベースファイル配置用のEBS作成

GridDBのデータベースファイル配置用のEBSがまだない場合、データベースファイル配置用のEBSを作成、EC2へのアタッチを行います。

  • EC2へアタッチした後、EC2にてフォーマットを行います。
    • 作業例を示します。
    # 作成したEBSは/dev/xvdb にアタッチしたものとする
# EC2にて、/db にマウントするものとする
mkfs -t xfs /dev/xvdb
file -s /dev/xvdb
mkdir /db
mount /dev/xvdb /db
  • 再起動後でもアタッチしたEBSをマウントするよう、/etc/fstab の設定を行います。
    • 作業例を示します。
    # /etc/fstab に以下を追加。
/dev/xvdb   /db       xfs    defaults,nofail   0   2

5.2.1.3 手順2 GridDBの設定変更

バックアップ元リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

GridDBがデータベースファイル配置用のEBSを使用するよう、設定を変更します。

  • gs_node.json にデータベースファイル作成先の設定を行います。

    • 以下の値を設定します。

      設定項目 入力値
      /dataStore/dbPath データファイルの作成先ディレクトリ
      /dataStore/transactionLogPath トランザクションログファイルの作成先ディレクトリ

      データベースファイル配置用のEBSにデータファイル、トランザクションログファイルが作成されるよう上記の設定値を変更します。

5.2.1.4 手順3 AMIの作成

EC2に既にGridDBはインストール済みであるとします。また、EC2インスタンスのGridDBはまだ一度も起動していないものとします。

GridDBインストール済みのEC2のAMIを作成します。このAMIは復旧作業実施時に、ディザスタリカバリ先でEC2インスタンスを作成する際に使用します。

注：AMI作成時に、EC2インスタンスを停止します。EC2インスタンスを停止しても問題ない状態で作業実施してください。

  • AWS マネジメントコンソール「EC2」より「インスタンス」をクリックします。
  • AMIを作成する対象のEC2を選択してください。
    その後、右クリック->[アクション]->[イメージ]->[イメージの作成]クリックを行います。

  • 以下の入力を行います。

    入力項目 入力値
    イメージ名 名前を入力（入力値は任意）（例：ami-griddb-node-11）
    イメージの説明 説明を入力
    復旧作業実施時には、このAMIからEC2の作成を行います。
    どのEC2インスタンスのAMIであるかわかる情報を入力してください。

  • [イメージの作成]をクリックします。

  • [イメージの作成]を行ったメッセージが表示されます。
  • AWS マネジメントコンソール「EC2」より「AMI」をクリックします。
    先の手順で作成したAMIのステータスがavailableになるまで待ちます。
  • 先の手順で作成したAMIを選択します。その後、[アクション]->[AMIのコピー]クリックを行います。

  • 以下の入力を行います。

    入力項目 入力値
    送信先リージョン バックアップ先リージョン
    名前 名前を入力（入力値は任意）（例：ami-griddb-node-11）
    説明 説明を入力

    [AMIのコピー]をクリックします。

  • [AMIのコピー]を行ったメッセージが表示されます。
  • [完了]をクリックします。
  • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。コピーしたAMIが存在していることを確認します。

5.2.1.5 手順4 スナップショット使用許可設定

  • AWS マネジメントコンソール「IAM」よりポリシーをクリックします。
    [ポリシーの作成]をクリックします。

  • [JSON]をクリックします。

  • Statement に以下の定義を追加します。

        {
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "ec2:CreateSnapshot",
                "ec2:CopySnapshot",
                "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
        }

  • [次のステップ:タグ]をクリックします。

  • [タグを追加]をクリックします。
    以下の入力を行います。

    入力項目 入力値
    キー name
    値 createsnapshot

    [次のステップ:確認]をクリックします。

  • 以下の入力を行います。

    入力項目 入力値
    名前 AmazonEC2CreateSnapshots
    説明 create snapshot

    [ポリシーの作成]をクリックします。

  • AWS マネジメントコンソール「EC2」よりインスタンスをクリックします。 IAMロールをクリックします。

  • AWS マネジメントコンソール「EC2」よりインスタンスをクリックします。

  • [許可を追加]->[ポリシーをアタッチ]をクリックします。

  • 先ほど作成した「AmazonEC2CreateSnapshots」を選択します。
    [ポリシーをアタッチ]をクリックします。

  • ポリシーのアタッチが行われたことを示すメッセージが表示されます。

5.2.1.6 手順4 スクリプトを設定（サンプルを提供）

バックアップ元リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

EBSスナップショットの作成を行うスクリプトのサンプルを提供します。サンプルはこちらからダウンロードできます。

以下、このスクリプトの設定方法について記述します。

  • dr_ebs_snapshot.sh

    • 処理概要
      以下の処理を行うスクリプトです。

      • EBSスナップショットを採取
      • EBSスナップショットを別のリージョンへコピー

    • 設定方法

      • 以下の入力を行います。
      設定項目 説明 入力値
      EBS_VOLUME_ID スナップショットをとるEBSのボリュームID GridDBデータファイル用に作成したEBSのボリュームIDを設定
      REGION_FROM EBSのあるリージョン バックアップ元リージョン（例：ap-northeast-1）を設定
      REGION_TO EBSスナップショットのコピー先のリージョン バックアップ先リージョン（例：ap-northeast-3）を設定
      NODE_NAME ノードを識別するための名前 GridDBのクラスタを構成する各ノードを識別するための名前を設定します。
      各ノードで異なる値となるよう設定してください。
      ADMIN_PASS adminユーザのパスワード GridDB管理者ユーザであるadminユーザのパスワードを設定してください。

5.2.1.7 手順5 定期実行の設定（CRONによる設定）

バックアップ元リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

先の手順のスクリプトを定期実行する設定を行います。

  • 前提
    スクリプトは下記のパスにあるものとします。
    また、実行属性が付与されているものとします。

    • /var/lib/gridstore/dr_backup/dr_ebs_snapshot.sh

  • 設定ファイルの準備設定ファイル cron.conf を準備します。
    EC2にcron.confを作成します。内容は以下とします。

0 5 * * * /var/lib/gridstore/dr_backup/dr_ebs_snapshot.sh 1> /dev/null

ここに示した例は以下のような内容となっています。

  • 午前05:00にdr_ebs_snapshot.shを実行。
    EBSスナップショットの作成とEBSスナップショットのコピー先リージョンへのコピーを行う。

  • 設定ファイルの登録設定ファイル cron.conf の内容を反映させるために以下を実行します。

crontab cron.conf

5.2.2 復旧作業

5.2.2.1 復旧作業の概要

復旧時の作業の概要は以下の通りです。

  1. AMIからEC2を復元
    GridDBを稼働させるEC2を作成するために、AMIよりEC2を作成します。
  2. EBSスナップショットからの復元およびEC2へのアタッチ
    GridDBのデータファイルの復元のために、EBSスナップショットからの復元を行います。
  3. GridDBの設定変更
    復旧先の環境に合わせるためにGridDBの設定変更を行います。
  4. GridDBクラスタを起動
    GridDBを起動します。
  5. アプリの接続先を変更
    復旧先の環境に合わせるためにGridDBを使用するアプリの設定変更を行います。

5.2.2.2 手順1 AMIからEC2を復元

AMIよりEC2を作成します。

  • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。

  • バックアップ先リージョンのEC2にて使用するキーペアがない場合、キーペアを作成します。
    AWS マネジメントコンソール「EC2」より「キーペア」をクリックします。

  • [キーペアを作成]をクリックします。

  • 以下の入力を行います。

入力項目 入力値
名前 名前を入力（入力値は任意）（例：key-osk）
プライベートキーファイル形式 .pem

  • [キーペアを作成]をクリックします。

  • キーペアが作成されたことを示すメッセージが表示されます。
    また、.pem のダウンロードが始まりますので、これを保存します。

  • AWS マネジメントコンソール「EC2」より「AMI」をクリックします。

  • バックアップ元リージョンからコピーしたAMIを選択します。
    該当するAMIがどれかはAMI作成時に入力した「説明」を参考に判断します。

  • [起動]クリックします。

  • 以下の入力を行います。

入力項目 入力値
名前 名前を入力（入力値は任意）（例：griddb-node-11）
インスタンスタイプ 任意
キーペア 既存のキーペアを選択
VPC バックアップ先リージョンのVPCを選択
サブネット バックアップ先リージョンのVPCのサブネットを選択
ファイアウォール (セキュリティグループ) 「既存のセキュリティグループを選択する」を選択
バックアップ先リージョンのセキュリティグループを選択
高度な詳細
IAMインスタンスプロフィール		 既存のIAMインスタンスプロフィールを選択
（バックアップ元リージョンのEC2で使用していたものと同じIAMインスタンスプロフィールを選択）

  • [インスタンスを起動]をクリックします。

  • [インスタンスの起動]を開始したことを示すメッセージが表示されます。

5.2.2.3 手順2 EBSスナップショットからの復元およびEC2へのアタッチ

  • AWS マネジメントコンソールのナビゲーションバーで、現在表示されているリージョン名を選択し、バックアップ先リージョン（例：大阪）を選択します。

  • AWS マネジメントコンソール「EC2」より「スナップショット」をクリックします。

  • 復元するスナップショットを選択します。
    スクリプトのサンプルでは、スナップショットの「説明」の値は「DR backup <NODE_NAME>」（例：DR backup NODE21）となります。
    この説明の値と開始日時を参照し、復元するスナップショットを選択します。
    [アクション]->[ボリュームの作成]をクリックします。

  • [ボリュームの作成]をクリックします。

  • AWS マネジメントコンソール「EC2」より「ボリューム」をクリックします。
    復元したボリュームの状態が「available」になれば、ボリュームの作成完了です。

  • ボリューム作成後、EC2にアタッチを行います。

5.2.2.4 手順3 GridDBの設定変更

バックアップ先リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

先の手順で復旧したEC2のIPアドレスは、復旧元のEC2のIPアドレスとは異なるものになります。
そのため、復旧したEC2のIPアドレスに合わせるためにGridDBの設定変更を行います。

  • gs_cluster.json

    • 以下の値を設定します。
    設定項目 入力値
    /cluster/notificationMember[]/cluster/address 復旧したEC2のIPアドレス
    /cluster/notificationMember[]/sync/address （同上）
    /cluster/notificationMember[]/system/address （同上）
    /cluster/notificationMember[]/transaction/address （同上）
    /cluster/notificationMember[]/sql/address （同上）

5.2.2.5 手順4 GridDBクラスタを起動

バックアップ先リージョンのEC2にログインし、gsadmユーザにて作業します。
この作業は、GridDBクラスタを構成するすべてのEC2にて実施する必要があります。

GridDBを起動します。

  • GridDBのノード起動を行います。起動方法は通常のノード起動の方法と同じです。
  • GridDBのクラスタへの参加を行います。参加方法は通常のクラスタ参加の方法と同じです。

5.2.2.6 手順5 アプリの接続先を変更

復旧したEC2のIPアドレスは、復旧元のEC2のIPアドレスとは異なるものになります。
そのため、GridDBへ接続を行うアプリはGridDBの接続先の設定を、復旧したEC2のアドレスに変更する必要があります。

（例）
JDBC接続先設定の
notificationMember=10.5.100.102:20001,10.5.131.249:20001,10.5.251.145:20001
を
notificationMember=<復元したEC2(1つ目)のIPアドレス>:20001,<復元したEC2(2つ目)のIPアドレス>:20001,<復元したEC2(3つ目)のIPアドレス>:20001
に変更
Copyright