Introducing Read Replicas

Scenarios

A GaussDB(for MySQL) instance contains read replicas in addition to a primary node.

In read-intensive scenarios, a primary node may be unable to handle the read pressure and service performance may be affected. To offload read pressure from the primary node, you can create one or more read replicas. These read replicas can process a large number of read requests and increase application throughput. To do this, connection addresses need to be scheduled separately for the primary node and each read replica on your applications so that all read requests can be sent to read replicas and write requests to the primary node.

Billing Standards

Read replicas are billed as well. The billing mode is the same as that of the primary node.

Functions

• Specifications of read replicas are the same as those of the primary node.
• You do not need to maintain accounts and databases for read replicas. They are synchronized from the primary node.
• The system can monitor the performance of read replicas.

Constraints

• There are up to 15 read replicas for a yearly/monthly or pay-per-use instance, and one read replica for a serverless instance.
• Read replicas do not support restoration from backups.
• Data cannot be migrated to read replicas.
• You cannot create or delete databases on read replicas.
• You cannot create database accounts for read replicas.
• There may be a latency between the read replicas and the primary node. The latency of the full-text index is significant due to its special mechanism. For latency-sensitive application workloads, you are advised to send queries to the primary node.