Read replicas are read-only copies of the primary MySQL instance of the DB system within the same region. They provide scalability and higher performance for read-heavy workloads. They scale out reads, that is, reduce query latency.

Read replicas are started when a DB system is started, stopped when the DB system is stopped, and deleted when the DB system is deleted. Each read replica is automatically updated using asynchronous replication. You can create read replicas on a standalone or high availability DB system. Read replicas are not supported on shapes that have less than 8 ECPUs or less than 4 OCPUs. If a read replica has failed beyond recovery and cannot replicate from the DB system anymore, the read replica is set to the Needs Attention state. In this case, delete the read replica and create a new one.

You can create a maximum of 18 read replicas in a DB system. Each read replica has its own endpoint. For example, if you have five read replicas, you have five endpoints, one endpoint for each read replica. If you want to execute a subset of queries on the primary instance and rest on the read replicas, you have to configure the application such that it uses appropriate endpoints.

You can connect to a read replica in a similar way as you connect to a DB system - using a compute instance, bastion session, or VPN. See Connecting to a DB System.

The read replicas can lag behind the primary instance. This is measured by the read replica lag metric. Depending on the workload on each read replica, the read replicas may exhibit a different read replica lag. Even if the workload is same, read replicas may exhibit a different read replica lag depending on its resources such as CPU and memory. You can create alarms to monitor the metric and notify you when metrics meet alarm-specified triggers. See Using Metrics to Create Alarms.

If you change the account definitions and their privileges (such as the password) in the associated DB system, the changes are propagated to the read replicas. You do not need to change the password on each read replica.

You cannot configure a read replica as the source server of an outbound replication; you can only configure a DB system as the source server.

A read replica inherits the security certificate of the associated DB system. You cannot update the security certificate of the read replica.

Inherit and Override

By default, a read replica inherits the shape, configuration, and version from the DB system. You can override these properties on a read replica to create a read replica with a different shape, configuration, or version as compared to the DB system. When a read replica inherits a property from the DB system, changing the property on the DB system will also change the property on the read replica to the same value. When a read replica overrides a property from the DB system, changing the property on the DB system does not affect the property of the read replica.

Read Replica Load Balancer

When you create the first read replica of a DB system, a read replica load balancer is created automatically, which distributes read traffic among the read replicas. All read replicas of the same DB systems are added as a backend to the load balancer. If the creation of read replica load balancer fails for any reason, the read replica is not created. A read replica load balancer is deleted only when you delete the associated DB system.

A read replica load balancer has a private IP address and you cannot access it directly from the internet. You can connect to the read replica load balancer in a similar way as you connect to a DB system - using a compute instance, bastion session, or VPN. See Connecting to a DB System.

• Read Replica Load Balancer Policy: The load balancing distribution policy of the load balancer is based on a 5-tuple hash of the source and destination IP address, port, and IP protocol information. This 5-tuple hash policy provides session affinity within a given TCP or UDP session, where packets in the same session are directed to the same backend server behind the network load balancer.
• Connections Idle Timeout: The load balancer tracks the state of all TCP flows passing through it. A combination of IP protocol and source and destination IP addresses and ports define a flow. The flow can be removed if no traffic is received from either the client or the server for longer than the idle timeout. Any TCP packets received after the idle timeout are dropped. The idle timeout duration for TCP flows is eight hours. You cannot change the idle timeout duration. If the connection is currently unused, and you want to keep the connection alive, set TCP keep-alive on the client, which sends the TCP keep-alive packets to keep the connection alive.
  Note
  
  All read replica load balancers created before October 10, 2023 have a default idle timeout of six minutes. If you want to increase the idle timeout to eight hours, contact Oracle Support.

A read replica load balancer handles the various states of the read replica in the following manner:

• Failed or needs attention state: If the read replica is in the failed or needs attention state, the load balancer removes the read replica from the backend.
• Inactive state: If the read replica is in the inactive state, the load balancer does not route traffic to it.
• Active state: If the read replica is in the active state, the load balancer routes traffic to it.

IP Address Requirements

If a standalone DB system has 18 read replicas, then the subnet in which the DB system is present requires the following number of IP addresses:

• One for the DB system endpoint. Connections made to this endpoint can perform both read and write operations. The read operations always return up-to-date data.
• 18 for the 18 read replica endpoints. Connections made to any of these endpoints can perform read-only operations. The read operations may return slightly out-of-date data depending to the replication lag.
• One for the read replica load balancer endpoint. Connections made to this endpoint are distributed across active read replicas.