Amazon RDS for MySQL のよくある質問

Amazon リレーショナルデータベース (Amazon RDS) for MySQL は、MySQL Community Edition のバージョン 5.7 および 8.0 をサポートしています。サポートされているマイナーバージョンについては、Amazon RDS ユーザーガイドをご覧ください。

MySQL においてバージョン番号は以下のように整理されています。
MySQL バージョン = X.Y.Z

X = メジャーバージョン、Y = リリースレベル、Z = リリースシリーズ内のバージョン番号
Amazon RDS では、メジャーバージョンまたはリリースレベルが変更されると、バージョン変更がメジャーであると判断されます。例: 5.6.X -> 5.7.X。

同じリリースでバージョン番号が変更されていれば、バージョン変更はマイナーであると判断されます。例: 5.6.27 -> 5.6.29。

はい。Amazon RDS のよくある質問をご覧ください。

Amazon RDS for MySQL のポイントインタイム復元、スナップショット復元、および Amazon Redshift 機能とのゼロ ETL 統合には、クラッシュからの回復が可能なストレージエンジンが必要で、InnoDB ストレージエンジンでのみサポートされます。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンは、信頼性の高いクラッシュ回復をサポートしておらず、MySQL がクラッシュ後に再起動した時、特定時点の復元およびスナップショット復元が意図どおりに機能せず、データが紛失または破損する可能性があります。それでも、Amazon RDS で MyISAM を使用する場合は、このステップに従ってください。DB スナップショット復元機能の特定のシナリオに役立つことがあります。フェデレーティッドストレージエンジンは、現在 Amazon RDS for MySQL では非サポートとなっています。

新しい DB インスタンスを作成すると、使用するデフォルトプライマリユーザーは特定の権限を取得します。権限の一覧については、Amazon RDS ユーザーガイドの「マスターユーザーアカウント特権」を参照してください。

Amazon RDS for MySQL リードレプリカにはトランザクションストレージエンジンが必要であり、InnoDB ストレージエンジンでのみサポートされています。MyISAM などの非トランザクション MySQL ストレージエンジンでは、リードレプリカが意図したとおりに動作しない可能性があります。それでも MyISAM でリードレプリカを使用する場合は、Amazon CloudWatch の「レプリカラグ」の計測値 (AWS マネジメントコンソールまたは Amazon CloudWatch API を介して取得できます) を注意して監視し、レプリケーションエラーが原因でリードレプリカが停止した場合は再作成することをお勧めします。一時テーブルや他の非トランザクションエンジンを使用する場合も、同様の注意事項が適用されます。

MySQL バージョン 5.6 以降では、バイナリログフォーマットを行ベースに設定できます。デフォルトでは、レプリケーションは混合フォーマット (行ベースと記述ベースのレプリケーション) で設定されます。これは、ほとんどのユースケースを満たすことができます。MySQL のドキュメントには、「混合フォーマットと行ベースのレプリケーションの違い」についての詳細が記載されています。

Amazon RDS ブルー/グリーンデプロイは、RDS for MySQL のバージョン 5.7 以降でご利用いただけます。利用可能なバージョンの詳細については、RDS for MySQL ドキュメントをご覧ください。

Amazon RDS ブルー/グリーンデプロイは、すべての AWS リージョンおよび AWS GovCloud リージョンで利用可能です。

Amazon RDS ブルー/グリーンデプロイでは、メジャー/マイナーバージョンアップグレード、スキーマの変更、インスタンスのスケーリング、エンジンパラメータの変更、メンテナンスアップデートなど、より安全でシンプル、かつ迅速なデータベース変更を行うことが可能です。

Amazon RDS ブルー/グリーンデプロイを使用すると、より安全、簡単、高速にデータベースの更新ができます。ブルー/グリーンデプロイは、メジャーバージョンまたはマイナーバージョンのデータベースエンジンのアップグレード、オペレーティングシステムの更新、論理レプリケーションを中断しないグリーン環境でのスキーマの変更 (テーブルの最後に新しい列を追加するなど)、またはデータベースパラメーター設定の変更などのユースケースに最適です。ブルー/グリーンデプロイを使用すると、1 回のスイッチオーバーで複数のデータベースを同時に更新できます。これにより、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短期間で予測可能なダウンタイムで新しいデータベース機能にアクセスできます。

