スキップしてコンテンツを表示

RDS DB インスタンスをシングル AZ からマルチ AZ 配置、またはマルチ AZ からシングル AZ 配置に変更する際に、発生する事象を教えてください。

所要時間2分
0

Amazon Relational Database Service (Amazon RDS) DB インスタンスをシングル AZ からマルチ AZ 配置に変更する際に、発生することを把握しておきたいです。また、インスタンスをマルチ AZ 配置からシングル AZ 配置に変更する際に発生する事象も把握したいと考えています。

解決策

ユースケースに応じたデプロイタイプを選択する

デプロイタイプを変更する前に、マルチ AZ 配置とシングル AZ 配置に関する次の相違点をレビューしてください。

  • シングル AZ 構成では、RDS DB インスタンスと Amazon Elastic Block Store (Amazon EBS) ストレージボリュームは、1 つのアベイラビリティーゾーンにデプロイされます。
  • マルチ AZ 構成では、インスタンスと EBS ストレージボリュームは、2 つのアベイラビリティーゾーンにデプロイされます。
  • マルチ AZ 配置を使用する場合、Amazon RDS はデータのスタンバイコピーを維持します。Amazon RDS がインフラストラクチャの障害を検出し、自動的に復旧するため、データベース操作を迅速に再開できます。
  • シングル AZ 配置を使用する場合、機能停止が計画されたものであるかどうかにかかわらず、ポイントインタイムリカバリ (PITR) 操作を開始する必要が生じる可能性があります。PITR 操作の完了には、数時間かかることがあります。復元可能な最新の時刻よりも後に更新されたデータは利用できないため、追加のダウンタイムが発生する可能性があります。
  • マルチ AZ 配置では、自動バックアップ期間中、Amazon RDS は DB のスナップショットおよび自動バックアップをセカンダリインスタンスから作成します。このバックアッププロセスにおいて、Amazon RDS は、Amazon RDS for MariaDB、Amazon RDS for MySQL、Amazon RDS for Oracle、Amazon RDS for PostgreSQL データベースエンジンのセカンダリインスタンスからバックアップを取得するため、プライマリインスタンスでは I/O アクティビティは中断されません。Amazon RDS for SQL Server では、バックアッププロセスにより、I/O アクティビティは短時間中断されます。
  • シングル AZ 配置では、バックアッププロセスにより I/O が短時間 (数秒から数分) 中断されます。所要時間は、インスタンスのサイズとクラスによって異なります。
  • マルチ AZ 配置では、Amazon RDS は、最初にセカンダリインスタンスに対し、オペレーティングシステム (OS) のメンテナンスおよびスケーリング操作を適用します。Amazon RDS は、セカンダリインスタンスをプライマリインスタンスに昇格させた後、過去のプライマリインスタンスでメンテナンスや変更を行います。過去のプライマリインスタンスは、新たにスタンバイインスタンスになります。結果的に、特定の OS パッチやスケーリング操作中のダウンタイムは最小限に抑えられます。
  • シングル AZ インスタンスは、スケーリング操作中は利用できません。

注: デプロイタイプを別のデプロイタイプに変更する際には、インスタンスにダウンタイムは発生しません。

デプロイタイプをマルチ AZ からシングル AZ に変更する

デプロイタイプを変更します

インスタンスをマルチ AZ 配置からシングル AZ 配置に変更する際、Amazon RDS は、セカンダリインスタンスとボリュームのみを削除します。この変更は、プライマリインスタンスには影響しません。

デプロイタイプをシングル AZ からマルチ AZ に変更する

デプロイタイプを変更します

インスタンスをシングル AZ 配置からマルチ AZ 配置に変更する際、Amazon RDS は、インスタンスボリュームのスナップショットを作成します。Amazon RDS は、そのスナップショットを使用して別のアベイラビリティーゾーンに新しいボリュームを作成します。この新しいボリュームは、即時利用可能になります。

ただし、遅延読み込みにより、変更処理中と変更処理後の書き込み遅延が増加する可能性があります。インスタンスは、Amazon Simple Storage Service (Amazon S3) から新しいボリュームのデータをバックグラウンドでロードするため、この遅延が発生します。詳細については、「DB インスタンスへの復元」を参照してください。

遅延の量は、ボリュームの種類、ワークロード、インスタンス、およびボリュームサイズによって異なります。したがって、本番インスタンスを変更する前にテストインスタンスを変更することをおすすめします。また、メンテナンス期間またはスループットが少ない期間にインスタンスを変更することをおすすめします。

ロード時間と書き込み遅延を削減するには、次の手順を実行します。

  1. インスタンスのストレージタイプを [プロビジョニングされた 1 秒あたりの入出力操作数 (IOPS)] に変更します。ワークロードで必要な量よりも大幅に高い IOPS をプロビジョニングします。
    注: インスタンスでカスタムパラメータグループを使用している場合は、ストレージタイプの変更時にダウンタイムが発生する可能性があります。
  2. デプロイタイプの変更を行わなかった場合は、インスタンスをマルチ AZ 配置に変更します。
  3. インスタンスでフェイルオーバーを開始し、新しいアベイラビリティーゾーンがプライマリアベイラビリティーゾーンとなったことを確認します。
  4. インスタンスでデータのフルダンプを実行します。または、最もアクティブなテーブルに全表スキャンクエリを実行し、ボリュームへのデータの読み込みを高速化します。
  5. Amazon CloudWatch で WriteLatency メトリクスを参照し、書き込み遅延が通常の水準に戻ったことを確認します。
  6. インスタンスのストレージタイプまたは IOPS を前回の構成に差し戻します。
    注: ストレージタイプの変更を差し戻す際、ダウンタイムは発生しません。

インスタンスをシングル AZ 配置からマルチ AZ 配置に変更する際、Amazon RDS は、同じ構成のスタンバイインスタンスを別のアベイラビリティーゾーンに作成します。スタンバイインスタンスにより、追加コストが発生する可能性があります。また、マルチ AZ 配置は同期レプリケーションを使用するため、書き込みはシングル AZ 配置よりも若干遅くなります。

関連情報

Amazon RDS マルチ AZ

AWS公式更新しました 2ヶ月前
コメントはありません

関連するコンテンツ