Skip to main content

Read Replica

Horizontal Scaling in DBaaS​

In the context of databases, horizontal scaling involves distributing data and workload across multiple database servers. This improves performance, availability, and fault tolerance. Horizontal scaling is achieved by adding more database instances to handle increased read workloads. One of the key approaches to horizontal scaling is the use of Read Replicas.

Read Replicas​

Read replication copies data from one DBaaS server (the primary) to one or more replica servers. This distributes read operations across multiple nodes, resulting in improved performance and overall system reliability.

A Read Replica is a read-only DB instance. Applications can connect to a read replica like any other database instance, except write operations are not permitted.

info

Currently, user can create a Read Replica for a DBaaS within the same region without any special requirements. For creating a cross-region Read Replica, only Delhi ↔ Chennai is supported at the moment. The user can create cross-region Read Replicas only for MySQL, PostgreSQL, and MariaDB DBaaS.

How to Create a Read Replica in Any Region?​

Follow the steps below to create a read replica:

  1. Select the DBaaS instance for which you want to create a read replica.

  2. Navigate to the Read Replica tab and click Create Read Replica.

  3. A side drawer will appear. Select:

    • The region where you want to create the replica
    • The VPC Peering connection
    • The plan that best fits your requirements

  4. Click Create Read Replica to begin the creation process.

    info

    Cross-Region Requirement:

    • To create a Read Replica in a different region, the primary DBaaS must be attached to a VPC that has an active VPC peering connection with a VPC in the target region.
    • Additionally, user cant create a cross-region Read Replica for encrypted DbaaS instances.

How to Connect to a Read Replica?​

Each read replica is assigned a public IP address for direct access. This allows user to efficiently distribute read workloads across multiple replicas, enhancing performance and availability.

Note: Read-only nodes inherit the size of the primary DBaaS node. They cannot be individually resized and will automatically scale to match the primary node.

How to Promote a Read Replica to a Master Node?​

  • Once a read replica reaches the Running state, you can promote it to a master node. Promotion creates a new, independent DBaaS cluster where the promoted replica becomes the Master node.
  • If the primary DBaaS region goes down, user can promote an existing Read Replica to act as the new master node. Once promoted, a new cluster is automatically created, and the promoted Read Replica becomes the primary DBaaS instance. This newly formed cluster then operates independently, ensuring service continuity and minimizing downtime.
info

Read Replica Promotion is currently supported for MySQL MariaDB and PostgreSQL.

Additional actions available for any Read Replica include:

  1. Convert to committed

  2. Delete Read Replica

    DB Read Replica

  • Once the promotion process is complete, the former Read Replica becomes the master of a new DBaaS cluster in the same region in which it was originally created. For example, if the Read Replica was created in Chennai, the promoted DBaaS cluster will also be created in Chennai. It then serves as the primary endpoint for all read and write operations.

    warning

    Once a read replica is promoted to a master node, it cannot be reverted back to a replica.
    There is no backward synchronization, meaning changes in the new cluster do not propagate to the original DBaaS.

What Happens If the VPC Is Detached?​

If the VPC attached to the primary DBaaS is detached while a Read Replica exists in another region, the primary DBaaS will no longer be able to send updates to the replica. This leads to data inconsistency between the primary DBaaS and the Read Replica.

Once network connectivity is restored, the system will automatically synchronize the replica with the primary database, and data consistency will be re-established.

What Happens If the VPC Peering Connection Is Deleted?​

If the VPC peering connection between regions is deleted, synchronization between the primary DBaaS and the read replica will stop, causing data inconsistency.

tip

Promote the read replica to a primary DBaaS cluster before deleting the peering connection or before detaching the VPC.