グリーンインスタンスでワークロードを実行する場合、ブルーインスタンスと同じ料金が発生します。ブルーおよびグリーンインスタンスで実行するコストは、db.instance の現在の標準料金、ストレージのコスト、読み取り/書き込み I/O のコスト、およびバックアップや Amazon RDS Performance Insights のコストなど、有効な機能を含みます。事実上、ブルーグリーンデプロイの有効期間中は、db.instance でワークロードを実行するコストの約 2 倍を支払うことになります。

例えば、次のような場合です: RDS for MySQL 5.7 データベースが、マルチ AZ (MAZ) 構成で us-east-1 AWS リージョンの 2 つの r5.2xlarge db.instance (プライマリデータベースインスタンスとリードレプリカ) で実行しているとします。それぞれの r5.2xlarge db.instance は、20GiB 汎用 Amazon Elastic Block Store (Amazon EBS) で構成されています。Amazon RDS ブルー/グリーンデプロイを使用してブルーインスタンスのトポロジーのクローンを作成し、15 日間 (360 時間) 実行し、スイッチオーバーに成功した後にブルーインスタンスを削除します。ブルーインスタンスのコストは、オンデマンド料金 1.926 USD/時 (インスタンス + EBS コスト) で 15 日間 1,387 USD です。この 15 日間、ブルー/グリーンデプロイを使用した場合の合計コストは 2,774 USD で、これはその期間のブルーインスタンスの運用コストの 2 倍となります。

Amazon RDS ブルー/グリーンデプロイでは、メジャー/マイナーバージョンアップグレード、スキーマの変更、インスタンスのスケーリング、エンジンパラメータの変更、メンテナンスアップデートなど、より安全でシンプル、かつ迅速なデータベース変更を行うことが可能です。

Amazon RDS ブルー/グリーンデプロイがスイッチオーバーを開始すると、スイッチオーバーが完了するまで、ブルーとグリーンの両方の環境への書き込みがブロックされます。スイッチオーバーの間、ステージング環境 (グリーン環境) はブルー環境に追いつき、ブルー環境とグリーン環境の間でデータの一貫性を確保します。ブルー環境とグリーン環境が完全に同期すると、ブルー/グリーンデプロイはグリーン環境にトラフィックをリダイレクトすることで、グリーン環境を新しいブルー環境として推進します。ブルー/グリーンデプロイは、スイッチオーバーが、完了してからグリーン環境への書き込みを可能にするよう設計されており、スイッチオーバープロセス中のデータ損失はゼロになります。

ブルー環境がセルフマネージド論理レプリカまたはサブスクライバーの場合、スイッチオーバーはブロックされます。最初にブルー環境へのレプリケーションを停止し、スイッチオーバーを続行してからレプリケーションを再開することをお勧めします。対照的に、ブルー環境がセルフマネージド論理レプリカまたはパブリッシャーのソースである場合は、スイッチオーバーを続けることができます。ただし、スイッチオーバー後にグリーン環境からレプリケートするには、セルフマネージドレプリカを更新する必要があります。

Amazon RDS ブルー/グリーンデプロイでは、古い本番環境は削除されません。必要に応じて、追加の検証やパフォーマンス/リグレッションのテストのためにアクセスすることができます。古い本番環境が不要になった場合は、削除することができます。古い本番インスタンスでは、それを削除するまで標準料金が発生します。

Amazon RDS ブルー/グリーンデプロイのスイッチオーバーガードレールは、スイッチオーバー前にグリーン環境が追いつくまで、ブルー環境とグリーン環境での書き込みをブロックします。ブルー/グリーンデプロイは、ブルーとグリーンの環境におけるプライマリとレプリカのヘルスチェックも行います。レプリケーションのヘルスチェックも行います。例えば、レプリケーションが停止していないか、エラーが発生していないか、などを確認します。ブルー環境とグリーン環境の間で長時間実行されているトランザクションを検出します。最大許容ダウンタイムは最短で 30 秒から指定でき、進行中のトランザクションがこれを超えると、スイッチオーバーがタイムアウトします。

いいえ、Amazon RDS ブルー/グリーンデプロイは、Amazon RDS Proxy、クロスリージョンリードレプリカ、またはカスケードリードレプリカをサポートしていません。

いいえ、現時点では、Amazon RDS ブルー/グリーンデプロイを使用して変更をロールバックすることはできません。

MySQL は、メモリ内の 16 KiB ページのデータを、まず「ダブルライトバッファ」に、次にテーブルストレージにと、耐久性のあるストレージに 2 回書き込むことで、データ損失からユーザーを保護します。Amazon RDS Optimized Writes は、AWS Nitro System の Torn Write Prevention 機能を使用して、高い信頼性および耐久性をもって、1 ステップで 16 KiB のデータページをデータファイルに直接書き込みます。

