メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

Amazon Aurora DB クラスターの管理

以下のセクションでは、Amazon Aurora DB クラスターのパフォーマンス、スケーリング、耐障害性、バックアップ、および復元の管理について説明します。

Aurora DB クラスターのパフォーマンスとスケーリングの管理

ストレージのスケーリング

Aurora ストレージは、クラスターボリューム内のデータに合わせて自動的にスケーリングします。データが増加すると、クラスターボリュームストレージは、10 ギガバイト (GB) 単位で最大 64 TB まで増加します。

クラスターボリュームのサイズは 1 時間ごとにチェックされ、ストレージコストが決定されます。料金についての詳細は、「Amazon RDS 料金表」を参照してください。

Aurora DB インスタンスのスケーリング

Aurora DB インスタンスは、インスタンススケーリングと読み込みのスケーリングの 2 つの方法でスケーリングできます。

インスタンススケーリング

クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、必要に応じて DB クラスターをスケーリングできます。Aurora は、Aurora 用に最適化されたさまざまな DB インスタンスクラスをサポートします。次の表は、インスタンスクラスの指定について説明しています。

インスタンスクラス vCPU ECU メモリ (GB)

db.t2.small

1

1 2

db.t2.medium

2

2 4

db.r3.large

2

6.5 15.25

db.r3.xlarge

4

13 30.5

db.r3.2xlarge

8

26 61

db.r3.4xlarge

16

52 122

db.r3.8xlarge

32

104 244

読み込みのスケーリング

Aurora DB クラスターの読み取りのスケーリングは、最大 15 個の Aurora レプリカを DB クラスター内に作成することで実現できます。各 Aurora レプリカは、最小限のレプリカラグでクラスターボリュームから同じデータを返します。通常、このラグはプライマリインスタンスが更新を書き込んだ後、100 ミリ秒を大幅に下回ります。読み取りトラフィックが増えたら、追加の Aurora レプリカを作成し、それらに直接接続することで DB クラスターの読み取りワークロードを分散できます。Aurora レプリカの DB インスタンスクラスは、プライマリイスタンスと同じものである必要はありません。

Aurora DB インスタンスへの最大接続数

Aurora DB インスタンスへの許可されている接続の最大数は、DB インスタンスのインスタンスレベルのパラメータグループの max_connections パラメータによって決まります。デフォルトでは、この値は次の方程式 (log 関数は log 基数 2 に相当します) に設定されます。

GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})

この方程式に max_connections パラメータを設定するときは、許可されている接続数をインスタンスのサイズに応じて適切に決定するようにします。たとえば、DB インスタンスクラスが db.r3.xlarge だとすると、メモリ量は 30.5 ギガバイト (GB) です。このとき、許可されている最大接続数は次の方程式で示されるように 2,000 です。

Copy
log( (30.5 * 1073741824) / 8187281408 ) * 1000 = 2000

次の表は、Aurora で使用できる DB インスタンスクラスごとの max_connections のデフォルト値です。Aurora DB インスタンスへの許可されている接続の最大数を増やすには、このインスタンスをメモリ量のより多い DB インスタンスクラスに変更するか、または max_connections パラメータの設定値を最大 16,000 まで大きくすることによって可能です。

インスタンスクラス max_connections デフォルト値

db.t2.small

45

db.t2.medium

90

db.r3.large

1,000

db.r3.xlarge

2000

db.r3.2xlarge

3000

db.r3.4xlarge

4000

db.r3.8xlarge

5000

Aurora DB クラスターの耐障害性

Aurora DB クラスターは、耐障害性を持つように設計されています。クラスターボリュームは 1 つのリージョン内の複数のアベイラビリティーゾーンにまたがり、各アベイラビリティーゾーンにはクラスターボリュームデータのコピーが含まれます。この機能は、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 DB クラスターのバックアップと復元

以下のセクションでは、Aurora のバックアップと、AWS マネジメントコンソールを使用した Aurora DB クラスターの復元方法について説明します。

バックアップ

Aurora は、クラスターボリュームを自動的にバックアップし、バックアップ保持期間分の復元データを保持できます。Aurora のバックアップは継続的かつ増分的であるため、バックアップ保持期間の任意の時点にすばやく復元できます。バックアップデータが書き込まれるときに、データベースサービスのパフォーマンスに影響が出たり、中断が発生したりすることはありません。DB クラスターを作成または変更するときに、バックアップ保持期間 (1 ~ 35 日) を指定できます。

バックアップ保持期間を超えたバックアップを保持する場合は、クラスターボリュームの中にデータのスナップショットを作成できます。スナップショットの保存には、Amazon RDS の標準ストレージ料金がかかります。RDS ストレージ料金の詳細については、「Amazon Relational Database Service の料金」を参照してください。

