マルチ AZ 配置は、Amazon RDS MySQL の変更中のダウンタイムを削減するのに役立ちますか?

所要時間2分
0

Amazon Relational Database Service (Amazon RDS) for MySQL インスタンスを変更したいと考えています。マルチ AZ 配置はダウンタイムの削減に役立ちますか?

簡単な説明

Amazon RDS MySQL インスタンスを変更すると、マルチ AZ 配置によって変更の影響が軽減されます。

マルチ AZ 配置は、次のシナリオで Amazon RDS MySQL インスタンスに影響を与える可能性があります。

  • DB インスタンスストレージの変更
  • DB インスタンスクラスの更新
  • 基盤となる OS またはハードウェアの保守

注: 実行しようとしている更新の種類によっては、マルチ AZ 配置では可用性の向上の恩恵を受けることができない場合があります。

解決方法

DB インスタンスストレージの変更

Amazon RDS ストレージを変更するために、次のストレージの変更を使用できます。

  • 割り当てられたストレージサイズ
  • プロビジョンド IOPs 値
  • ストレージタイプ

割り当てられたストレージのサイズの引き上げ、および IOPs 値の変更は、ダウンタイムを含まないオンラインのオペレーションです。プライマリ DB インスタンスとスタンバイ DB インスタンスの両方に対するこれらのストレージ更新は同時に行われるため、マルチ AZ はストレージの更新中に追加の可用性を提供しません。ストレージの変更と潜在的なダウンタイムの詳細については、「DB インスタンスの設定」を参照してください。

また、マルチ AZ DB インスタンスのストレージタイプを [General Purpose (SSD)] (汎用 (SSD)) と [Provisioned IOPS (SSD)] (プロビジョンド IOPS (SSD)) の間で変更しても、ダウンタイムは発生しません。ただし、次のシナリオではダウンタイムが発生します。

  • [General Purpose (SSD)] (汎用 (SSD)) から [Magnetic] (マグネティック)、または [Magnetic] (マグネティック) から [General Purpose (SSD)] (汎用 (SSD))。
  • [Provisioned IOPS (SSD)] (プロビジョンド IOPS (SSD)) から [Magnetic] (マグネティック)、または [Magnetic] (マグネティック) から [Provisioned IOPS (SSD)] (プロビジョンド IOPS (SSD))。
  • [General Purpose (SSD)] (汎用 (SSD)) から [Provisioned IOPS (SSD)] (プロビジョンド IOPS (SSD)) 。ただし、DB インスタンスがシングル AZ で、カスタムパラメータグループを使用している場合に限ります。
  • プロビジョンド IOPS (SSD) から汎用 (SSD)。ただし、DB インスタンスがシングル AZ で、カスタムパラメータグループを使用している場合に限ります。

DB インスタンスクラスの更新

インスタンスクラスの変更には新たに定義されたハードウェアセットが必要であり、この変更はオンラインのオペレーションではないため、ダウンタイムが必要になります。Amazon RDS MySQL DB インスタンスのマルチ AZ 配置により、どのような影響も大幅に緩和できます。これは、更新がプライマリとスタンバイに対して同時に行われないためです。スタンバイインスタンスが最初に変更され、フェイルオーバーが発生します。フェイルオーバー後、新しいスタンバイが変更されます。必要なダウンタイムには、フェイルオーバーの完了 (通常は 60~120 秒) と DB エンジンのクラッシュリカバリの完了の時間が含まれます。詳細については、「マルチ AZ 配置」を参照してください。

DB エンジンのバージョンのアップグレード

DB エンジンのバージョンのアップグレードは、RDS コンソールまたは API を使用して手動でスケジュールできます。または、DB エンジンのアップグレードは、自動マイナーバージョンアップグレードまたはエンジンが非推奨となった後に行われます。RDS MySQL はローリングアップグレードを自動化しないため、DB エンジンのバージョンアップグレードはプライマリホストとスタンバイホストの両方で同時に行われます。したがって、DB エンジンのバージョンアップグレードでは、マルチ AZ 配置から得られるメリットはありません。影響の範囲と期間を評価するには、実際のアップグレードを実行する前に、ステージング環境でアップグレードを実行します。詳細については、Best practices for upgrading Amazon RDS for MySQL and Amazon RDS for MariaDB を参照してください。

注: RDS MySQL DB インスタンスがリードレプリカを使用している場合は、ソースインスタンスをアップグレードする前に、すべてのリードレプリカをアップグレードする必要があります。詳細については、MySQL データベースのアップグレード時にリードレプリカを使用したダウンタイムの短縮を参照してください。

スケジュールされた OS またはハードウェアメンテナンスの実行

スケジュールされた OS またはハードウェアメンテナンスを実行する場合、マルチ AZ 配置により、これらの変更による影響が大幅に軽減されます。

マルチ AZ 配置は、スケジュールされたメンテナンスに次のような影響を及ぼします。

  • プライマリホストのみにメンテナンスをスケジュールすると、フェイルオーバーが発生し、新しいセカンダリホストでメンテナンスが実行されます。
  • セカンダリホストのみにメンテナンスをスケジュールすると、ダウンタイムは発生しません。
  • プライマリホストとセカンダリホストの両方でメンテナンスをスケジュールすると、最初にセカンダリ (スタンバイ) ホストでメンテナンスが実行されます。その後、フェイルオーバーが発生し、新しいセカンダリホストでメンテナンスが実行されます。

詳細については、「必要な Amazon RDS メンテナンスの実行時におけるダウンタイムを最小限に抑えるにはどうすればよいですか?」を参照してください。


AWS公式
AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