Amazon RDS Optimized Writes は、MySQL のメジャーバージョン 8.0.30 以降でご利用いただけます。

Amazon RDS Optimized Writes は、db.r6i および db.r5b インスタンスで利用可能です。これらのインスタンスが利用可能なすべてのリージョン (AWS 中国リージョンを除く) でご利用いただけます。

Amazon RDS for MySQL のすべてのユーザーは、書き込みトランザクションのスループットを最大 2 倍向上させる Amazon RDS Optimized Writes を実装すべきです。デジタル決済、金融取引、オンラインゲームアプリケーションなど、書き込みの多いワークロードを持つアプリケーションでは、この機能が特に有用です。

いいえ。Amazon Aurora MySQL 互換エディション は、既に「ダブルライトバッファ」の使用を回避しています。 その代わりに、Aurora は 3 つの アベイラビリティーゾーン (AZ) で 6 つの方法でデータをレプリケートし、クォーラムベースのアプローチでデータを耐久性をもって書き込み、その後正しく読み取ることができます。

現時点では、インスタンスクラスが Optimized Writes をサポートしていても、この初期リリースでは、既存のデータベースインスタンスのために Amazon RDS Optimized Writes を有効にすることはサポートされていません。

RDS for MySQL をご利用のお客様は、Amazon RDS Optimized Writes を追加費用なしでご利用いただけます。

クエリ処理に MySQL の一時オブジェクトを使用するワークロードは、Amazon RDS Optimized Reads の恩恵を受けることができます。Optimized Reads は、Amazon EBS ボリュームではなく、データベースインスタンスの NVMe ベースのインスタンスストレージに一時オブジェクトを配置します。これにより、複雑なクエリ処理を最大 50% 高速化することができます。

Amazon RDS Optimized Reads は、RDS for MySQL の MySQL バージョン 8.0.28 以降でご利用いただけます。

Amazon RDS Optimized Reads は、db.r5d、db.m5d、db.r6gd、db.m6gd、X2idn および X2iedn インスタンスが利用可能なすべてのリージョンでご利用いただけます。詳細については、Amazon RDS DB インスタンスクラスのドキュメントをご覧ください。

お客様は、複雑なクエリ、汎用分析、または複雑なグループ、ソート、ハッシュ集約、高負荷の結合、および共通テーブル式 (CTE) を必要とするワークロードがある場合、Amazon RDS Optimized Reads を使用する必要があります。これらのユースケースでは、一時テーブルが作成され、Optimized Reads によってワークロードのクエリ処理を高速化することが可能になります。

はい、お客様は、Optimized Read が有効なインスタンスにワークロードを移動することにより、既存の Amazon RDS データベースを変換して Amazon RDS Optimized Reads を使用することができます。また、Optimized Reads は、サポートされているすべてのインスタンスクラスでデフォルトで利用可能です。db.r5d、db.m5d、db.r6gd、db.m6gd、X2idn、および X2iedn インスタンスでワークロードを実行している場合は、既に Optimized Reads の恩恵を受けています。

複雑なデータパイプラインを構築して管理したくない場合は、Amazon Redshift との Amazon RDS for MySQL ゼロ ETL 統合を使用すべきです。データが Amazon Redshift に格納されると、RDS for MySQL のトランザクションデータに対して、ほぼリアルタイムの分析および機械学習 (ML) 機能にアクセスできます。

Amazon Redshift との RDS for MySQL ゼロ ETL 統合は、サポートされている AWS リージョンの MySQL バージョン 8.0.32 以降で利用できます。

Amazon Redshift との RDS for MySQL ゼロ ETL 統合により、ペタバイト規模のトランザクションデータに対するほぼリアルタイムの分析および機械学習 (ML) が可能になり、複雑なデータパイプラインを構築して管理する必要がなくなります。RDS for MySQL にデータが書き込まれると数秒で、そのデータは Amazon Redshift にレプリケートされます。RDS for MySQL から Amazon Redshift に複数のデータベースとテーブルのデータを統合できます。分析上のニーズに基づいて、特定のデータベースとテーブルをデータフィルタリングすることで、データを Amazon Redshift に選択的に取り込むことができます。

