RDS マルチAZ & リードレプリカ

  • DB インスタンスのレプリカは、マルチ AZ & リードレプリカの2つの方法で作成できます。
  • マルチAZ デプロイ
    • マルチ AZ デプロイにより、高可用性とフェイルオーバーのサポートを実現する。
    • RDS は、別の AZ (物理的に別の場所にある独立したインフラストラクチャ) で同期スタンバイレプリカを自動的にプロビジョニングおよび管理します。
    • RDS は自動的にスタンバイ状態にフェイルオーバーするため、データベース操作が管理者の介入なしに迅速に再開できるようになります。
      • 計画データベースの保守
      • ソフトウェアのパッチ
      • プライマリ・インスタンスの再起動
      • プライマリ DB インスタンスの接続またはホストの障害、または
      • アベイラビリティーゾーンの障害
  • リードレプリカ
    • RDS は、PostgreSQL、MySQL、および MariaDB DB エンジンの組み込みレプリケーション機能を使用して、ソース DB インスタンスからのリードレプリカと呼ばれる特別なタイプの DB インスタンスを作成します。
    • アプリケーションからリードレプリカへの読み取りクエリをルーティングすることにより、ソース DB インスタンスへの負荷を軽減できます。
    • リード・レプリカにより、読み取り/負荷の高いデータベース・ワークロードに対する単一 DB インスタンスの容量制約を超えたエラスティック・スケーリングが可能。

マルチAZ　デプロイ

  • マルチAZ 配置により、DB インスタンスの高可用性と自動フェイルオーバーのサポートが実現
  • マルチAZ は、クリティカルシステムの耐久性と可用性を向上させ、計画的なシステム保守、DB インスタンス障害、アベイラビリティーゾーンの中断時に可用性を高めることができます。
  • マルチAZ は高可用性機能であり、読み取り専用シナリオのスケーリングソリューションではありません。スタンバイレプリカを使用して読み取りトラフィックを提供することはできません。読み取り専用のトラフィックをサービスするには、リードレプリカを使用します。
  • Oracle、PostgreSQL、MySQL、および MariaDB DB インスタンスのマルチAZ デプロイメントでは、Amazon テクノロジーが使用しますが、SQL Server DB インスタンスは SQL Server ミラーリングを使用します。
  • マルチAZ デプロイでは
    • RDS は、別のアベイラビリティーゾーンで同期スタンバイレプリカを自動的にプロビジョニングし、維持します。
    • データのコピーは、さまざまなアベイラビリティーゾーンに格納され、より高いレベルのデータの耐久性を実現します。
    • プライマリ DB インスタンスは、可用性ゾーン間で同期的にレプリケートされ、スタンバイレプリカに提供されます。
      • データの冗長性
      • スナップショットとバックアップ中の I/O のフリーズを排除
      • システムのバックアップ中の待ち時間のスパイクを最小化します
    • DB インスタンスは、同期データレプリケーションにより、単一の AZ 配置に比べて書き込みとコミットの待ち時間が増加している可能性があります。
    • トランザクションの成功は、プライマリとスタンバイ DB の両方でコミットが成功した場合にのみ返されます。
    • AWS は可用性ゾーン間の遅延の少ないネットワーク接続で設計されていますが、デプロイがスタンバイレプリカにフェイルオーバーされた場合、待ち時間が変化することがあります。
  • BYOL ライセンスモデルを使用する場合、プライマリ・インスタンスとスタンバイ・レプリカの両方のライセンスが必要です。
  • 本番ワークロードでは、プロビジョニンド IOPS と DB インスタンスクラス (m1.large 以上) を備えたマルチ AZ 配置を使用することをお勧めします。
  • シングルAZ 配置がマルチAZ 配置に変更された場合 (SQL Server または Amazon Aurora 以外のエンジンの場合)
    • RDS は、プライマリ DB インスタンスのスナップショットを配置から取得し、スナップショットを別のアベイラビリティーゾーンに復元します。
    • 次に、RDS はプライマリ DB インスタンスと新しいインスタンスの間の同期レプリケーションを設定します。
    • これにより、シングルAZ からマルチAZ への変換時のダウンタイムを回避

