翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Keyspaces point-in-timeでの復旧の仕組み

このセクションでは、Amazon Keyspaces point-in-time リカバリ (PITR) の仕組みの概要を説明します。料金の詳細については、「Amazon Keyspaces (for Apache Cassandra) pricing (Amazon Keyspaces (Apache Cassandra 向け) の料金)」を参照してください。

PITR 継続的バックアップの時間枠

Amazon Keyspaces PITRは、テーブルに対して復元可能なバックアップが利用できる期間を維持するために、2 つのタイムスタンプを使用します。

PITR を有効にするEarliestRestorableDateTimeと、 と の間の任意の時点に復元できますCurrentTime。テーブルデータは、 が有効になっていPITRる時点にのみ復元できます。

を無効にPITRして後で再度有効にする場合は、最初に使用可能なバックアップの開始時刻を が再度有効PITRになった時点にリセットします。つまり、 を無効にするとバックアップ履歴がPITR消去されます。

復元するテーブルはアクティブでなくても構いません。削除されたテーブルで が有効になっていて、バックアップウィンドウ内 (または過去 35 日間) に削除が発生した場合は、削除PITRされたテーブルを復元することもできます。

PITR 設定の復元

を使用してテーブルを復元するとPITR、Amazon Keyspaces は、選択したタイムスタンプ (day:hour:minute:second) に基づいてソーステーブルのスキーマとデータを新しいテーブルに復元します。 PITRは既存のテーブルを上書きしません。

テーブルのスキーマとデータに加えて、 はソーステーブルcustom_propertiesから をPITR復元します。カスタムプロパティについては、最古の復元時刻から現在の時刻までの範囲で選択したタイムスタンプに基づいて復元されるテーブルのデータとは異なり、常に現在の時刻のテーブル設定に基づいて復元されます。

復元されたテーブルの設定は、タイムスタンプが復元開始時であるソーステーブルの設定と一致します。これらの設定は復元中にオーバーライドすることができるので、その場合は WITH custom_properties を使用します。カスタムプロパティには以下の設定が含まれます。

テーブルがプロビジョンドキャパシティモードで、自動スケーリングが有効になっている場合、復元オペレーションはテーブルの自動スケーリング設定も復元します。これらは、 の autoscaling_settingsパラメータCQLまたは autoScalingSpecificationを使用して上書きできますCLI。自動スケーリング設定の詳細については、「Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する」を参照してください。

テーブル全体を復元する場合、復元済みテーブルのすべてのテーブル設定は、復元時の送信元のテーブルの現在の設定から取得されます。

たとえば、テーブルのプロビジョニングされたスループットが 50 読み込みキャパシティーユニットおよび 50 書き込みキャパシティーユニットに最近下げられたとします。その後、このテーブルを 3 週間前の状態に復元します。このとき、プロビジョンドスループットの読み取りキャパシティユニットは 100 に、書き込みキャパシティユニットも 100 に設定されました。この場合、Amazon Keyspaces では、テーブルデータは指定の時点の状態に復元されますが、プロビジョンドスループット設定は最新の設定 (読み取りキャパシティユニット 50、書き込みキャパシティユニット 50) が使用されます。

次の設定は復元されないため、新しいテーブルに対して手動で設定する必要があります。

PITR 暗号化されたテーブルの復元

を使用してテーブルを復元するとPITR、Amazon Keyspaces はソーステーブルの暗号化設定を復元します。テーブルが AWS 所有のキー （デフォルト) で暗号化されている場合、テーブルは同じ設定で自動的に復元されます。復元するテーブルがカスタマーマネージドキーを使用して暗号化されている場合は、テーブルデータを復元するために同じカスタマーマネージドキーを使用して Amazon Keyspaces にアクセスできる必要があります。

テーブルの暗号化設定は復元時に変更できます。から AWS 所有のキー カスタマーマネージドキーに変更するには、復元時に有効でアクセス可能なカスタマーマネージドキーを指定する必要があります。

カスタマーマネージドキーから に変更する場合は AWS 所有のキー、Amazon Keyspaces がソーステーブルのカスタマーマネージドキーにアクセスして、 でテーブルを復元できることを確認します AWS 所有のキー。テーブルの保管データ暗号化設定の詳細については、「保管データ暗号化: Amazon Keyspaces での動作」を参照してください。

PITR マルチリージョンテーブルの復元

を使用してマルチリージョンテーブルを復元できますPITR。復元操作を正常に行うには、ソーステーブルとターゲットテーブルの両方を同じ AWS リージョンに複製する必要があります。

Amazon Keyspaces は、キースペースに含まれるレプリケート先の各リージョンでソーステーブルの設定を復元します。復元操作中に設定を上書きすることもできます。復元中に変更できる設定の詳細については、「PITR 設定の復元」を参照してください。

マルチリージョンレプリケーションの詳細については、「」を参照してくださいAmazon Keyspaces でのマルチリージョンレプリケーションの仕組み。

PITR ユーザー定義タイプを使用したテーブルの復元 (UDTs）

を使用するテーブルを復元できますUDTs。復元オペレーションを成功させるには、参照される UDTsが存在し、キースペースで有効である必要があります。

テーブルの復元時に必要な がない場合、Amazon Keyspaces UDTは自動的にUDTスキーマの復元を試み、テーブルの復元を続行します。

を削除して再作成した場合UDT、Amazon Keyspaces は の新しいスキーマUDTで を復元UDTし、元のUDTスキーマを使用してテーブルを復元するリクエストを拒否します。この場合、古いUDTスキーマでテーブルを復元する場合は、テーブルを新しいキースペースに復元できます。を削除して再作成するとUDT、再作成された のスキーマUDTが削除された のスキーマと同じであってもUDT、再作成された UDTは新しい と見なされますUDT。この場合、Amazon Keyspaces は古いUDTスキーマでテーブルを復元するリクエストを拒否します。

UDT が欠落していて、Amazon Keyspaces が の復元を試みた場合UDT、リージョン内のアカウントの の最大数に達した場合UDTs、試行は失敗します。

UDT クォータとデフォルト値の詳細については、「」を参照してくださいAmazon Keyspaces のユーザー定義タイプ (UDTs) のクォータとデフォルト値。UDTs の使用方法の詳細については、「Amazon Keyspaces のユーザー定義タイプ (UDTs）」を参照してください。

を使用したテーブルの復元時間 PITR

テーブルの復元にかかる時間は複数の要因に基づいており、テーブルのサイズに直接関連しているとは限りません。

復元時間に関する考慮事項を次に示します。

災害対策を計画する際のベストプラクティスは、平均復元完了時間を定期的に記録し、これらの時間が目標復旧時間全体にどのように影響するかを確認することです。

Amazon Keyspaces PITRと AWS サービスとの統合

次のPITRオペレーションは、 を使用してログに記録され AWS CloudTrail 、継続的なモニタリングと監査を有効にします。

詳細については、「を使用した Amazon Keyspaces API呼び出しのログ記録 AWS CloudTrail」を参照してください。

を使用して次のPITRアクションを実行できます AWS CloudFormation。

詳細については、『AWS CloudFormation ユーザーガイド』の「Cassandra Resource Type Reference(Cassandra リソースタイプのリファレンス)」を参照してください。