# Amazon Aurora MySQL の管理
以下のセクションでは、Amazon Aurora MySQL DB クラスターの管理について説明します。
**Topics**
+ [Amazon Aurora MySQL のパフォーマンスとスケーリングの管理](AuroraMySQL.Managing.Performance.md)
+ [Aurora DB クラスターのバックトラック](AuroraMySQL.Managing.Backtrack.md)
+ [障害挿入クエリを使用した Amazon Aurora MySQL のテスト](AuroraMySQL.Managing.FaultInjectionQueries.md)
+ [高速 DDL を使用して Amazon Aurora のテーブルを変更する](AuroraMySQL.Managing.FastDDL.md)
+ [Aurora MySQL DB クラスターのボリュームステータスの表示](AuroraMySQL.Managing.VolumeStatus.md)
# Amazon Aurora MySQL のパフォーマンスとスケーリングの管理
## Aurora MySQL DB インスタンスのスケーリング
Aurora MySQL DB インスタンスは、インスタンススケーリングと読み取りスケーリングの 2 つの方法でスケールできます。読み取りスケーリングの詳細については、「[読み取りのスケーリング](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling)」を参照してください。
DB クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、Aurora MySQL DB クラスターをスケーリングできます。Aurora MySQL は、Aurora 用に最適化された複数の DB インスタンスクラスをサポートしています サイズが 40 TB より大きい Aurora クラスターには、db.t2 または db.t3 インスタンスクラスを使用しないでください。Aurora MySQL でサポートされている DB インスタンスクラスの詳細な仕様については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
**注記**
T DB インスタンスクラスは、開発サーバーおよびテストサーバー、またはその他の本稼働以外のサーバーにのみ使用することをお勧めします。T インスタンスクラスの詳細については、「[開発やテストのための T インスタンスクラスの使用](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium)」を参照してください。
## Aurora MySQL DB インスタンスへの最大接続数
Aurora MySQL DB インスタンスへの許可されている接続の最大数は、DB インスタンスのインスタンスレベルパラメータグループの `max_connections` パラメータによって決まります。
次の表は、Aurora MySQL で使用できる DB インスタンスクラスごとの `max_connections` のデフォルト値です。Aurora MySQL DB インスタンスへの接続の最大数を増やすには、このインスタンスをメモリ量のより多い DB インスタンスクラスにスケールするか、インスタンスの DB パラメータグループの `max_connections` パラメータの値を最大 16,000 に設定できます。
**ヒント**
アプリケーションが頻繁に接続を開いたり閉じたりする場合や、長時間の接続を多数開いたままにする場合は、Amazon RDS Proxy の使用を推奨します。RDS Proxy は、接続プーリングを使用してデータベース接続を安全かつ効率的に共有する、フルマネージドの高可用性データベースプロキシです。RDS Proxy の詳細については、[Amazon RDS Proxy for Aurora](rds-proxy.md) を参照してください。
Aurora Serverless v2 インスタンスによるこのパラメータの処理方法については、「[Aurora Serverless v2 の最大接続数](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections)」を参照してください。
| インスタンスクラス | max\$1connections のデフォルト値 |
| --- | --- |
| db.t2.small | 45 |
| db.t2.medium | 90 |
| db.t3.small | 45 |
| db.t3.medium | 90 |
| db.t3.large | 135 |
| db.t4g.medium | 90 |
| db.t4g.large | 135 |
| db.r3.large | 1,000 |
| db.r3.xlarge | 2000 |
| db.r3.2xlarge | 3000 |
| db.r3.4xlarge | 4000 |
| db.r3.8xlarge | 5000 |
| db.r4.large | 1,000 |
| db.r4.xlarge | 2000 |
| db.r4.2xlarge | 3000 |
| db.r4.4xlarge | 4000 |
| db.r4.8xlarge | 5000 |
| db.r4.16xlarge | 6000 |
| db.r5.large | 1,000 |
| db.r5.xlarge | 2000 |
| db.r5.2xlarge | 3000 |
| db.r5.4xlarge | 4000 |
| db.r5.8xlarge | 5000 |
| db.r5.12xlarge | 6000 |
| db.r5.16xlarge | 6000 |
| db.r5.24xlarge | 7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6000 |
| db.r6g.16xlarge | 6000 |
| db.r6i.large | 1,000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6000 |
| db.r6i.16xlarge | 6000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1,000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6000 |
| db.r7g.16xlarge | 6000 |
| db.r7i.large | 1,000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6000 |
| db.r7i.16xlarge | 6000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1,000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6000 |
| db.r8g.16xlarge | 6000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
**ヒント**
`max_connections` パラメータ計算では、選択した Aurora MySQL インスタンスクラスで 2 を底とする対数 (自然対数とは異なる) とバイト単位の `DBInstanceClassMemory` 値を使用します。パラメータは整数値のみを受け入れ、小数点以下は計算から切り捨てられます。この式は、次のように接続制限を実装します。
より大きな R3、R4、R5 インスタンスの場合は 1,000 ごとの接続の増分
T2 および T3 インスタンスメモリバリアントの場合は 45 ごとの接続の増分
例: db.r6g.large の場合、式の計算は 1,069.2 となりますが、システムは 1,000 を実装して一貫した増分パターンを維持します。
接続制限のデフォルトをカスタマイズする新しいパラメータグループを作成すると、`DBInstanceClassMemory` 値に基づく式を使用してデフォルトの接続制限が取得されます。前の表で示されているように、式は、メモリが段階的により大きな R3、R4、R5 インスタンスへと倍増すると 1000 ごとに増える接続最大数を、また T2 インスタンス、および T3 インスタンスの異なるメモリサイズでは 45 ごとに増える接続最大数を生成します。
`DBInstanceClassMemory` を計算する方法の詳細については、「[DB パラメータの指定](USER_ParamValuesRef.md)」を参照してください。
Aurora MySQL と RDS for MySQL DB インスタンスには、異なる量のメモリオーバーヘッドがあります。したがって、同じインスタンスクラスを使用する RDS for MySQL DB インスタンスと Aurora MySQL インスタンスでは、`max_connections` 値が異なる場合があります。テーブルの値は Aurora MySQL DB インスタンスにのみ適用されます。
**注記**
T2 インスタンス、および T3 インスタンスの接続制限がかなり低いのは、Aurora では、これらのインスタンスが本番稼働のワークロードのためではなく、開発やテストシナリオのみを目的としているためです。
デフォルトの接続制限は、バッファプールやクエリのキャッシュといった多くのメモリを消費する他の処理のデフォルト値を使用するシステムに合わせて調整されています。クラスターのこれらの他の設定を変更する場合は、DB インスタンスで使用可能なメモリの増減に応じて接続制限を調整することを検討してください。
## Aurora MySQL 用の一時ストレージの制限
Aurora MySQL は、Aurora ストレージサブシステムにテーブルとインデックスを格納します。Aurora MySQL は、非永続的な一時ファイルや非 InnoDB 一時テーブル用に、別個の一時ストレージまたはローカルストレージを使用します。ローカルストレージには、クエリ処理中の大きなデータセットのソートや、インデックスの作成オペレーションなどの目的に使用するファイルも含まれます。InnoDB 一時テーブルは含まれません。
Aurora MySQL バージョン 3 の一時テーブルの詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。バージョン 2 の一時テーブルの詳細については、「[Aurora MySQL バージョン 2 での一時テーブルスペースの動作](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.TempTables57)」を参照してください。
これらのボリュームのデータと一時ファイルは、DB インスタンスの起動時と停止時、およびホストの交換時に失われます。
これらのローカルストレージボリュームは、Amazon Elastic Block Store (EBS) によってバックアップされ、より大きな DB インスタンスクラスを使用することで拡張できます。ストレージの詳細については、「[Amazon Aurora ストレージ](Aurora.Overview.StorageReliability.md)」を参照してください。
ローカルストレージは、`LOAD DATA FROM S3` や `LOAD XML FROM S3` を使用して Amazon S3 からデータをインポートする場合や、SELECT INTO OUTFILE S3 を使用して S3 にデータをエクスポートする場合にも使用します。S3 からのインポートと S3 へのエクスポートの詳細については、以下を参照してください。
+ [Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード](AuroraMySQL.Integrating.LoadFromS3.md)
+ [Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存](AuroraMySQL.Integrating.SaveIntoS3.md)
Aurora MySQL は、ほとんどの Aurora MySQL DB インスタンスクラス (db.t2、db.t3、db.t4g などのバーストパフォーマンスインスタンスクラスタイプは除く) のエラーログ、一般ログ、スロークエリログ、監査ログに別個の永続ストレージを使用します。このボリュームのデータは、DB インスタンスの起動時や停止時、ホストの交換時に保持されます。
また、この永続的ストレージボリュームは Amazon EBS-backed であり、DB インスタンスクラスに応じた固定サイズを持ちます。より大きな DB インスタンスクラスを使用して拡張することはできません。
次の表は、Aurora MySQL DB インスタンスクラス別に使用可能な一時ストレージと永続的ストレージの最大量を示しています。Aurora の DB インスタンスクラスサポートの詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
| DB インスタンスクラス | 使用可能な一時ストレージ/ローカルストレージの最大量 (GiB) | ログファイルに使用可能な追加のストレージの最大量 (GiB) |
| --- | --- | --- |
| db.x2g.16xlarge | 1280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
**重要**
これらの値は、各 DB インスタンスの理論上の最大空きストレージ量を表します。実際に使用可能なローカルストレージは、これより小さい場合があります。Aurora は、管理プロセスにローカルストレージを使用します。DB インスタンスでは、データをロードする前でもローカルストレージを使用します。特定の DB インスタンスで使用できる一時ストレージをモニタリングするには、 `FreeLocalStorage` CloudWatch メトリクスを使用できます。詳細については、[Amazon Aurora の Amazon CloudWatch メトリクス](Aurora.AuroraMonitoring.Metrics.md) を参照してください。現時点での空きストレージの量を確認できます。空きストレージの量を時間の経過に合わせてグラフ化することもできます。時間の経過に合わせて空きストレージをモニタリングすると、値が増加または減少しているかどうかを判断したり、最小値、最大値、または平均値を確認したりするのに役立ちます。
(これは Aurora Serverless v2 には適用されません。)
# Aurora DB クラスターのバックトラック
Amazon Aurora MySQL 互換エディション では、バックアップからデータを復元しないで、DB クラスターを特定の時刻までバックトラックできます。
**Contents**
+ [バックトラックの概要](#AuroraMySQL.Managing.Backtrack.Overview)
+ [バックトラックウィンドウ](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [バックトラック時間](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [バックトラックの制限事項](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [利用可能なリージョンとバージョン](#AuroraMySQL.Managing.Backtrack.Availability)
+ [バックトラック対応クラスターのアップグレードに関する考慮事項](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Aurora MySQL DB クラスターのバックトラックの設定](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Aurora MySQL DB クラスターのバックトラックの実行](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Aurora MySQL DB クラスターのバックトラックのモニタリング](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [コンソールを使用したバックトラックイベントへのサブスクライブ](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [既存のバックトラックの取得](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Aurora MySQL DB クラスターのバックトラックの無効化](AuroraMySQL.Managing.Backtrack.Disabling.md)
## バックトラックの概要
バックトラックは、指定した時間まで DB クラスターを「巻き戻し」ます。バックトラックは、DB クラスターをバックアップして特定の時点の状態に復元する操作に代わるものではありません。ただし、バックトラックは、従来のバックアップと復元に比べて、以下の利点があります。
+ 簡単にエラーを取り消すことができます。WHERE 句なしの DELETE などの破壊的なアクションを間違えて実行した場合、サービスの中断を最小限に抑えながら、破壊的なアクション以前の時点まで DB クラスターをバックトラックできます。
+ DB クラスターのバックトラックは迅速に実行できます。DB クラスターを特定の時点の状態に復元するには、新しい DB クラスターを起動し、これに対してバックアップデータや DB クラスターのスナップショットから復元する必要があり、時間がかかります。DB クラスターのバックトラックでは、新しい DB クラスターを作成せずに、DB クラスターを数分で巻き戻します。
+ 以前のデータの変更を調べることができます。DB クラスターを前後に繰り返しバックトラックして、特定のデータの変更がどの時点で発生したかを確認できます。例えば、DB クラスターを 3 時間前までバックトラックし、そこから 1 時間後まで戻すことができます。この場合、バックトラック時間は元の時間の 2 時間前となります。
**注記**
DB クラスターを特定の時点の状態に復元する方法については、「[Aurora DB クラスターのバックアップと復元の概要](Aurora.Managing.Backups.md)」を参照してください。
### バックトラックウィンドウ
バックトラックには、ターゲットバックトラックウィンドウと実際のバックトラックウィンドウがあります。
+ *ターゲットバックトラックウィンドウ*は、DB クラスターをバックトラックする所望時間です。*ターゲットバックトラックウィンドウ*は、バックトラックを有効化するときに指定します。例えば、DB クラスターを 1 日バックトラックする場合は、ターゲットバックトラックウィンドウとして 24 時間を指定します。
+ *実際のバックトラックウィンドウ*は、DB クラスターを実際にバックトラックできる時間であり、ターゲットバックトラックウィンドウより小さい値になることがあります。実際のバックトラックウィンドウは、ワークロードとストレージ (*変更レコード*と呼ばれるデータベースの変更に関する情報を保存) に基づきます。
バックトラックが有効になっている Aurora DB クラスターを更新すると、変更レコードが生成されます。Aurora は、ターゲットのバックトラックウィンドウの変更レコードを保持します。変更レコードの保存には利用料金 (時間単位) が発生します。DB クラスターのターゲットバックトラックウィンドウとワークロードの両方により、保存する変更レコード数が決まります。ワークロードは、特定の時間内に DB クラスターを変更する回数です。ワークロードが重い場合は、ワークロードが軽い場合と比べて、バックトラックウィンドウに保存される変更レコードが多くなります。
ターゲットバックトラックウィンドウは、DB クラスターをバックトラックできる最大の目標時間と考えることができます。通常、指定した最大時間までバックトラックできます。ただし、状況によっては、DB クラスターに保存できる変更レコードの数が少なくて、最大時間までバックトラックできない場合があります。この場合、実際のバックトラックウィンドウはターゲットより小さくなります。通常、DB クラスターのワークロードが非常に重い場合、実際のバックトラックウィンドウはターゲットより小さくなります。実際のバックトラックウィンドウがターゲットより小さい場合は、通知が送信されます。
DB クラスターのバックトラックが有効になっている場合、DB クラスターに保存されているテーブルを削除すると、そのテーブルは Aurora のバックトラック変更レコード内に保持されます。これにより、テーブルを削除する前の時点まで戻すことができます。バックトラックウィンドウ内のスペース不足でテーブルを保存できないと、テーブルは最終的にバックトラック変更レコードから削除される場合があります。
### バックトラック時間
Aurora は、常に DB クラスターに即した時間までバックトラックします。これにより、トランザクションがコミットされないままバックトラックが完了するという事態が避けられます。バックトラック時間を指定すると、Aurora はそれに即した最も近い時間を自動的に選択します。このアプローチでは、最終的なバックトラック時間が、指定した時間と正確に一致しない場合があります。正確なバックトラック時間は、AWS CLI の [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) コマンドを使用して確認できます。詳細については、「[既存のバックトラックの取得](#AuroraMySQL.Managing.Backtrack.Retrieving)」を参照してください。
### バックトラックの制限事項
バックトラックには以下の制限が適用されます。
+ バックトラックは、バックトラック機能を有効にして作成した DB クラスターでのみ使用できます。DB クラスターを変更せずにバックトラック機能を有効にすることはできません。バックトラック機能は、新しい DB クラスターの作成時または DB クラスターのスナップショットの復元時に有効化できます。
+ バックトトラックウィンドウの上限は 72 時間です。
+ バックトラックは、DB クラスター全体に影響します。例えば、1 つのテーブルや 1 つのデータ更新に限定してバックトラックすることはできません。
+ バックトラック対応クラスターからクロスリージョンリードレプリカを作成することはできませんが、クラスターでバイナリログ (binlog) レプリケーションを有効にすることはできます。バイナリログ記録が有効になっている DB クラスターをバックトラックしようとすると、バックトラックの強制を選択していない限り、通常はエラーが発生します。バックトラックを強制しようとすると、ダウンストリームのリードレプリカが壊れ、ブルー/グリーンデプロイなどの他のオペレーションが妨げられます。
+ データベースのクローンを、その作成時より前の時点までバックトラックすることはできません。ただし、元のデータベースを使用すると、クローン作成時より前の時点までバックトラックできます。データベースのクローンの詳細については、「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。
+ バックトラックに伴って DB インスタンスがわずかに中断します。バックトラックオペレーションをスタートする前にアプリケーションを停止または一時停止し、新しい読み取り/書き込みリクエストを阻止する必要があります。Aurora は、バックトラックオペレーション時に、データベースを一時停止し、開いている接続をすべて閉じて、コミットされていない読み取りや書き込みをすべて削除します。その後、バックトラックオペレーションが完了するまで待ちます。
+ バックトラックをサポートしていない AWS リージョンでは、バックトラック対応クラスターのクロスリージョンスナップショットを復元できません。
+ バックトラック対応クラスターで Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行する場合、アップグレードを実行する前の時点にバックトラックすることはできません。
## 利用可能なリージョンとバージョン
バックトラックは Aurora PostgreSQL では使用できません。
Aurora MySQL によるバックトラックでサポートされているエンジンとリージョンは以下のとおりです。
| リージョン | Aurora MySQL バージョン 3 | Aurora MySQL バージョン 2 |
| --- | --- | --- |
| 米国東部 (バージニア北部) | すべてのバージョン | すべてのバージョン |
| 米国東部 (オハイオ) | すべてのバージョン | すべてのバージョン |
| 米国西部 (北カリフォルニア) | すべてのバージョン | すべてのバージョン |
| 米国西部 (オレゴン） | すべてのバージョン | すべてのバージョン |
| アフリカ (ケープタウン) | – | – |
| アジアパシフィック (香港) | – | – |
| アジアパシフィック (ジャカルタ) | – | – |
| アジアパシフィック (マレーシア) | – | – |
| アジアパシフィック (メルボルン) | – | – |
| アジアパシフィック (ムンバイ) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (ニュージーランド） | – | – |
| アジアパシフィック (大阪) | すべてのバージョン | バージョン 2.07.3 以降 |
| アジアパシフィック (ソウル) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (シンガポール) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (シドニー) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (台北) | – | – |
| アジアパシフィック (タイ) | – | – |
| アジアパシフィック (東京) | すべてのバージョン | すべてのバージョン |
| カナダ (中部) | すべてのバージョン | すべてのバージョン |
| カナダ西部 (カルガリー) | – | – |
| 中国 (北京) | – | – |
| 中国 (寧夏) | – | – |
| 欧州 (フランクフルト) | すべてのバージョン | すべてのバージョン |
| 欧州 (アイルランド) | すべてのバージョン | すべてのバージョン |
| 欧州 (ロンドン) | すべてのバージョン | すべてのバージョン |
| 欧州 (ミラノ) | – | – |
| 欧州 (パリ) | すべてのバージョン | すべてのバージョン |
| 欧州 (スペイン) | – | – |
| 欧州 (ストックホルム) | – | – |
| 欧州 (チューリッヒ) | – | – |
| イスラエル (テルアビブ) | – | – |
| メキシコ (中部) | – | – |
| 中東 (バーレーン) | – | – |
| 中東 (アラブ首長国連邦) | – | – |
| 南米 (サンパウロ) | – | – |
| AWS GovCloud (米国東部) | – | – |
| AWS GovCloud (米国西部) | – | – |
## バックトラック対応クラスターのアップグレードに関する考慮事項
Aurora MySQL バージョン 3 のすべてのマイナーバージョンがバックトラックについてサポートされているため、バックトラック対応 DB クラスターを Aurora MySQL バージョン 2 からバージョン 3 にアップグレードできます。
# Aurora MySQL DB クラスターのバックトラックの設定
バックトラック機能を使用するには、バックトラックを有効にしてターゲットバックトラックウィンドウを指定する必要があります。それ以外の場合、バックトラックは無効です。
ターゲットのバックトラックウィンドウでは、バックトラックを使用してデータベースを巻き戻したい時間の長さを指定します。Aurora は、その時間枠をサポートするのに十分な変更レコードを保持しようと試みます。
## コンソール
コンソールを使用して、新しい DB クラスターの作成時にバックトラックを設定できます。DB クラスターを変更して、バックトラック対応クラスターのバックトラックウィンドウを変更することもできます。バックトラックウィンドウを 0 に設定してクラスターのバックトラックを完全に無効にすると、そのクラスターでバックトラックを再度有効にすることはできません。
**Topics**
+ [DB クラスターの作成時にコンソールでバックトラックを設定する](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Creating)
+ [DB クラスターの変更時にコンソールでバックトラックを設定する](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Modifying)
### DB クラスターの作成時にコンソールでバックトラックを設定する
新しい Aurora MySQL DB クラスターの作成時にバックトラックを設定するには、[**Enable Backtrack (バックトラックの有効化)**] を選択し、[**Target Backtrack window (ターゲットバックトラックウィンドウ)**] 値としてゼロより大きい値を [**Backtrack (バックトラック)**] セクションに指定します。
DB クラスターを作成するには、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」の手順に従います。次のイメージは [**Backtrack (バックトラック)**] セクションを示しています。
![\[コンソールで DB クラスターの作成時にバックトラックを有効化する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-create.png)
新しい DB クラスターを作成した時点では、Aurora には DB クラスターのワークロード用のデータがありません。したがって、新しい DB クラスターのコストを具体的に見積もることはできません。コンソールでは、代わりに一般的なワークロードに基づいて、指定したターゲットバックトラックウィンドウの一般的なユーザーコストを提示します。一般的なコストは、バックトラック機能のコストを見積もるための一般的な参考として提供されます。
**重要**
実際のコストは、DB クラスターのワークロードに基づくため、一般的なコストとは一致しない場合があります。
### DB クラスターの変更時にコンソールでバックトラックを設定する
コンソールを使用して DB クラスターのバックトラックを変更できます。
**注記**
現時点では、バックトラック機能が有効になっている DB クラスターに限り、バックトラックを変更できます。バックトラック機能を無効にして作成した DB クラスターや後でバックトラック機能を無効にした DB クラスターでは、[**バックトラック**] 機能が表示されません。
**コンソールを使用して DB クラスターのバックトラックを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. 変更するクラスターを選択し、[**変更**] を選択します。
1. [**Target Backtrack window (ターゲットバックトラックウィンドウ)**] で、バックトラックする所望時間を変更します。上限は 72 時間です。
![\[コンソールでバックトラックを変更する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-modify.png)
コンソールは、DB クラスターの過去のワークロードに基づいて、指定した時間のコストを見積もります。
+ DB クラスターでバックトラックが無効になっている場合は、Amazon CloudWatch の DB クラスターの `VolumeWriteIOPS` メトリクスに基づいてコストを見積もります。
+ DB クラスターでバックトラックが以前に有効化されている場合は、Amazon CloudWatch の DB クラスターの `BacktrackChangeRecordsCreationRate` メトリクスに基づいてコストを見積もります。
1. [**Continue**] を選択します。
1. [**Scheduling of Modifications (変更の予定)**] で、以下のいずれかを選択します。
+ **Apply during the next scheduled maintenance window (次回予定のメンテナンスウィンドウで適用する)** - 次回のメンテナンスウィンドウまで待ってから [**Target Backtrack window (ターゲットバックトラックウィンドウ)**] の変更を適用します。
+ **Apply immediately (即時に適用する)** - [**Target Backtrack window (ターゲットバックトラックウィンドウ)**] の変更をできるだけ早急に適用します。
1. [**Modify cluster**] (クラスターの変更) を選択します。
## AWS CLI
AWS CLI の [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) コマンドを使用して新しい Aurora MySQL DB クラスターを作成する場合、バックトラックを設定するには、ゼロより大きい `--backtrack-window` 値を指定します。`--backtrack-window` 値は、ターゲットバックトラックウィンドウを指定します。詳細については、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」を参照してください。
以下の `--backtrack-window` CLI コマンドを使用して AWS 値を指定することもできます。
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
次の手順では、AWS CLI を使用して DB クラスターのターゲットバックトラックウィンドウを変更する方法を示します。
**AWS CLI を使用して DB クラスターのターゲットバックトラックウィンドウを変更するには**
+ AWS CLI の [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを呼び出して以下の値を指定します。
+ `--db-cluster-identifier` - DB クラスターの名前。
+ `--backtrack-window` - DB クラスターをバックトラックする所望の最大秒数。
次の例では、`sample-cluster` のターゲットバックトラックウィンドウを 1 日 (86,400 秒) に設定します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 86400
```
Windows の場合:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 86400
```
**注記**
現在、バックトラックを有効化できるのは、バックトラック機能を有効にして作成した DB クラスターに限ります。
## RDS API
[CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API オペレーションを使用して新しい Aurora MySQL DB クラスターを作成する場合、バックトラックを設定するには、ゼロより大きい `BacktrackWindow` 値を指定します。`BacktrackWindow` 値は、`DBClusterIdentifier` 値で指定した DB クラスターのターゲットバックトラックウィンドウを指定します。詳細については、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」を参照してください。
以下の API オペレーションを使用して `BacktrackWindow` 値を指定することもできます。
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [RestoreDBClusterFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [RestoreDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
**注記**
現在、バックトラックを有効化できるのは、バックトラック機能を有効にして作成した DB クラスターに限ります。
# Aurora MySQL DB クラスターのバックトラックの実行
DB クラスターは、指定したバックトラックタイムスタンプまでバックトラックできます。バックトラックタイムスタンプが、最も早いバックトラック時間から現時点までの範囲内にあれば、DB クラスターはそのタイムスタンプまでバックトラックされます。
それ以外の場合は、通常、エラーが発生します。また、バイナリログが有効になっている DB クラスターをバックトラックしようとすると、通常、エラーが発生します。ただし、バックトラックの強制実行を選択した場合を除きます。バックトラックの強制実行は、バイナリログを使用する他のオペレーションに干渉する場合があります。
**重要**
バックトラックでは、それに伴う変更の binlog エントリが生成されません。DB クラスターでバイナリログを有効にしている場合、バックトラックは binlog 実装と互換性がない可能性があります。
**注記**
データベースのクローンでは、クローンの作成日時より前の時点まで DB クラスターをバックトラックすることはできません。データベースのクローンの詳細については、「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。
## コンソール
次の手順では、コンソールを使用して DB クラスターのバックトラックオペレーションを実行する方法を示します。
**コンソールを使用してバックトラックオペレーションを実行するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**インスタンス**] を選択します。
1. バックトラックする DB クラスターのプライマリインスタンスを選択します。
1. [**アクション**] で、[**DB クラスターのバックトラック**] を選択します。
1. [**DB クラスターのバックトラック**] ページで、DB クラスターのバックトラック先のバックトラックタイムスタンプを入力します。
![\[DB クラスターのバックトラック\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-db-cluster.png)
1. [**Backtrack DB cluster (DB クラスターのバックトラック)**] を選択します。
## AWS CLI
次の手順では、AWS CLI を使用して DB クラスターをバックトラックする方法を示します。
**AWS CLI を使用して DB クラスターをバックトラックするには**
+ AWS CLI の [backtrack-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/backtrack-db-cluster.html) コマンドを呼び出して以下の値を渡します。
+ `--db-cluster-identifier` - DB クラスターの名前。
+ `--backtrack-to` - DB クラスターをバックトラックする先のバックトラックタイムスタンプ (ISO 8601 形式で指定)。
次の例では、DB クラスター `sample-cluster` を 2018 年 3 月 19 日午前 10 時までバックトラックします。
Linux、macOS、Unix の場合:
```
aws rds backtrack-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
```
Windows の場合:
```
aws rds backtrack-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-to 2018-03-19T10:00:00+00:00
```
## RDS API
Amazon RDS API を使用して DB クラスターをバックトラックするには、[BacktrackDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BacktrackDBCluster.html) オペレーションを使用します。このオペレーションでは、`DBClusterIdentifier` 値で指定した DB クラスターを、指定した時間までバックトラックします。
# Aurora MySQL DB クラスターのバックトラックのモニタリング
DB クラスターのバックトラック情報を表示し、バックトラックのメトリクスをモニタリングできます。
## コンソール
**コンソールを使用してバックトラック情報を表示し、バックトラックのメトリクスをモニタリングするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. 情報を表示する DB クラスターの名前を選択します。
バックトラック情報は [**Backtrack (バックトラック)**] セクションにあります。
![\[DB クラスターのバックトラックの詳細\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-details.png)
バックトラックが有効になっていると、以下の情報が表示されます。
+ **Target window (ターゲットウィンドウ)** - ターゲットバックトラックウィンドウとして現在指定されている時間。十分なストレージがある場合、ターゲットはバックトラックできる最大時間です。
+ **Actual window (実際のウィンドウ)** - 実際にバックトラックできる時間であり、ターゲットバックトラックウィンドウより小さい値になることがあります。実際のバックトラックウィンドウは、ワークロードと、バックトラック変更レコードを保持できるストレージに基づきます。
+ **Earliest backtrack time (最も早いバックトラック時間)** - DB クラスターの最も早い (可能な限り) バックトラック時間。表示された時間より前の時点まで DB クラスターをバックトラックすることはできません。
1. DB クラスターのバックトラックのメトリクスを表示するには、以下の操作を行います。
1. ナビゲーションペインで、[**インスタンス**] を選択します。
1. 詳細を表示する DB クラスターのプライマリインスタンス名を選択します。
1. [**CloudWatch**] セクションで、[**CloudWatch**] ボックスに **Backtrack** と入力し、バックトラックのメトリクスのみを表示します。
![\[バックトラックのメトリクス\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-metrics.png)
以下のメトリクスが表示されます。
+ **バックトラック変更レコードの作成率 (カウント)** - このメトリクスは、DB クラスターで 5 分間に作成されたバックトラック変更レコードの数を示します。このメトリクスを使用して、ターゲットバックトラックウィンドウのバックトラックコストを見積もることができます。
+ **[課金済み] 保存されたバックトラック変更レコード数 (カウント)** - このメトリクスは、DB クラスターで実際に使用されたバックトラック変更レコードの数を示します。
+ **実際のバックトラックウィンドウ (分数)** - このメトリクスは、ターゲットバックトラックウィンドウと実際のバックトラックウィンドウの間に差異があるかどうかを示します。例えば、ターゲットバックトラックウィンドウが 2 時間 (120 分) で、このメトリクスで示された実際のバックトラックウィンドウが 100 分の場合、実際のバックトラックウィンドウはターゲットよりも小さくなります。
+ **バックトラックウィンドウのアラート (カウント)** - このメトリクスは、特定の時間内に実際のバックトラックウィンドウがターゲットバックトラックウィンドウより小さくなった回数を示します。
**注記**
以下のメトリクスは、現在の時刻より遅れる場合があります。
**バックトラック変更レコードの作成率 (カウント)**
**[課金済み] 保存されたバックトラック変更レコード (カウント)**
## AWS CLI
次の手順では、AWS CLI を使用して DB クラスターのバックトラック情報を表示する方法を示します。
**AWS CLI を使用して DB クラスターのバックトラック情報を表示するには**
+ AWS CLI の [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) コマンドを呼び出して以下の値を渡します。
+ `--db-cluster-identifier` - DB クラスターの名前。
次の例では、`sample-cluster` のバックトラック情報を一覧表示します。
Linux、macOS、Unix の場合:
```
aws rds describe-db-clusters \
--db-cluster-identifier sample-cluster
```
Windows の場合:
```
aws rds describe-db-clusters ^
--db-cluster-identifier sample-cluster
```
## RDS API
Amazon RDS API を使用して DB クラスターのバックトラック情報を表示するには、[DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) オペレーションを使用します。このオペレーションでは、`DBClusterIdentifier` 値で指定した DB クラスターのバックトラック情報を返します。
## コンソールを使用したバックトラックイベントへのサブスクライブ
次の手順では、コンソールを使用してバックトラックイベントにサブスクライブする方法を示します。実際のバックトラックウィンドウがターゲットバックトラックウィンドウより小さい場合、このイベントから E メール通知またはテキスト通知が送信されます。
**コンソールを使用してバックトラック情報を表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**イベントサブスクリプション**] をクリックします。
1. [**イベントサブスクリプションを作成**] をクリックします。
1. [**名前** ] ボックスにイベントサブスクリプションの名前を入力し、[**有効**] で [**はい**] を必ず選択します。
1. [**ターゲット**] セクションで、[**新しい E メールトピック**] を選択します。
1. [**トピック名**] にトピックの名前を入力し、[**これらの受取人を含みます**] に通知を受け取る E メールアドレスまたは電話番号を入力します。
1. [**出典**] セクションで、[**出典タイプ**] として [**インスタンス**] を選択します。
1. [**含めるインスタンス**] で、[**特定のインスタンスを選択**] をクリックし、DB インスタンスを選択します。
1. [**含めるイベントカテゴリ**] で、[**特定のイベントカテゴリを選択**] をクリックし、[**バックトラック**] を選択します。
ページは次のように表示されます。
![\[バックトラックイベントサブスクリプション\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. [**作成**] を選択します。
## 既存のバックトラックの取得
DB クラスターの既存のバックトラックに関する情報を取得できます。この情報には、バックトラック固有の識別子、出典から/ターゲットへのバックトラック日時、バックトラックのリクエスト日時、バックトラックの現在のステータスが含まれます。
**注記**
現時点では、コンソールを使用して既存のバックトラックを取得することはできません。
### AWS CLI
次の手順では、AWS CLI を使用して DB クラスターの既存のバックトラックを取得する方法を示します。
**AWS CLI を使用して既存のバックトラックを取得するには**
+ AWS CLI の [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) コマンドを呼び出して以下の値を渡します。
+ `--db-cluster-identifier` - DB クラスターの名前。
次の例では、`sample-cluster` の既存のバックトラックを取得します。
Linux、macOS、Unix の場合:
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Windows の場合:
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### RDS API
Amazon RDS API を使用して DB クラスターのバックトラックに関する情報を取得するには、[DescribeDBClusterBacktracks](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html) オペレーションを使用します。このオペレーションでは、`DBClusterIdentifier` 値で指定した DB クラスターのバックトラックに関する情報を返します。
# Aurora MySQL DB クラスターのバックトラックの無効化
DB クラスターのバックトラック機能を無効にすることができます。
## コンソール
コンソールを使用して DB クラスターのバックトラックを無効にすることができます。クラスターのバックトラックを完全に無効にした後に、そのクラスターに対して再度有効にすることはできません。
**コンソールを使用して DB クラスターのバックトラック機能を無効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. 変更するクラスターを選択し、[**変更**] をクリックします。
1. [**バックトラック**] セクションで、[**バックトラックを無効にする**] をクリックします。
1. **[Continue]** (続行) をクリックします。
1. [**Scheduling of Modifications (変更の予定)**] で、以下のいずれかを選択します。
+ **次回の定期メンテナンス期間中に適用** - 次回のメンテナンスウィンドウまで待ってから変更を適用します。
+ **すぐに適用** - 変更をできるだけ早急に適用します。
1. [**クラスターの変更**] をクリックします。
## AWS CLI
AWS CLI を使用して DB クラスターのバックトラック機能を無効にするには、ターゲットバックトラックウィンドウを `0` (ゼロ) に設定します。クラスターのバックトラックを完全に無効にした後に、そのクラスターに対して再度有効にすることはできません。
**AWS CLI を使用して DB クラスターのターゲットバックトラックウィンドウを変更するには**
+ AWS CLI の [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを呼び出して以下の値を指定します。
+ `--db-cluster-identifier` - DB クラスターの名前。
+ `--backtrack-window` - バックトラックをオフにするには、`0` を指定します。
次の例では、`sample-cluster` のバックトラック機能を無効化するために `--backtrack-window` を `0` に設定します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 0
```
Windows の場合:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 0
```
## RDS API
Amazon RDS API を使用して DB クラスターのバックトラック機能を無効にするには、[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) オペレーションを使用します。`BacktrackWindow` 値を `0` (ゼロ) に設定し、`DBClusterIdentifier` 値に DB クラスターを指定します。クラスターのバックトラックを完全に無効にした後に、そのクラスターに対して再度有効にすることはできません。
# 障害挿入クエリを使用した Amazon Aurora MySQL のテスト
障害挿入クエリを使用して、Aurora MySQL DB クラスターの耐障害性をテストできます。フォールト挿入クエリは、SQL コマンドとして Amazon Aurora インスタンスに発行されます。次のいずれかのイベント発生をシミュレートしてスケジュールすることができます。
+ 書き込みまたは読み取り DB インスタンスの障害
+ Aurora レプリカの障害
+ ディスクの障害
+ ディスクの輻輳
障害挿入クエリでクラッシュを指定すると、Aurora MySQL DB インスタンスのクラッシュが強制的に実行されます。その他の障害挿入クエリでは、障害イベントのシミュレーションが実行されますが、そのイベントは発生しません。障害挿入クエリを送信する場合、障害イベントのシミュレーションが発生する時間も指定します。
Aurora レプリカのエンドポイントに接続することによって、Aurora レプリカインスタンスの 1 つに障害挿入クエリを送信できます。詳細については、「[Amazon Aurora エンドポイント接続](Aurora.Overview.Endpoints.md)」を参照してください。
障害挿入クエリの実行には、すべてのマスターユーザー権限が必要です。詳細については、「[マスターユーザーアカウント権限](UsingWithRDS.MasterAccounts.md)」を参照してください。
## インスタンスのクラッシュのテスト
`ALTER SYSTEM CRASH` 障害挿入クエリを使用して、Amazon Aurora インスタンスのクラッシュを強制的に発生させることができます。
この障害挿入クエリでは、フェイルオーバーが発生しません。フェイルオーバーをテストする場合、RDS コンソールで DB クラスターの **[フェイルオーバー]** インスタンスアクションを選択するか、AWS CLI コマンドの [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html)、または RDS API の [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) オペレーションを使用します。
### 構文
```
1. ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
```
### オプション
この障害挿入クエリでは、次のクラッシュタイプのいずれかを指定できます。
+ **`INSTANCE`** — Amazon Aurora インスタンスの MySQL 互換データベースのクラッシュがシミュレートされます。
+ **`DISPATCHER`** — Aurora DB クラスターのライターインスタンスにあるディスパッチャーのクラッシュがシミュレートされます。*ディスパッチャー* は Amazon Aurora DB クラスターのクラスターボリュームに対して更新を書き込みます。
+ **`NODE`** — MySQL 互換データベースと Amazon Aurora インスタンスのディスパッチャーの両方のクラッシュがシミュレートされます。この障害挿入のシミュレーションでは、キャッシュも削除されます。
デフォルトのクラッシュタイプは `INSTANCE` です。
## Aurora レプリカの障害のテスト
`ALTER SYSTEM SIMULATE READ REPLICA FAILURE` 障害挿入クエリを使用して、Aurora レプリカの障害をシミュレートできます。
Aurora レプリカの障害は、指定した期間で、ライターインスタンスから Aurora レプリカまたは DB クラスター内のすべての Aurora レプリカに対するすべてのリクエストをブロックします。指定した期間が終了すると、影響を受けた Aurora レプリカは自動的にライターインスタンスと同期されます。
### 構文
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
2. [ TO ALL | TO "replica name" ]
3. 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` です。
+ **`quantity`** — Aurora レプリカの障害のシミュレートにかかる時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した単位の期間だけ発生します。例えば、`20 MINUTE` と指定すると、シミュレーションは 20 分間実行されます。
**注記**
Aurora レプリカの障害イベントの時間を指定するときには注意が必要です。指定する時間が長すぎ、障害イベントの発生時にライターインスタンスが大量のデータを書き込んだ場合、Aurora DB クラスターは Aurora レプリカがクラッシュしたものと見なし、レプリカを置き換える可能性があります。
## ディスクの障害のテスト
`ALTER SYSTEM SIMULATE DISK FAILURE` 障害挿入クエリを使用して、Aurora DB クラスターのディスクの障害をシミュレートできます。
ディスク障害のシミュレーションでは、Aurora DB クラスターがランダムにディスクセグメントをエラーとしてマークします。シミュレーションの実行中、これらのセグメントに対するリクエストはブロックされます。
### 構文
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
2. [ IN DISK index | NODE index ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### オプション
この障害挿入クエリでは、以下のパラメータを使用します。
+ **`percentage_of_failure`** — 障害イベントの発生時にエラーとしてマークするディスクの割合。この値は 0～100 の倍精度にすることができます。0 を指定すると、ディスクのどの部分もエラーとしてマークされません。100 を指定すると、ディスク全体がエラーとしてマークされます。
+ **`DISK index`** — 障害イベントをシミュレートする特定のデータの論理的なブロック。利用可能な論理的なデータブロックの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。詳細については、「[Aurora MySQL DB クラスターのボリュームステータスの表示](AuroraMySQL.Managing.VolumeStatus.md)」を参照してください。
+ **`NODE index`** — 障害イベントをシミュレートする特定のストレージノード。利用可能なストレージノードの範囲を超えた場合は、指定できる最大インデックス値を示すエラーが表示されます。詳細については、「[Aurora MySQL DB クラスターのボリュームステータスの表示](AuroraMySQL.Managing.VolumeStatus.md)」を参照してください。
+ **`quantity`** — ディスクの障害をシミュレートする時間。この値は時間の量の後に時間単位を続けて指定します。シミュレーションは、指定した単位の期間だけ発生します。例えば、`20 MINUTE` と指定すると、シミュレーションは 20 分間実行されます。
## ディスクの輻輳のテスト
`ALTER SYSTEM SIMULATE DISK CONGESTION` 障害挿入クエリを使用して、Aurora DB クラスターのディスクの障害をシミュレートできます。
ディスク輻輳のシミュレーションでは、Aurora DB クラスターがランダムにディスクセグメントを輻輳としてマークします。これらのセグメントに対するリクエストは、シミュレーションの実行中、指定した最小遅延値と最大遅延値の間で遅延します。
### 構文
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
2. BETWEEN minimum AND maximum MILLISECONDS
3. [ IN DISK index | NODE index ]
4. 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 のテーブルを変更する
Amazon Aurora には、ほぼ瞬時に所定の位置で `ALTER TABLE` オペレーションを実行するための最適化が含まれています。このオペレーションを実行するために、テーブルをコピーする必要はありません。また、他の DML ステートメントに実質的な影響を及ぼすことなく実行できます。このオペレーションは、テーブルのコピーにテンポラリストレージを使用しないため、スモールインスタンスクラスの大きなテーブルに対しても、DDL ステートメントを使用できます。
Aurora MySQL バージョン 3 は、インスタント DDL と呼ばれる MySQL 8.0 の特徴と互換性があります。Aurora MySQL バージョン 2 では、高速 DDL と呼ばれる異なる実装が使用されています。
**Topics**
+ [インスタント DDL (Aurora MySQL バージョン 3)](#AuroraMySQL.mysql80-instant-ddl)
+ [高速 DDL (Aurora MySQL バージョン 2)](#AuroraMySQL.Managing.FastDDL-v2)
## インスタント DDL (Aurora MySQL バージョン 3)
DDL オペレーションの効率性を向上するため Aurora MySQL バージョン 3 によって実行される最適化を、インスタント DDL と呼びます。
Aurora MySQL バージョン 3 はコミュニティ MySQL 8.0 のインスタント DDL と互換性があります。インスタント DDL オペレーションを実行するには、`ALTER TABLE` ステートメントで `ALGORITHM=INSTANT` 句を使用します。インスタント DDL の構文と使用方法の詳細については、MySQL ドキュメントの「[ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html)」ならびに「[Online DDL Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html)」(オンライン DDL オペレーション) を参照してください。
以下の例は、インスタンス DDL の特徴を説明しています。`ALTER TABLE` ステートメントは、列の追加、および列でのデフォルト値の変更を行います。例には、スタンダードカラムと仮想カラムの両方、およびスタンダードテーブルとパーティションテーブルの両方が含まれます。各ステップで、`SHOW CREATE TABLE` と `DESCRIBE` ステートメントを発行すると結果が確認できます。
```
mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)) PARTITION BY KEY(b) PARTITIONS 6;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 MODIFY COLUMN c ENUM('a', 'b', 'c', 'd', 'e'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN (d INT GENERATED ALWAYS AS (a + 1) VIRTUAL), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t2 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t3 (a INT, b INT) PARTITION BY LIST(a)(
-> PARTITION mypart1 VALUES IN (1,3,5),
-> PARTITION MyPart2 VALUES IN (2,4,6)
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> ALTER TABLE t3 ALTER COLUMN a SET DEFAULT 20, ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t4 (a INT, b INT) PARTITION BY RANGE(a)
-> (PARTITION p0 VALUES LESS THAN(100), PARTITION p1 VALUES LESS THAN(1000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE);
Query OK, 0 rows affected (0.05 sec)
mysql> ALTER TABLE t4 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
/* Sub-partitioning example */
mysql> CREATE TABLE ts (id INT, purchased DATE, a INT, b INT)
-> PARTITION BY RANGE( YEAR(purchased) )
-> SUBPARTITION BY HASH( TO_DAYS(purchased) )
-> SUBPARTITIONS 2 (
-> PARTITION p0 VALUES LESS THAN (1990),
-> PARTITION p1 VALUES LESS THAN (2000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE
-> );
Query OK, 0 rows affected (0.10 sec)
mysql> ALTER TABLE ts ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
```
## 高速 DDL (Aurora MySQL バージョン 2)
Aurora MySQL の高速 DDL は、ダウンタイムとリソース使用量を削減することで、特定のスキーマ変更 (列の追加や削除など) のパフォーマンスを向上させるように設計された最適化です。これにより、従来の DDL メソッドと比較して、これらのオペレーションをより効率的に完了できます。
**重要**
現在、高速 DDL を使用するには、Aurora ラボモードを有効にする必要があります。ラボモードを有効にする方法については、「[Amazon Aurora MySQL ラボモード](AuroraMySQL.Updates.LabMode.md)」を参照してください。
高速 DDL の最適化は、特定の DDL オペレーションの効率を向上させるために、当初 Aurora MySQL バージョン 2 のラボモードで導入されました。Aurora MySQL バージョン 3 では、ラボモードが廃止され、高速 DDL が MySQL 8.0 のインスタント DDL 機能に置き換えられました。
MySQL において、何度もデータ操作言語 (DDL) オペレーションを行うと、パフォーマンスに大きな影響が出ることがあります。
例えば、`ALTER TABLE` オペレーションを使用して列をテーブルに追加するとします。オペレーションに指定するアルゴリズムによっては、このオペレーションに以下の操作が伴う場合があります。
+ テーブル全体のコピーの作成
+ 同時データ操作言語 (DML) オペレーションを処理するためのテンポラリテーブルの作成
+ テーブルのすべてのインデックスの再構築
+ 同時 DML 変更の適用時におけるテーブルロックの適用
+ 同時 DML スループットの低下
このパフォーマンスへの影響は、大きなテーブルやトランザクション量が多い環境では特に問題となる場合があります。高速 DDL は、問題を軽減するために、スキーマの変更を最適化してオペレーションを迅速化し、リソース使用量を減らします。
### 高速 DDL の制限事項
現在、高速 DDL には以下の制限があります。
+ 高速 DDL は、NULL を許容する列 (デフォルト値を持たない) を、既存テーブルの末尾に追加する場合にのみ使用できます。
+ 高速DDLは、パーティション化されたテーブルでは機能しません。
+ 高速 DDL は、REDUNDANT 行形式を使用する InnoDB テーブルをサポートしていません。
+ Fast DDL は、フルテキスト検索インデックスを持つテーブルでは機能しません。
+ DDL オペレーションの最大可能レコードサイズが大きすぎる場合、高速 DDL は使用されません。ページサイズの半分を超えるレコードサイズは大きすぎます。レコードの最大サイズは、すべての列の最大サイズを追加して計算されます。サイズを変更可能な列の場合は、InnoDB スタンダードに基づき、extern byte は計算に含まれません。
### 高速 DDL の構文
```
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
```
このステートメントには、以下のオプションがあります。
+ **`tbl_name` — **変更するテーブルの名前。
+ **`col_name` — **追加する列の名前。
+ **`col_definition` — **追加する列の定義。
**注記**
NULL を許容する列の定義は、デフォルト値を使用せずに指定する必要があります。そうでない場合、高速 DDL は使用されません。
### 高速 DDL の例
次の例は、高速 DDL オペレーションによる高速化を示しています。最初の SQL の例では、高速 DDL を使用せずに、大きなテーブルに対して `ALTER TABLE` ステートメントを実行しています。この操作にはかなりの時間がかかります。CLI の例は、クラスターで高速 DDL を有効化する方法を示しています。次に、別の SQL の例では、同じテーブルで同じ `ALTER TABLE` ステートメントを実行します。高速 DDL を有効にすると、オペレーションが非常に高速になります。
この例では、1 億 5000 万行を含む、TPC-H ベンチマークの `ORDERS` テーブルを使用しています。このクラスターでは、比較的小さなインスタンスクラスを意図的に使用して、高速 DDL を使用できない場合の `ALTER TABLE` ステートメントの所要時間を示しています。この例では、同じデータを含む元のテーブルのクローンを作成します。`aurora_lab_mode` 設定を確認すると、ラボモードが有効になっていないため、クラスターで高速 DDL を使用できないことが分かります。その場合、`ALTER TABLE ADD COLUMN` ステートメントでテーブルの最後に新しい列を追加するには、かなりの時間がかかります。
```
mysql> create table orders_regular_ddl like orders;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into orders_regular_ddl select * from orders;
Query OK, 150000000 rows affected (1 hour 1 min 25.46 sec)
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 0 |
+-------------------+
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (40 min 31.41 sec)
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (40 min 44.45 sec)
```
この例では、前の例と同様に大きなテーブルを準備します。ただし、Interactive SQL セッション内で単にラボモードを有効にすることはできません。この設定は、カスタムパラメータグループで有効にする必要があります。そのためには、`mysql` セッションを終了して AWS CLI コマンドをいくつか実行するか、AWS マネジメントコンソール を使用する必要があります。
```
mysql> create table orders_fast_ddl like orders;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into orders_fast_ddl select * from orders;
Query OK, 150000000 rows affected (58 min 3.25 sec)
mysql> set aurora_lab_mode=1;
ERROR 1238 (HY000): Variable 'aurora_lab_mode' is a read only variable
```
クラスターのラボモードを有効にするには、パラメータグループをいくつか使用する必要があります。この AWS CLI の例では、クラスターのパラメータグループを使用して、クラスター内のすべての DB インスタンスのラボモード設定で同じ値を使用するようにします。
```
$ aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora5.7 \
--db-cluster-parameter-group-name lab-mode-enabled-57 --description 'TBD'
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].[ParameterName,ParameterValue]' \
--output text | grep aurora_lab_mode
aurora_lab_mode 0
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--parameters ParameterName=aurora_lab_mode,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lab-mode-enabled-57"
}
# Assign the custom parameter group to the cluster that's going to use Fast DDL.
$ aws rds modify-db-cluster --db-cluster-identifier tpch100g \
--db-cluster-parameter-group-name lab-mode-enabled-57
{
"DBClusterIdentifier": "tpch100g",
"DBClusterParameterGroup": "lab-mode-enabled-57",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.2",
"Status": "available"
}
# Reboot the primary instance for the cluster tpch100g:
$ aws rds reboot-db-instance --db-instance-identifier instance-2020-12-22-5208
{
"DBInstanceIdentifier": "instance-2020-12-22-5208",
"DBInstanceStatus": "rebooting"
}
$ aws rds describe-db-clusters --db-cluster-identifier tpch100g \
--query '*[].[DBClusterParameterGroup]' --output text
lab-mode-enabled-57
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
--output text | grep aurora_lab_mode
aurora_lab_mode 1
```
次の例では、パラメータグループの変更が有効になった後のステップを示します。クラスターで高速 DDL を使用できることを確認するため、`aurora_lab_mode` 設定をテストします。次に、`ALTER TABLE` ステートメントを実行して、別の大きなテーブルの末尾に列を追加します。ここでは、ステートメントは非常に高速で終了します。
```
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 1 |
+-------------------+
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (1.51 sec)
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (0.40 sec)
```
# Aurora MySQL DB クラスターのボリュームステータスの表示
Amazon Aurora において、DB クラスターボリュームは、論理的なブロックのコレクションで構成されます。各論理的なブロックは、10 ギガバイトの割り当て済みストレージです。これらのブロックは*保護グループ*と呼ばれます。
各保護グループのデータは、6 つの物理ストレージデバイス (*ストレージノード*と呼ばれる) にわたってレプリケートされます。これらのストレージノードは、DB クラスターがある AWS リージョン内の 3 つのアベイラビリティーゾーン (AZ) に割り当てられます。また、各ストレージノードには、DB クラスターボリュームに対する 1 つ以上の論理的なデータブロックが含まれます。保護グループおよびストレージノードの詳細については、AWS データベースブログの「[Aurora ストレージエンジンの概要](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/)」を参照してください。
ストレージノード全体の障害、またはストレージノード内の単一の論理的なデータブロックの障害をシミュレートできます。シミュレートするには、`ALTER SYSTEM SIMULATE DISK FAILURE` の障害挿入ステートメントを使用します。このステートメントで、特定の論理的なデータブロックまたはストレージノード全体のインデックス値を指定します。ただし、DB クラスターボリュームで使用されている論理的なデータブロックまたはストレージノードの数より大きいインデックス値を指定すると、ステートメントからエラーが返されます。障害挿入クエリの詳細については、「[障害挿入クエリを使用した Amazon Aurora MySQL のテスト](AuroraMySQL.Managing.FaultInjectionQueries.md)」を参照してください。
このエラーは、`SHOW VOLUME STATUS` ステートメントを使用して回避できます。このステートメントからは、2 つのサーバーステータス変数 (`Disks` および `Nodes`) が返されます。これらの変数は、DB クラスターボリュームの論理的なデータブロックとストレージノードの合計数をそれぞれ示します。
## Syntax
```
SHOW VOLUME STATUS
```
## 例
次の例は、SHOW VOLUME STATUS の一般的な結果を示しています。
```
mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
```