RDS のマルチAZフェイルオーバープロセス

  • DB インスタンスの計画的または予期しない停止が発生した場合
    • マルチAZ で有効になっている場合、RDS は別の AZ のスタンバイレプリカに自動的に切り替わります。
    • フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなった時点でのデータベースアクティビティおよびその他の条件によって異なります。
    • フェイルオーバー時間は通常60-120 秒です。ただし、大規模なトランザクションまたは長い回復プロセスは、フェイルオーバー時間を増やすことができます。
    • フェイルオーバーメカニズムにより、DB インスタンスの DNS レコードがスタンバイ DB インスタンスを指すように自動的に変更されます。
    • マルチAZ スイッチは、エンドポイント URL に変更がないため、アプリケーションに対してシームレスですが、DB インスタンスへの既存の接続を再確立する必要があります。
  • RDS は自動的にフェールオーバーを処理するため、データベース操作を管理者の介入なしにできるだけ早く再開できます。
  • 次のいずれかの条件が発生した場合、プライマリ DB インスタンスはスタンバイレプリカに自動的に切り替わります。
    • アベイラビリティーゾーンの停止
    • プライマリ DB インスタンスが失敗する
    • DB インスタンスのサーバタイプが変更される
    • DB インスタンスのオペレーティングシステムは、ソフトウェアのパッチを受けている
    • DB インスタンスの手動フェイルオーバーは、フェイルオーバー付き再起動 (強制フェイルオーバーとも呼ばれます) を使用して開始されました
  • マルチAZ DB インスタンスがフェイルオーバーした場合は
    • DB イベントサブスクリプションは、フェイルオーバーが開始されたことを電子メールまたは SMS で通知するようにセットアップできます。
    • DB イベントは、Amazon RDS コンソールまたは API を介して表示できます。
    • マルチAZ デプロイの現在の状態は、RDS コンソールおよび API を介して表示できます。

リードレプリカ

  • Amazon RDS では、MySQL、MariaDB、および PostgreSQL (バージョン9.3.5 以降) の DB エンジンの組み込みレプリケーション機能を使用して、ソース DB インスタンスからリードレプリカを作成します。
  • ソース DB インスタンスに対して行われた更新は、リードレプリカに非同期的にコピーされます。
  • アプリケーションからリードレプリカへの読み取りクエリをルーティングすることにより、ソース DB インスタンスへの負荷を軽減できます。
  • リードレプリカを使用すると、DB が1つの DB インスタンスの容量制限を超えて、読み取り負荷の高いデータベースワークロードに対して、自動的にスケールアウトすることができます。
  • リードレプリカは、読み取り専用接続を可能にする DB インスタンスとして動作します。アプリケーションは、任意の DB インスタンスと同じ方法でリードレプリカに接続できます。

リードレプリカの作成

  • 1つのソース DB インスタンスから最大5つのリードレプリカを作成できます。
  • 作成プロセス
    • バックアップ保持期間を0以外の値に設定することにより、ソース DB インスタンスで自動バックアップを有効にする必要があります。
    • 既存の DB インスタンスはソースとして指定する必要があります。
    • RDS は、ソースインスタンスのスナップショットを取得し、スナップショットから読み取り専用インスタンスを作成します。
    • RDS は、DB エンジンの非同期レプリケーションメソッドを使用して、ソース DB インスタンスに対する変更の読み取りレプリカを更新します。
  • RDS は、ソース DB インスタンス内のすべてのデータベースをレプリケートします。
  • RDS は、ソース DB インスタンスとリードレプリカの間に、そのリードレプリカが DB インスタンスとは異なる AWS リージョンにある場合に、セキュリティで保護された通信チャネルを設定します。
  • RDS では、セキュリティグループエントリの追加など、セキュリティで保護されたチャネルを有効にするために必要な AWS セキュリティー構成を確立します。
  • リードレプリカの作成中に、DB スナップショットが発生すると、ソース DB インスタンスの I/O の一時停止が発生する可能性があります。
  • 通常、I/O サスペンションは約1分間続き、ソース DB インスタンスがマルチ AZ デプロイの場合、回避することができます。 (マルチ AZ デプロイの場合は、スタンバイから DB スナップショットが取得されます)
  • 長時間実行されているトランザクションが実行中で、完了を待つ必要がある場合は、リードレプリカの作成時間を遅らせることができます。
  • 同じソース DB インスタンスから並行して作成された複数のリードレプリカでは、最初の作成アクションの開始時に1つのスナップショットだけが取得されます。
  • リードレプリカは、新しい独立したソース DB に昇格させることができ、その場合、リードレプリカとソース DB の間でレプリケーションリンクが切断されます。 ただし、レプリケーションは、レプリケーションソースとして元のソース DB を使用して他のレプリカに対して続行されます。