Aurora では、バックアップ保持期間全体の増分復元データを保持するため、必要なのは、バックアップ保持期間を超えて保持するデータのスナップショットを作成することだけです。スナップショットから新しい DB クラスターを作成できます。

データの復元

Aurora が保持するバックアップデータから、または保存した DB クラスターのスナップショットから、新しい Aurora DB クラスターを作成することで、データを回復できます。バックアップデータから作成された DB クラスターの新しいコピーは、バックアップ保持期間内の任意の時点にすばやく復元できます。バックアップ保持期間中の Aurora バックアップが継続的かつ増分的であることは、復元時間を短縮するためにデータのスナップショットを頻繁に作成する必要がないことを意味します。

DB インスタンスの最新または最も早い復元可能時間を判断するには、RDS コンソールでLatest Restorable Time 値または Earliest Restorable Time 値を探します。DB クラスターの最新の復元可能時間は、DB クラスターを復元できる最も直近の時点であり、通常は現在時間の 5 分以内です。最も早い復元時間は、クラスターボリュームをバックアップ保持期間内でどこまで遡って復元できるかを示します。

DB クラスターの復元が完了したことは、Latest Restorable Time または Earliest Restorable Time を確認することでわかります。復元オペレーションが完了するまで、Latest Restorable TimeEarliest Restorable Time の値としては NULL が返されます。Latest Restorable Time または Earliest Restorable Time の値として NULL が返される場合、バックアップまたは復元オペレーションをリクエストすることはできません。

AWS マネジメントコンソールを使用して指定時間に DB クラスターを復元するには

  1. https://console.aws.amazon.com/rds で Amazon Aurora コンソールを開きます。

  2. 左のナビゲーションペインの [Instances] をクリックします。復元する DB クラスターのプライマリインスタンスをクリックして選択します。

  3. [Instance Actions] をクリックし、[Restore To Point In Time] をクリックします。

    [Restore DB Cluster] ウィンドウで、[Use Custom Restore Time] オプションをクリックして選択します。

  4. [Use Custom Restore Time] ボックスに、復元する日時を入力します。

  5. [DB Instance Identifier] ボックスに、復元される新しい DB インスタンスの名前を入力します。

  6. 復元された DB クラスターを起動するには、[Launch DB Cluster] ボタンをクリックします。

データベースのクローン化

データベースクローンを使用して、DB クラスタースナップショットを回復する代わりに、新しい DB クラスターに DB クラスターのデータベースのクローンを作成できます。初めて作成されるとき、クローンデータベースは最小限の追加スペースのみを使用し、ソースデータベースあるいはクローンデータベースのいずれかで変更されたデータとしてのみデータをコピーします。同じ DB クラスターから複数のクローンを作成したり、他のクローンから追加のクローンを作成することもできます。詳細については、「Aurora DB クラスターでのデータベースのクローン作成」を参照してください。

障害挿入クエリを使用した Amazon Aurora のテスト

障害挿入クエリを使用して、Amazon Aurora DB クラスターの耐障害性をテストできます。障害挿入クエリは、Amazon Aurora インスタンスに対して SQL コマンドとして発行され、次のいずれかのイベント発生をシミュレートしてスケジュールすることができます。

  • マスターインスタンスまたは Aurora レプリカのクラッシュ

  • Aurora レプリカの障害

  • ディスクの障害

  • ディスクの輻輳

クラッシュを指定する障害挿入クエリは、Amazon Aurora インスタンスのクラッシュを強制的に発生させます。その他の障害挿入クエリでは、障害イベントのシミュレーションが実行されますが、そのイベントは発生しません。障害挿入クエリを送信する場合、障害イベントのシミュレーションが発生する時間も指定します。

Aurora レプリカのエンドポイントに接続することによって、Aurora レプリカインスタンスの 1 つに障害挿入クエリを送信できます。詳細については、「Aurora エンドポイント」を参照してください。

インスタンスのクラッシュのテスト

ALTER SYSTEM CRASH 障害挿入クエリを使用して、Amazon Aurora インスタンスのクラッシュを強制的に発生させることができます。

この障害挿入クエリでは、フェイルオーバーが発生しません。フェイルオーバーをテストする場合は、RDS コンソールで DB クラスターの [Failover] インスタンスアクションを選択するか、AWS CLI の failover-db-cluster コマンド、または RDS API の FailoverDBCluster アクションを使用できます。

構文

Copy
ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];

オプション

