特定時点へのバックアップの復元

特定時点の復元では、コミット・ログ・アーカイブを使用し、OpsCenterを使用してバックアップから特定の日時のデータを復元します。

特定時点の復元の場合、OpsCenterは、クラスターを復元する日時に基づいて、どのスナップショットとコミット・ログから復元するかをインテリジェントに選択します。スナップショットとコミット・ログの使用可能な組み合わせが見つからない場合、復元は失敗します。詳細なエラー・メッセージがOpsCenter UIの［Activity］セクションに表示されます。

dse-env.sh

dse-env.shファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストール：/etc/dse/dse-env.sh
tarボール・インストール：install_location/dse/dse-env.sh

始める前に

特定時点の復元を行うには、コミットログ・バックアップを有効にし、復元する日時の前に少なくとも1つのスナップショット・バックアップを実行している必要があります。
Backup Service（バックアップ・サービス）の復元機能では、sstableloaderユーティリティを使用しています。このユーティリティでは、現在、復元する前にすべてのノードでThriftサーバーを有効にする必要があります。復元する前にすべてのノードでThriftサーバーが有効になっていることを確認してください。
特定時点の復元を実行する場合、バックアップ後にクラスター・トポロジーを変更しないでください。トポロジーが変更されたクラスターで特定時点の復元を実行しようとすると、失敗します。クラスター・トポロジーを変更する前に、スナップショット・バックアップを実行することを推奨します。その場合、そのバックアップに基づいてクラスターを復元できます。
既知の制限事項：
- 特定時点の復元では、Cassandra 2.1以降とDataStaX Enterprise 4.7以降で再作成する必要のあるキースペースまたはテーブルのコミット・ログを復元できません。
- 実際の特定時点の復元の期間中にテーブルが再作成されると、特定時点の復元は失敗します。

重要: Backup Service（バックアップ・サービス）は、デスティネーションの場所のデータと構造を制御する必要があります。AWS S3バケットとローカル・ファイル・システムのデスティネーションは、OpsCenterのみの専用とする必要があります。これらのデスティネーションに他のディレクトリーやファイルを追加すると、Backup Service（バックアップ・サービス）がバックアップ操作または復元操作を適切に実行できなくなる可能性があります。

手順

クラスター名 > ［Services］をクリックします。
Backup Service（バックアップ・サービス）の［Details］リンクをクリックします。
［Restore Backup］をクリックします。
［Restore from Backup］ダイアログの［Step 1 of 2: Select Backup］が表示されます。
［Point In Time］タブをクリックします。
以下の選択を行います。
1. 必須: 特定時点：データを復元する日時を設定します。
2. 必須: コミット・ログの場所：コミット・ログの場所を、サーバー内、ローカル・ファイル・システム、またはAmazon S3の別の場所のいずれかから選択します。コミット・ログの場所は、コミット・ログ・バックアップが有効になっている場合に構成します。
3. 必須: バックアップ場所：スナップショットの場所を、サーバー内、ローカル・ファイル・システム、またはAmazon S3のいずれかから選択します。別の場所を追加するには、［+Add Location］リンクをクリックします。
4. ［Next］をクリックします。
  ［Restore from Backup］ダイアログの［Step 2 of 2: Configure and Restore］が表示されます。
以下の選択を行います。
1. 必須: キースペース：バックアップに含まれている、復元するテーブルを選択します。キースペースのすべてのテーブルを含めるには、キースペース名をクリックします。すべてのキースペースを復元するには、［All Keyspaces］をクリックします。
  特定のテーブルのみを選択するには、キースペース名を展開してテーブルを選択します。
  注: バックアップの作成と復元を行う場合、以下の点に注意してください。
  - システム・キースペースのみを含むスナップショットを復元することはできません。復元するスナップショットには、システムと非システム・キースペースの両方が含まれているか、非システム・キースペースのみが含まれている必要があります。
  - テーブル定義を含まないスナップショットを復元することはできません。
  - スナップショットを十分なディスク領域がない場所に復元すると失敗します。復元レポートには、十分な領域がないノードと、復元を正常に行うために必要な領域が表示されます。予防措置の詳細とヒントについては、「バックアップを復元するための十分なディスク領域の監視」を参照してください。
2. ［Location:］で復元するデータのターゲット・クラスターを選択します。
  - ［Location］リストは、複数のクラスターがあり、両方のクラスターが同じOpsCenterインスタンスで管理されている場合にのみ表示されます。
  - バックアップしたクラスターとは異なるクラスターを選択すると、選択したクラスターにデータが複製されます。「クラスター・データの複製」を参照してください。
  注: 暗号化キーが同一でない限り（通常は同一ではない）、暗号化されたテーブルを別のクラスターに復元しても正しく動作しません。
3. オプション: データを復元する前に既存のキースペース・データを削除するには、［Truncate/delete existing data before restore］を選択します。これによって、復元するキースペースに対し、クラスター内の更新データが完全に削除されます。
4. オプション: ネットワークの過負荷を防ぐには、復元の最大転送速度を設定します。［Throttle stream throughput at ____ MB］を選択し、1秒あたりの最大メガバイト数を設定します。
5. オプション: 必要に応じてaddress.yamlのbackup_staging_directory構成オプションを設定して、ステージング・ディレクトリーを変更します。
6. オプション: ローリング再起動の設定を調整するには、［Edit Restart Settings］リンクをクリックします。
［Restore Backup］をクリックします。
［Confirm Restore］ダイアログが表示されます。
警告: 8でストリーム出力をスロットルするための値を設定していない場合、スロットルされていない復元の影響を示す警告メッセージが表示されます。スロットル警告は、4.8.7以降のバージョンのDSEでのみ表示されます。［Cancel］をクリックして［Restore from Backup］ダイアログでスロットル値を設定するか、cassandra.yaml（stream_throughput_outbound_megabits_per_secおよびinter_dc_stream_throughput_outbound_megabits_per_sec）の値を設定するか、ネットワークのボトルネックのリスクを承知した上で続行します。
ヒント: LCMを使用してDSEクラスター構成を管理している場合は、そのクラスターの構成プロファイルのcassandra.yamlのクラスター通信設定を更新して、構成ジョブを実行します。ストリーム・スループット（データ・センター間ではない）は、LCMのデフォルトで既に200に設定されています。
プロンプトが表示されたら確認し、［Start Restore］をクリックします。

タスクの結果

OpsCenterはバックアップ・データを取得し、そのデータをクラスター内のノードに送信します。通常のスナップショットの復元と同じプロセスに従って、スナップショットの復元が最初に完了します。スナップショットの復元が正常に完了すると、OpsCenterはすべてのエージェントに並列処理で必要なコミット・ログをダウンロードし、その後にクラスター全体でコミット・ログのリプレイをローリングするよう指示します。各ノードはリプレイ用に構成され、前のノードが正常に終了した後に再起動されます。

テーブルのサブセットに対する特定時点の復元中にエラーが発生した場合は、一部のクラスター・ノードに行った変更を手動で戻す必要がある場合があります。ノードをクリーンアップするには、dse-env.shを編集し、JVM_OPTSを指定する最後の行を削除します。例を次に示します。

export JVM_OPTS="$JVM_OPTS -Dcassandra.replayList=Keyspace1.Standard1"