リードレプリカ削除 と DB フェイルオーバー

  • DB インスタンスを削除する場合と同じメカニズムを使用して、リードレプリカを明示的に削除する必要があります。
  • レプリカを削除せずにソース DB インスタンスが削除された場合、各レプリカはスタンドアロンのシングル AZ DB インスタンスに昇格されます。
  • マルチ AZ 配置のソースインスタンスがスタンバイにフェールオーバーした場合、関連するリードレプリカは、セカンダリをレプリケーションソースとして使用するように切り替えられます。

リートレプリカストレージおよびコンピュート要件

  • デフォルトでは、リードレプリカは、ソース DB インスタンスと同じストレージタイプで作成されます。
  • レプリケーションが効果的に動作するためには、各リードレプリカは、ソース DB インスタンスと同じ量のコンピューティング & ストレージリソースを持つ必要があります。
  • ソース DB インスタンス (スケーリングされた場合)、リードレプリカはそれに応じてスケーリングする必要がある。

リードレプリカの機能と制限

  • RDS は循環レプリケーションをサポートしていません。
  • DB インスタンスは、既存の DB インスタンスのレプリケーションソースとして機能するように構成することはできません。新しいリードレプリカは、既存の DB インスタンスからのみ作成できます (たとえば、MyDBInstance が ReadReplica1 にレプリケートされる場合、ReadReplica1 を MyDBInstance にレプリケートするように構成することはできません)。 ReadReplica1 から、ReadRep2 などの新しいリードレプリカのみを作成できます。
  • クロスリージョンレプリケーション
    • MySQL、PostgresSQL (2016.06から更新) または MariaDB リードレプリカは、改善に役立つソース DB インスタンスとは異なるリージョンで作成することができます。
      • 災害復旧機能 (RTO と RPO を削減)
      • 読み取り操作をエンドユーザーに近い領域にスケールする
      • あるリージョンのデータセンターから別のリージョンへの移行
  • リードレプリカは、他のリードレプリカからも作成できます。ただし、レプリカラグはこれらのインスタンスの方が高く、レプリケーションチェーンに関与するインスタンスは4つ以上存在することはできません。

リードレプリカの違い

リードレプリカの使用例

  • リードレプリカは、以下を含むさまざまなユースケースで使用できます。
    • 読み取り負荷の高いデータベースワークロードに対して、単一の DB インスタンスの計算または I/O 容量を超えてスケーリングすることで、レプリカの読み取りに過剰な読み取りトラフィックを指示します。
    • ソース DB インスタンスが使用できない場合の読み取りトラフィックの処理ソース DB インスタンスが、バックアップ I/O の停止またはスケジュールされたメンテナンスのために I/O 要求を取得できない場合は、読み取りトラフィックをリードレプリカに送ることができます。ただし、データが古い可能性があります。
    • ビジネスレポートまたはデータウェアハウスのシナリオでは、プライマリ、プロダクション DB インスタンスではなく、リードレプリカに対してビジネスレポートクエリを実行できます。