この障害挿入クエリでは、次のクラッシュタイプのいずれかを指定できます。

  • INSTANCEAmazon Aurora インスタンスの MySQL 互換データベースのクラッシュがシミュレートされます。

  • DISPATCHERAurora DB クラスターのマスターインスタンスにあるディスパッチャーのクラッシュがシミュレートされます。ディスパッチャーは Amazon Aurora DB クラスターのクラスターボリュームに対して更新を書き込みます。

  • NODEMySQL 互換データベースと Amazon Aurora インスタンスのディスパッチャーの両方のクラッシュがシミュレートされます。この障害挿入のシミュレーションでは、キャッシュも削除されます。

デフォルトのクラッシュタイプは INSTANCE です。

Aurora レプリカの障害のテスト

ALTER SYSTEM SIMULATE READ REPLICA FAILURE 障害挿入クエリを使用して、Aurora レプリカの障害をシミュレートできます。

Aurora レプリカの障害は、指定した期間で、Aurora レプリカまたは DB クラスター内のすべての Aurora レプリカに対するすべてのリクエストをブロックします。指定した期間が終了すると、影響を受けた Aurora レプリカは自動的にマスターインスタンスと同期されます。

構文

Copy
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE [ TO ALL | TO "replica name" ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

オプション

この障害挿入クエリは、以下のパラメータを取ります。

  • percentage_of_failure障害イベントの発生時にブロックするリクエストの割合。この値は 0 ~ 100 の範囲で指定できます。0 を指定する場合、リクエストはブロックされません。100 を指定する場合、すべてのリクエストがブロックされます。

  • 障害のタイプ – シミュレートする障害のタイプ。DB クラスター内のすべての Aurora レプリカの障害をシミュレートするには、TO ALL を指定します。1 つの Aurora レプリカの障害をシミュレートするには、TO と Aurora レプリカの名前を指定します。デフォルトの障害タイプは TO ALL です。

  • quantityAurora レプリカの障害をシミュレートする時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した単位の期間だけ発生します。たとえば、20 MINUTE と指定すると、シミュレーションは 20 分間実行されます。

    注記

    Aurora レプリカの障害イベントの時間を指定するときには注意が必要です。指定する時間が長すぎ、障害イベントの発生時にマスターインスタンスが大量のデータを書き込んだ場合、Aurora DB クラスターは Aurora レプリカがクラッシュしたものと見なし、レプリカを置き換える可能性があります。

ディスクの障害のテスト

ALTER SYSTEM SIMULATE DISK FAILURE 障害挿入クエリを使用して、Aurora DB クラスターのディスクの障害をシミュレートできます。

ディスク障害のシミュレーションでは、Aurora DB クラスターがランダムにディスクセグメントをエラーとしてマークします。シミュレーションを実行する間、これらのセグメントに対するリクエストはブロックされます。

構文

Copy
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE [ IN DISK index | NODE index ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

オプション

この障害挿入クエリは、以下のパラメータを取ります。

  • percentage_of_failure — 障害イベントの発生時にエラーとしてマークするディスクの割合。この値は 0 ~ 100 の範囲で指定できます。0 を指定すると、ディスクのどの部分もエラーとしてマークされません。100 を指定すると、ディスク全体がエラーとしてマークされます。

  • DISK index — 障害イベントをシミュレートする特定のデータの論理ブロック。利用可能な論理データブロックの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。詳細については、「Aurora DB クラスターのボリュームステータスの表示」を参照してください。

  • NODE index — 障害イベントをシミュレートする特定のストレージノード。利用可能なストレージノードの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。詳細については、「Aurora DB クラスターのボリュームステータスの表示」を参照してください。

  • quantity — ディスクの障害をシミュレートする時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した単位の期間だけ発生します。たとえば、20 MINUTE と指定すると、シミュレーションは 20 分間実行されます。

ディスクの輻輳のテスト

ALTER SYSTEM SIMULATE DISK CONGESTION 障害挿入クエリを使用して、Aurora DB クラスターのディスクの障害をシミュレートできます。

ディスク輻輳のシミュレーションでは、Aurora DB クラスターがランダムにディスクセグメントを輻輳としてマークします。これらのセグメントに対するリクエストは、シミュレーションを実行する間、指定された最小遅延値と最大遅延値の間で遅延します。

構文

Copy
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION BETWEEN minimum AND maximum MILLISECONDS [ IN DISK index | NODE index ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };

オプション

この障害挿入クエリは、以下のパラメータを取ります。

  • percentage_of_failure障害イベントの発生時に輻輳としてマークするディスクの割合。この値は 0 ~ 100 の範囲で指定できます。0 を指定すると、ディスクのどの部分も輻輳としてマークされません。100 を指定すると、ディスク全体が輻輳としてマークされます。

  • DISK index または NODE index障害イベントをシミュレートする特定のディスクまたはノード。ディスクまたはノードのインデックスの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。

  • minimum および maximum輻輳による遅延の最小値と最大値をミリ秒単位で指定します。シミュレーションを実行する間、輻輳としてマークされたディスクセグメントでは、ミリ秒単位の最小値と最大値の間の範囲でランダムな遅延が発生します。

  • quantityディスクの輻輳をシミュレートする時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した時間単位の期間だけ発生します。たとえば、20 MINUTE と指定すると、シミュレーションは 20 分間実行されます。

高速 DDL を使用して Amazon Aurora でテーブルを変更する

MySQL において、何度もデータ操作言語 (DDL) 操作を行うと、パフォーマンスに大きな影響が出ることがあります。最新バージョンのオンライン DDL を使用しても、パフォーマンスへの影響は発生します。

たとえば、ALTER TABLE 操作を使用して列をテーブルに追加するとします。指定されたアルゴリズムによっては、この操作において、以下のことを行う必要が生じる場合があります。

  • テーブルの全体コピーの作成

  • 同時データ操作言語 (DML) オペレーションを処理するための一時テーブルの作成

  • テーブルのすべてのインデックスの再構築

  • 同時 DML 変更適用時のテーブルロックの適用

  • 同時 DML スループットの低下

Amazon Aurora では、高速 DDL を使用して、適切な ALTER TABLE オペレーションをほぼ即時に実行できるようになりました。このオペレーションでは、テーブルをコピーする必要はありません。また、他の DML ステートメントに実体的な影響を及ぼすことなく行うことができます。このオペレーションは、テーブルのコピーに一時ストレージを使用しないため、スモールインスタンスタイプの大きなテーブルに対しても、DDL ステートメントが実用的になります。

注記

高速 DDL は Aurora バージョン 1.12 以降で使用できます。Aurora のバージョンの詳細については、「Amazon Aurora データベースエンジンの更新」を参照してください。

制約事項

現在のところ、高速 DDL には以下の制限があります。

  • 高速 DDL は、デフォルト値を持たない、null が許容される列を、既存の表の末尾に追加する場合にのみ使用できます。

  • 高速 DDL は、パーティション分割されたテーブルをサポートしません。

  • 高速 DDL は、REDUNDANT 列形式を使用する DB テーブルをサポートしません。

構文

Copy
ALTER TABLE tbl_name ADD COLUMN col_name column_definition

オプション

このステートメントには、以下のオプションがあります。

  • tbl_name変更するテーブルの名前。

  • col_name追加する列の名前。

  • col_definition追加する列の定義。

    注記

    null が許容される列の定義を、デフォルト値を使用せずに指定する必要があります。指定しない場合、高速 DDL は使用されません。

Aurora DB クラスターのボリュームステータスの表示

Amazon Aurora において、DB クラスターボリュームは、論理ブロックのコレクションで構成されています。各論理ブロックは、10 ギガバイトの割り当て済みストレージです。これらのブロックは 保護グループ と呼ばれます。

各保護グループのデータは、6 つの物理ストレージデバイス (ストレージノード と呼ばれる) にわたってレプリケートされます。これらのストレージノードは、DB クラスターがあるリージョン内の 3 つのアベイラビリティーゾーン (AZ) に割り当てられます。また、各ストレージノードには、DB クラスターボリュームに対する 1 つ以上の論理データブロックが含まれます。保護グループおよびストレージノードの詳細については、AWS データベースブログの「Aurora ストレージエンジンの概要」を参照してください。

ストレージノード全体、またはストレージノード内の単一の論理データブロックの障害をシミュレートできます。シミュレートするには、ALTER SYSTEM SIMULATE DISK FAILURE の障害挿入クエリを使用します。このクエリで、特定の論理データブロックまたはストレージノードのインデックス値を指定します。ただし、DB クラスターボリュームで使用されている論理データブロックまたはストレージノードの数より大きいインデックス値を指定すると、クエリよりエラーが返ります。障害挿入クエリの詳細については、「障害挿入クエリを使用した Amazon Aurora のテスト」を参照してください。

このエラーは、SHOW VOLUME STATUS クエリを使用して回避できます。クエリより、2 つのサーバーのステータス変数 (Disks および Nodes) が返ります。これらの変数は、DB クラスターボリュームに対する論理データブロックとストレージノードの各合計数を表しています。

注記

SHOW VOLUME STATUS クエリは、Aurora バージョン 1.12 以降で使用できます。Aurora のバージョンの詳細については、「Amazon Aurora データベースエンジンの更新」を参照してください。

構文

Copy
SHOW VOLUME STATUS

以下の例では、SHOW VOLUME STATUS の一般的な結果を示しています。

mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks         | 96    |
| Nodes         | 74    |
+---------------+-------+