Aurora DB クラスターのバックアップと復元の概要
以下のセクションでは、Aurora のバックアップと、AWS マネジメントコンソールを使用した Aurora DB クラスターの復元方法に関する情報を示します。
Aurora DB クラスターの耐障害性
Aurora DB クラスターは、耐障害性を持つように設計されています。クラスターボリュームは 1 つの AWS リージョン内の複数のアベイラビリティーゾーンにまたがり、各アベイラビリティーゾーンにはクラスターボリュームデータのコピーが含まれます。この機能は、DB クラスターがデータ喪失なしでアベイラビリティーゾーンの障害に耐えることができ、発生するのはサービスの短時間の中断のみであることを意味します。
シングルマスターレプリケーションを使用した DB クラスターのプライマリインスタンスが失敗した場合、Aurora は以下のいずれかの方法で、新しいプライマリインスタンスに自動的にフェイルオーバーします。
-
既存の Aurora レプリカを新しいプライマリインスタンスに昇格する
-
新しいプライマリインスタンスを作成する
DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、一般的なサービスの復元時間は 120 秒未満であり、多くの場合 60 秒未満で復元されます。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で少なくとも 1 つ以上の Aurora レプリカを作成することをお勧めします。
各レプリカに優先度を割り当てることで、Aurora レプリカがプライマリインスタンスに昇格される順序をカスタマイズできます。優先度の範囲は、最も高い 0 から最も低い 15 までです。プライマリインスタンスが失敗した場合、Amazon RDS は優先度が高い Aurora レプリカを新しいプライマリインスタンスに昇格します。Aurora レプリカの優先度はいつでも変更できます。優先度を変更しても、フェイルオーバーはトリガーされません。
複数の Aurora レプリカで同じ優先度を共有でき、その場合は昇格階層が発生します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。
DB クラスターに Aurora レプリカが含まれていない場合、障害イベントの発生時にプライマリインスタンスが再作成されます。障害イベントによって中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。新しいプライマリインスタンスが再作成されると、サービスが回復します。これは、通常は 10 分未満で行われます。Aurora レプリカのプライマリインスタンスへの昇格は、新しいプライマリインスタンスの作成よりもはるかに短時間で実行されます。
注記
Amazon Aurora では、外部 MySQL データベースまたは RDS MySQL DB インスタンスとのレプリケーションもサポートします。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション」を参照してください。
バックアップ
Aurora は、クラスターボリュームを自動的にバックアップし、バックアップ保持期間分の復元データを保持できます。Aurora のバックアップは継続的かつ増分的であるため、バックアップ保持期間の任意の時点にすばやく復元できます。バックアップデータが書き込まれるときに、データベースサービスのパフォーマンスに影響が出たり、中断が発生したりすることはありません。DB クラスターを作成または変更するときに、バックアップ保持期間 (1 ～ 35 日) を指定できます。
バックアップ保持期間を超えたバックアップを保持する場合は、クラスターボリュームの中にデータのスナップショットを作成できます。Aurora では、バックアップ保持期間全体の増分復元データを保持するため、必要なのは、バックアップ保持期間を超えて保持するデータのスナップショットを作成することだけです。スナップショットから新しい DB クラスターを作成できます。
注記
-
Amazon Aurora DB クラスターの場合、DB クラスターの作成方法に関係なく、デフォルトのバックアップ保持期間は 1 日です。
-
Aurora の自動バックアップを無効にすることはできません。Aurora のバックアップ保持期間は、DB クラスターによって管理されます。
バックアップストレージのコストは、保持する Aurora バックアップおよびスナップショットのデータとその保持期間に応じて異なります。Aurora バックアップおよびスナップショットに伴うストレージの詳細については、「Aurora バックアップストレージの使用状況を確認する」を参照してください。Aurora バックアップストレージの料金情報については、「Amazon RDS for Aurora の料金」を参照してください。Aurora クラスターを削除した後で、このクラスターに関連するスナップショットを保存すると、Aurora の標準のバックアップストレージ料金が発生します。
データの復元
Aurora が保持するバックアップデータから、または保存した DB クラスターのスナップショットから、新しい Aurora DB クラスターを作成することで、データを回復できます。バックアップデータから作成された DB クラスターの新しいコピーは、バックアップ保持期間内の任意の時点にすばやく復元できます。バックアップ保持期間中の Aurora バックアップが継続的かつ増分的であることは、復元時間を短縮するためにデータのスナップショットを頻繁に作成する必要がないことを意味します。
DB インスタンスの最新の復元可能時刻または最も早い復元可能時刻を判断するには、RDS コンソールでLatest Restorable Time 値または Earliest Restorable Time 値を探します。これらの値の表示については、「Amazon Aurora DB クラスターの表示」を参照してください。DB クラスターの最新の復元可能時間は、DB クラスターを復元できる最も直近の時点であり、通常は現在時間の 5 分以内です。最も早い復元時間は、クラスターボリュームをバックアップ保持期間内でどこまで遡って復元できるかを示します。
DB クラスターの復元が完了したことは、Latest Restorable Time および Earliest Restorable Time の値を確認することでわかります。復元オペレーションが完了するまで、Latest Restorable Time と Earliest Restorable
Time の値としては NULL が返されます。Latest Restorable
Time または Earliest Restorable Time が NULL を返す場合、バックアップまたは復元オペレーションをリクエストすることはできません。
DB クラスターを指定の時点の状態に復元する方法については、「特定の時点への DB クラスターの復元」を参照してください。
Aurora 用のデータベースのクローン作成
DB クラスターのスナップショットを復元する代わりに、データベースのクローン作成により Aurora DB クラスターのデータベースのクローンを新しい DB クラスターに作成することもできます。クローンデータベースの初回作成時に使用する追加スペースは最小限です。ソースデータベースまたはクローンデータベースのいずれかでデータが変更された場合に限り、データがコピーされます。同じ DB クラスターから複数のクローンを作成したり、他のクローンから追加のクローンを作成することもできます。詳細については、「Aurora DB クラスターでのデータベースのクローン作成」を参照してください。
バックトラック
Aurora MySQL が、バックアップからデータを復元しないで、DB クラスターを特定の時刻に「巻き戻し」することができるようになりました。詳細については、「Aurora DB クラスターのバックトラック」を参照してください。