AWS認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
  • さらなるフィードバック、ディスカッション、修正を可能にします。
  1. AWS で成功した多層 Web アプリケーションを実行している場合、マーケティング部門では、アプリケーションにレポート層を追加するように求められています。レポート層は、Web アプリケーションデータベースに格納されているユーザーが生成した情報から、30分ごとにステータスレポートを集計および発行します。現在、データベース層のマルチ AZ RDS MySQL インスタンスを実行しています。また、アプリケーション層とデータベース層の間のデータベースキャッシュ層として ElastiCache を実装しています。データベースへの影響をできるだけ少なくして、レポート層を正常に実装できるようにする答えを選択してください。
    1. マスタデータベースから S3 バケットにトランザクションログを継続的に送信し、S3 バイト範囲要求を使用して S3 バケットからレポートを生成します。
    2. マルチ AZ によって維持された同期的にレプリケートされたスタンバイ RDS MySQL インスタンスを照会してレポートを生成する (スタンバイインスタンスをスケーリングソリューションとして使用することはできません)
    3. マルチ AZ マスタデータベースに接続された RDS リードレプリカを起動し、リードレプリカを照会してレポートを生成します。
    4. ElastiCache データベースキャッシュ層にクエリを実行してレポートを生成します。(ElasticCache は完全なデータを維持せず、単なるキャッシング・ソリューションです)
  2. 企業は、AWS に新しい2層 web アプリケーションを展開しています。同社は、限られたスタッフを持っており、高可用性を必要とし、アプリケーションは複雑なクエリとテーブルの結合が必要です。会社の要件に対するソリューションを提供する構成はどれですか。
    1. MySQL は、単一のアベイラビリティーゾーン内の2つの Amazon EC2 インスタンスにインストールされます (ハイアベイラビリティをすぐに使用することはできません)。
    2. マルチ AZ の Amazon RDS（MySQL）
    3. Amazon ElastiCache (単なるキャッシュソリューション)
    4. Amazon DynamoDB (複雑なクエリや結合には適さない)
  3. あなたの会社は、AWS のソーシャルメディアサイトの主要な公開発表を行う準備をしている。Web サイトは、マルチ AZ RDS MySQL エクストララージ DB インスタンスを使用して複数のアベイラビリティーゾーンにデプロイされた EC2 インスタンスで実行されています。このサイトでは、1秒あたりの小さな読み取りと書き込みの数が多いため、最終的な整合性モデルに依存します。包括的なテストの後には、RDS MySQL の読み取り競合があることがわかります。これらの要件を満たすために最適なアプローチはどれですか。(2 つの回答を選択)
    1. 各アベイラビリティーゾーンで実行中の ElastiCache インメモリキャッシュを展開する
    2. 複数の RDS MySQL インスタンスに負荷を分散するシャーディングを実装する (これは読み取り競合のみで、書き込みは正常に動作します)
    3. RDS MySQL インスタンスサイズを増やし、プロビジョニングされた IOPS を実装します (スケーラブルではありませんが、これは読み取り競合のみで、書き込みは正常に動作します)
    4. 各アベイラビリティーゾーンに RDS MySQL リードレプリカを追加する
  4. あなたの会社は、本社を東京に、世界中の支社を持ち、日本、ヨーロッパ、米国の AWS に複数の地域で展開したロジスティクスソフトウェアを使用しています。ロジスティック・ソフトウェアには3層アーキテクチャがあり、現在はデータ永続化に MySQL 5.6 を使用しています。各地域は独自のデータベースを展開しています。本社地域では、すべてのリージョンからのデータを読み取る時間ごとのバッチ処理を実行して、すべてのオフィスに電子メールで送信されるクロスリージョンレポートを計算しますこのバッチ処理は、できるだけ迅速にロジスティクスを最適化するために完了する必要があります。要件を満たすためにデータベースアーキテクチャを構築するにはどうすればいいですか。
    1. 各リージョンの展開について、リージョン内のマスタと RDS MySQL を使用し、HQ リージョンのリードレプリカを使います。
    2. 各リージョンの展開について、リージョンのマスターと共に EC2 で MySQL を使用し、1時間ごとに EBS スナップショットを HQ リージョンに送信します。
    3. 各リージョンの展開について、リージョン内のマスターと共に rds MySQL を使用し、1時間ごとの RDS スナップショットを HQ リージョンに送信します。
    4. 各リージョンの展開について、リージョンのマスターと共に EC2 で MySQL を使用し、S3 を使用してデータファイルを HQ リージョンに1時間ごとにコピーします。
    5. ダイレクトコネクト接続を使用して、すべてのリージョンの MySQL 展開を HQ リージョンに接続し、バッチ処理のネットワーク待ち時間を削減します。
  5. プライマリ DB インスタンスに障害が発生した場合、RDS (リレーショナルデータベースサービス) のマルチアベイラビリティゾーンの展開はどうなりますか。
    1. プライマリ DB インスタンスの IP は、スタンバイ DB インスタンスに切り替わります。
    2. 新しい DB インスタンスがスタンバイアベイラビリティーゾーンに作成されます。
    3. 標準名レコード (CNAME) は、プライマリからスタンバイに変更されます。
    4. RDS (リレーショナルデータベースサービス) DB インスタンスが再起動します。
  6. お客様のビジネスは、RDS MySQL データベース上の顧客データベース全体を格納する新しいアプリケーションを構築しており、様々なアプリケーションとは、さまざまな目的のためにそのデータを照会するユーザーがあります。データベース上の大規模なアナリティクスジョブは、タイムアウトになる前に、他のアプリケーションが必要なクエリ結果を取得できない可能性があります。また、データが増加するにつれて、これらの分析ジョブはより多くの時間がかかり、他のアプリケーションへの悪影響が高まります。同じデータのこれらの異なるワークロード間の競合の問題をどのように解決しますか。
    1. RDS インスタンスでマルチ AZ モードを有効にする
    2. ElastiCache を使用して分析ジョブデータをオフロードする
    3. 分析作業用の RDS リードレプリカの作成
    4. 可能な最大サイズで RDS インスタンスを実行する
  7. スタンバイ RDS インスタンスは、プライマリと同じアベイラビリティーゾーンにありますか。
    1. Oracle RDS タイプのみ
    2. はい
    3. 起動時に設定されている場合のみ
    4. いいえ
  8. 別のリードレプリカのリードレプリカ作成はサポートされていますか？
    1. 特定のリージョンでのみ
    2. MySQL ベースの RDS のみ
    3. Oracle RDS タイプのみ
    4. いいえ
  9. ユーザーは、RDS のマルチ AZ 機能をセットアップすることを計画しています。次の条件のうちマルチAZ機能を利用しない条件はどれですか？
    1. アベイラビリティーゾーンの停止
    2. フェイルオーバー・オプションを使用した再起動による DB インスタンスの手動フェイルオーバー
    3. リージョンの停止
    4. ユーザーが DB インスタンスのサーバーの種類を変更すると
  10. マルチ AZ 配置として DB インスタンスを実行すると、”___” によってデータベースの書き込みと読み取りが機能します。
    1. セカンダリ
    2. バックアップ
    3. スタンバイ
    4. プライマリ
  11. DB インスタンスをマルチ AZ 展開として実行する場合、読み取りまたは書き込み操作にスタンバイを使用できますか。
    1. はい
    2. MySQL ベースの RDS のみ
    3. Oracle RDS タイプのみ
    4. いいえ
  12. リードレプリカは、トランザクションストレージエンジンを必要とし、_________ ストレージエンジンでのみサポートされています
    1. OracleISAM
    2. MSSQLDB
    3. InnoDB
    4. MyISAM
  13. ユーザーは、RDS DB のマルチ AZ 機能を構成しています。ユーザーは、この RDS DB が AWS テクノロジーを使用しないことを知るようになりましたが、サーバーミラーリングを使用してレプリケーションを実現しています。ユーザーが現在使用している DB はどれですか。
    1. MySQL
    2. Oracle
    3. MS SQL
    4. PostgresSQL
  14. マスター DB インスタンスに複数のリードレプリカがある場合、そのうちの1つをプロモートすると、残りのリードレプリカはどうなりますか。
    1. 残りのリードレプリカは、引き続き古いマスタ DB インスタンスからもレプリケートされます
    2. 残りのリードレプリカは削除されます
    3. 残りのリードレプリカは、1つのリードレプリカに結合されます。
  15. マルチ AZ 配置を選択した場合、プライマリ DB インスタンスの計画的または予期しない停止が発生した場合、Amazon RDS は自動的にスタンバイレプリカに切り替わります。自動フェールオーバーメカニズムは、メイン DB インスタンスの ______ レコードを、スタンバイ DB インスタンスを指すように変更するだけです。
    1. DNAME
    2. CNAME
    3. TXT
    4. MX
  16. 自動フェールオーバーが発生すると、Amazon RDS は DB インスタンスイベントを生成して、自動フェールオーバーが発生したことを通知します。、_________ を使用して、DB インスタンスに関連するイベントに関する情報を返すことができます。
    1. FetchFailure
    2. DescriveFailure
    3. DescribeEvents
    4. FetchEvents
  17. リードレプリカをプロモートするときに作成される新しい DB インスタンスは、バックアップ期間を保持します。
    1. 真
    2. 偽
  18. 自動フェイルオーバーが発生したときにアラートが表示されますか？
    1. SNSが設定されている場合のみ
    2. いいえ
    3. はい
    4. Cloudwatchが設定されている場合のみ
  19. MySQL マルチ AZ DBインスタンスの展開で強制フェイルオーバーを開始できますか？
    1. 特定のリージョンでのみ
    2. VPCでのみ
    3. はい
    4. いいえ
  20. ユーザーがアプリケーションから RDS にアクセスしています。ユーザーは、MS SQL RDS DB でマルチ AZ 機能を有効にしました。計画的な停止中に AWS は、DB からスタンバイレプリカへのスイッチがアプリケーションへのアクセスに影響しないようにする方法を確認します。
    1. RDS には、新しい DB へのすべての要求をリダイレクトする内部 IP があります。
    2. RDS は、DNS を使用して、シームレスな移行のためにスタンバイレプリカに切り替えます。
    3. スイッチオーバーによりハードウェアが変更されるため、RDS はアクセスを心配する必要はありません。
    4. RDS は両方の DB を独立して実行し、ユーザーは手動で切り替える必要があります。
  21. マルチ AZ Amazon リレーショナルデータベースサービス (RDS) インスタンスのフェールオーバープロセスの一部は、次のうちどれですか。
    1. 失敗した RDS DB インスタンスが再起動します。
    2. プライマリ DB インスタンスの IP は、スタンバイ DB インスタンスに切り替わります。
    3. RDS エンドポイントの DNS レコードは、プライマリからスタンバイに変更されます。
    4. 新しい DB インスタンスがスタンバイアベイラビリティーゾーンに作成されます。
  22. マルチ AZ RDS インスタンスがフェールオーバーする理由はどれですか？
    1. アベイラビリティーゾーンの停止
    2. DB インスタンスの手動フェールオーバーは、フェールオーバーによる再起動を使用して開始されました
    3. より高いインスタンスクラスに自動スケールするには (リンクを参照)
    4. Master データベースの破損が発生する
    5. プライマリ DB インスタンスが失敗する
  23. RDS の展開を拡張する必要があります。あなたのログに基づいて、10% の書き込みと 90% の読み取りで動作しています。どのように最高の簡単な方法でこれをスケーリングできますか?
    1. 2番目のマスター RDS インスタンスを作成し、RDS グループをピアします。
    2. CloudFront を使用して、読み取り側のすべてのデータベース応答をキャッシュします。
    3. 負荷がほとんど読み取りのため、RDS のリードレプリカを作成します。
    4. マルチ AZ RDS のインストールを作成し、読み取りトラフィックをスタンバイにルーティングします。
  24. Amazon RDS マルチアベイラビリティゾーンモデルはどのように動作しますか?
    1. 2番目のスタンバイデータベースは、同期レプリケーションを使用して、master とは別のアベイラビリティーゾーンに配置および保守されます。(リンク参照)
    2. 2番目のスタンバイデータベースは、非同期レプリケーションを使用してマスターから別のアベイラビリティーゾーンに配置および保守されます。
    3. 2番目のスタンバイデータベースは、非同期レプリケーションを使用してマスタとは別のリージョンにデプロイおよび保守されます。
    4. 2番目のスタンバイデータベースは、同期レプリケーションを使用してマスタとは別のリージョンにデプロイおよび保守されます。
  25. お客様は、米国西部 (北カリフォルニア) 地域でアプリケーションを実行しており、アジア太平洋地域 (シンガポール) の災害復旧フェイルオーバーをセットアップしたいと考えています。お客様は、Amazon RDS マルチ AZ MySQL データベースインスタンスの低復旧ポイント目標 (RPO) を達成することに関心を持っています。このニーズに最適なアプローチはどれですか。
    1. 同期レプリケーション
    2. 非同期レプリケーション
    3. Route53 健康チェック
    4. RDS 増分スナップショットのコピー
  26. ユーザーは、小さな MySQL RDS DB を使用しています。マルチ AZ 機能により、ユーザーの待ち時間が長くなっています。以下のオプションのうち、このような状況でユーザーを助けることができないものはどれか?
    1. 非稼働時間で自動バックアップをスケジュールする
    2. 大規模またはそれより大きいサイズのインスタンスを使用する
    3. PIOPS を使う
    4. スタンバイレプリカからスナップショットを取得する
  27. リザーブドインスタンスはマルチAZ配備に使用できますか？
    1. クラスター計算インスタンスの場合のみ
    2. すべてのインスタンスタイプで出来る
    3. M3インスタンスタイプのみ
  28. マルチ AZ のフェイルオーバー後に “スタック” が表示され、ソース DB インスタンスから更新を取得または適用できません。何をしますか？
    1. 読み取りレプリカを削除して、それを置き換えるために新しい複製物を作成する必要があります。
    2. DB エンジンの関連付けを解除し、再関連付けする必要があります。
    3. インスタンスを単一の AZ にデプロイしてから、再びマルチ AZ に移動する必要があります。
    4. DB インスタンスを削除し、それを置き換える新しいデータベースを作成する必要があります。
  29. プライマリとスタンバイの間でデータをレプリケートする際に発生するデータ転送の料金は何ですか。
    1. 無料です。それは自由である。
    2. 標準データ転送料金を2倍にする
    3. 標準データ転送料金と同じ
    4. 標準データ転送料金の半分
  30. ユーザーは、MS SQL RDS データベースサーバーでマルチ AZ 機能を有効にしています。以下のステートメントのうち、ユーザーがマルチ AZ 機能をよりよく理解できるようになるのはどれですか。
    1. マルチ AZ では、AWS は2つの DB を並行して実行し、レプリカコピーにデータを非同期的にコピーします。
    2. マルチ AZ では、AWS は2つの DB を並行して実行し、レプリカコピーにデータを同期的にコピーします。
    3. マルチ AZ では、AWS は1つの DB だけを実行しますが、データを同期的にスタンバイレプリカにコピーします。
    4. AWS MS SQL はマルチ AZ 機能をサポートしていません
  31. 会社は、RDS MySQL インスタンスで実行されているメイントランザクション DB 上で、1時間ごとにバッチ分析を実行して、Redshift で実行されている中央データウェアハウスを作成します。バッチの実行中に、トランザクションアプリケーションは非常に低速です。バッチが完了したら、新しいデータを使用してトップ管理ダッシュボードを更新する必要があります。パフォーマンスの問題を解決し、可能な限りプロセスを自動化するために、このシナリオをどのように最適化しますか。
    1. RDS をバッチ分析および SNS 用の Redshift に置き換えて、社内システムにダッシュボードを更新するように通知します。
    2. RDS をバッチ分析と SQS に置き換えて、ダッシュボードを更新するためのメッセージをオンプレミスシステムに送信します。
    3. バッチ分析および SNS 用の RDS リードレプリカを作成し、ダッシュボードを更新するためにオンプレミスシステムに通知します。
    4. バッチ分析および SQS 用の RDS リードレプリカを作成し、ダッシュボードを更新するために社内システムにメッセージを送信します。

Jayendra’s Blog

この記事は自己学習用に「AWS RDS Replication – Multi-AZ & Read Replica – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。