ゼロ ETL 統合の一環として作成された変更データの作成と処理に使用された既存の RDS for MySQL および Amazon Redshift リソースには課金されます。 これらのリソースには、Amazon Redshift データウェアハウスのシードと再同期のための Amazon RDS スナップショットのエクスポートコスト、ソースからターゲットへのデータ変更の継続的なレプリケーションにかかる変更データキャプチャ (CDC) データ転送コスト、変更データの処理に使用される通常の RDS I/O とストレージ、レプリケートされたデータの通常の Amazon Redshift ストレージとコンピューティングコストが含まれます。詳細については、RDS for MySQL の料金ページをご覧ください。

例: RDS for MySQL 8.0.32 データベースと Amazon Redshift データウェアハウスが米国東部 (バージニア北部) リージョンで実行されているとします。この RDS for MySQL DB インスタンスは現在、プロビジョンドベースライン IOPS を含む汎用 SSD (gp3) ストレージ容量を 50 GB 使用しており、自動バックアップが有効で、MySQL バイナリログ記録がオンになっています。

RDS for MySQL DB インスタンス用に Amazon Redshift とのゼロ ETL 統合を作成すると、データのスナップショット (50 GB) が作成され、Amazon Redshift データウェアハウスにシードするためにエクスポートされます。翌日、RDS for MySQL DB インスタンスのテーブルのプライマリキーを変更すると、スナップショットエクスポートが Amazon Redshift に再同期されます。30 日間にわたって、データベースは 5 GB のデータ変更を処理します。

この例では、米国東部 (バージニア北部) で MySQL ゼロ ETL 統合と Amazon Redshift を統合するために RDS を使用して 30 日以内にかかる費用は、50 GB x (0.10 GB) の初期エクスポートに 50 GB x (0.10 GB) の再同期コストと 5 GB x (2.00 USD/GB) の CDC データ転送を加えた合計で 20.00 USD です。ゼロ ETL 統合にかかるこれらのコストに加えて、I/O、ストレージ、コンピューティングコストなど、レプリケートされたデータを処理するための Amazon RDS と Amazon Redshift の通常使用にかかる料金は、お客様の負担となります。

はい。プライマリインスタンスでのリソース消費を削減するために、Amazon Redshift とのゼロ ETL 統合のソース Amazon RDS インスタンスとして、Amazon RDS リードレプリカを使用できます。

はい。AWS CloudFormation を利用して、Amazon Redshift との RDS for MySQL ゼロ ETL 統合に必要なリソースの設定とデプロイを管理および自動化できます。詳細については、AWS CloudFormation ユーザーガイドにアクセスしてください。

Amazon Redshift との RDS for MySQL ゼロ ETL 統合により、トランザクションがアトミックにレプリケートされ、ソース RDS for MySQL データベースとターゲット Amazon Redshift クラスター間のデータ整合性が確保されます。

この統合によるトランザクションのアトミック性に関する重要なポイントをいくつかご紹介します。

• RDS for MySQL でコミットされたトランザクションのみが Amazon Redshift にレプリケートされます。コミットされていないトランザクションやロールバックされたトランザクションは適用されません。
• この統合は 2 段階のコミットプロセスを使用して、各トランザクションを Amazon Redshift にアトミックに適用します。トランザクションのすべてのデータ変更が適用されるか、または何も適用されないか (エラーが発生した場合) のいずれかです。
• ソースとターゲットの間でトランザクションの一貫性が維持されます。レプリケーション後、特定のトランザクションのデータの一貫性は RDS for MySQL と Amazon Redshift の両方で維持されます。
• DDL または DML を通じたスキーマ変更も、完全性を維持するためにアトミックに適用されます。
• トランザクションをアトミックに適用することで、データベース間で部分的なトランザクションが発生したり、一貫性のないデータ状態が発生したりすることがなくなります。

Amazon Redshift との RDS for MySQL ゼロ ETL 統合により、ソース RDS for MySQL データベースとターゲット Amazon Redshift クラスター間のトランザクションの完全な一貫性が維持されます。

スキーマ変更の処理方法に関する重要なポイントをいくつかご紹介します。

• CREATE TABLE、ALTER TABLE、DROP TABLE などの DDL ステートメントは、RDS for MySQL から Amazon Redshift に自動的にレプリケートされます。
• 統合により、レプリケートされたスキーマの変更について、Amazon Redshift テーブルで必要なチェックと調整が行われます。例えば、RDS for MySQL に列を追加すると、その列が Amazon Redshift にも追加されます。
• レプリケーションとスキーマの同期は、ソースデータベースとターゲットデータベース間の遅延を最小限に抑えながら、ほぼリアルタイムで自動的に行われます。
• DML の変更が DDL の変更と並行して発生しても、スキーマの一貫性は維持されます。