読取りレプリカは、同じリージョン内のDBシステムのプライマリMySQLインスタンスの読取り専用コピーです。読取り負荷のワークロードに対してスケーラビリティと高パフォーマンスを提供します。読取り、つまり問合せレイテンシをスケール・アウトします。

読取りレプリカは、DBシステムの起動時に起動され、DBシステムの停止時に停止され、DBシステムの削除時に削除されます。各読取りレプリカは、非同期レプリケーションを使用して自動的に更新されます。読取りレプリカは、スタンドアロンまたは高可用性DBシステムで作成できます。ECPUが8未満またはOCPUが4未満のシェイプでは、読取りレプリカはサポートされていません。読取りレプリカがリカバリを超えて失敗し、DBシステムからレプリケートできなくなった場合、読取りレプリカはNeeds Attention状態に設定されます。この場合、読取りレプリカを削除し、新しいレプリカを作成します。

DBシステムには最大18個の読取りレプリカを作成できます。各読取りレプリカには独自のエンドポイントがあります。たとえば、5つの読取りレプリカがある場合、5つのエンドポイントがあり、各読取りレプリカに1つのエンドポイントがあります。プライマリ・インスタンスで問合せのサブセットを実行し、読取りレプリカに残す場合は、適切なエンドポイントを使用するようにアプリケーションを構成する必要があります。

読取りレプリカには、コンピュート・インスタンス、要塞セッションまたはVPNを使用してDBシステムに接続する場合と同様の方法で接続できます。DB Systemへの接続を参照してください。

読取りレプリカは、プライマリ・インスタンスより遅れる可能性があります。これは、read replica lagメトリックで測定されます。各読取りレプリカのワークロードに応じて、読取りレプリカは異なる読取りレプリカ・ラグを示す場合があります。ワークロードが同じ場合でも、読取りレプリカは、CPUやメモリーなどのリソースに応じて異なる読取りレプリカ・ラグを示す場合があります。メトリックをモニターするアラームを作成し、メトリックがアラーム指定のトリガーを満たしたときに通知できます。メトリックを使用したアラームの作成を参照してください。

関連付けられたDBシステムでアカウント定義とその権限(パスワードなど)を変更すると、変更は読取りレプリカに伝播されます。各読取りレプリカでパスワードを変更する必要はありません。

読取りレプリカはアウトバウンド・レプリケーションのソース・サーバーとして構成できません。ソース・サーバーとして構成できるのはDBシステムのみです。

読取りレプリカは、関連付けられたDBシステムのセキュリティ証明書を継承します。読取りレプリカのセキュリティ証明書は更新できません。

Replica Load Balancerの読取り

DBシステムの最初の読取りレプリカを作成すると、読取りレプリカ・ロード・バランサが自動的に作成され、これにより読取りトラフィックが読取りレプリカ間に分散されます。同じDBシステムのすべての読取りレプリカがバックエンドとしてロード・バランサに追加されます。何らかの理由で読取りレプリカ・ロード・バランサの作成が失敗した場合、読取りレプリカは作成されません。読取りレプリカ・ロード・バランサは、関連付けられたDBシステムを削除した場合にのみ削除されます。

読取りレプリカ・ロード・バランサにはプライベートIPアドレスがあり、インターネットから直接アクセスすることはできません。読取りレプリカ・ロード・バランサには、コンピュート・インスタンス、要塞セッションまたはVPNを使用してDBシステムに接続する場合と同様の方法で接続できます。DB Systemへの接続を参照してください。

• Read Replica Load Balancer Policy: ロード・バランサのロード・バランシング分散ポリシーは、ソースおよび宛先のIPアドレス、ポートおよびIPプロトコル情報の5タプル・ハッシュに基づいています。この5タプル・ハッシュ・ポリシーは、特定のTCPまたはUDPセッション内のセッション・アフィニティを提供します。この場合、同じセッションのパケットは、ネットワーク・ロード・バランサの背後にある同じバックエンド・サーバーに送信されます。
• 接続のアイドル・タイムアウト: ロード・バランサは、通過するすべてのTCPフローの状態をトラッキングします。IPプロトコルとソースおよび宛先IPアドレスとポートの組合せによってフローが定義されます。トラフィックがクライアントまたはサーバーからアイドル・タイムアウトより長い間受信されない場合、フローは削除できます。アイドル・タイムアウト後に受信されたTCPパケットは、すべてドロップされます。TCPフローのアイドル・タイムアウト期間は8時間です。アイドル・タイムアウト期間は変更できません。接続が現在未使用で、接続を有効のままにする場合は、TCPキープアライブをクライアントに設定し、TCPキープアライブパケットを送信して接続を維持します。
  ノート
  
  2023年10月10日より前に作成されたすべての読取りレプリカ・ロード・バランサには、デフォルトのアイドル・タイムアウトは6分です。アイドル・タイムアウトを8時間に増やす場合は、Oracle Supportに連絡してください。

読取りレプリカ・ロード・バランサは、読取りレプリカの様々な状態を次のように処理します。

• 失敗状態または注意状態が必要: 読取りレプリカが失敗状態または注意状態が必要な場合、ロード・バランサはバックエンドから読取りレプリカを削除します。
• 非アクティブ状態: 読取りレプリカが非アクティブ状態の場合、ロード・バランサはトラフィックをルーティングしません。
• アクティブ状態: 読取りレプリカがアクティブ状態の場合、ロード・バランサはトラフィックをルーティングします。

IPアドレスの要件

スタンドアロンDBシステムに18個の読取りレプリカがある場合、DBシステムが存在するサブネットには、次の数のIPアドレスが必要です:

• 1つはDBシステム・エンドポイント用です。このエンドポイントへの接続では、読取り操作と書込み操作の両方を実行できます。読取り操作では常に最新データが返されます。
• 18個の読取りレプリカ・エンドポイント用。これらのエンドポイントに対する接続は、読取り専用操作を実行できます。読取り操作では、レプリケーション・ラグに応じて若干古いデータが返される場合があります。
• 1つは、読取りレプリカ・ロード・バランサ・エンドポイント用です。このエンドポイントへの接続は、アクティブな読取りレプリカ間で分散されます。