Managing the RO Group of Read-Only Instance

Last updated: 2025-08-14 14:36:09
Managing the RO Group of Read-Only Instance
Last updated: 2025-08-14 14:36:09
Overview
TencentDB for MySQL allows you to create one or more read-only instances to form an RO group, which is suitable for read/write separation and one-source-multiple-replica application scenarios and capable of greatly enhancing the read load capacity of your database.
An RO group is a set of read-only instances sharing the same address. You can set their weights to balance the traffic load, set the policy of removing delayed read-only instances, and perform other configurations. You can deploy an RO group as needed and send the corresponding read requests to read-only instances according to certain rules. In addition, you can implement disaster recovery by configuring multiple read-only instances in the same RO group.
TencentDB for MySQL supports two types of RO groups: standard RO group and analytical RO group.
Standard RO group: The RO groups used by normal InnoDB engine read-only instances support features such as load balancing, delayed read-only instance removal, and the minimum number of retained instances.
Analytical RO group: The RO group used by read-only analysis engine instances of the LibraDB engine only supports load balancing.
Note:
The analytical RO group can only manage read-only analysis engines, while the standard RO group can only manage read-only instances.
Only primary or disaster recovery instances of two-node or three-node architectures support the creation of the RO group for the read-only instance.
If a delay threshold is set, the read-only instance will remain in the removed status after a restart or rebuild until the delay is recovered to within the specified threshold, at which point the read-only instance will rejoin the RO group.
Prerequisites
A source instance must be created first before a read-only instance can be created. For more information, see Creating MySQL Instance.
Creating an RO group
1. Log in to the TencentDB for MySQL console. In the instance list, click an Instance ID or Manage in the Operation column to enter the instance management page.
2. Select the Read-Only Instance page and click Create to enter the purchase page.
﻿
3. On the displayed purchase page, specify the following read-only instance configurations, confirm that everything is correct, and click Buy Now.
Instance engine: Select the engine for the current read-only instance. Currently, both InnoDB and LibraDB engines are supported. The LibraDB engine is selected in this case.
Specify RO Group: Select Create RO group. If multiple instances are purchased at a time, all of them will be assigned to this new RO group, and their weights will be automatically assigned by the system by default. - Assign Read Weight: It is assigned by the system.
RO Group Name: The RO group name doesn't need to be unique and can contain up to 60 letters, digits, hyphens, and underscores. - Instance Name: It must contain less than 60 letters, digits, or symbols (-_.).
Removal of read-only instances with delays exceeding the threshold: During the primary-secondary replication of the instance, if the secondary database is unable to promptly obtain the update content from the primary database and the delay exceeds the preset time threshold, the connection to the primary database will be automatically disconnected, and the secondary database will be removed from the replication link to ensure the availability and performance of the replication link. Whether to enable the removal policy can be configured.
If a read-only instance is removed since its delay exceeds the threshold, an alarm will be sent to the user (for information on configuring read-only instance removal alarms and recipients, see Alarm Policies). The instance status will be set to synchronizing while stopping services with a weight of 0. When the delay of the read-only instance is less than the threshold, the instance will rejoin the RO group. Simultaneously, regardless of whether the removal of read-only instances with delays exceeding the threshold feature is enabled, the read-only instance will also rejoin the RO group automatically once it is repaired after being removed due to a failure.
Delay Threshold: Set a delay threshold for the read-only instance. When the threshold is exceeded, the instance will be removed from the RO group.
Least RO Instances: This is the minimum number of instances that should be retained in the RO group. When there are fewer instances in the RO group, even if an instance exceeds the delay threshold, it will not be removed.
Assign Read Weight: It is assigned by the system.
Billing Mode: Monthly subscription and pay-as-you-go billing are supported.
Region: It is the same as the region of the primary instance. Selecting another region is also supported.
Database Version: It is the same as that of the source instance by default.
Engine: It is the same as that of the source instance by default.
Architecture: Select Single-node. Although the single-node architecture is cost-effective, there is a single point of failure for a single read-only instance. It is recommended to purchase at least two read-only instances in the service RO group that requires availability.
Data Replication Mode: Async replication
AZ: When creating a new RO group, you can select the same AZ as the source instance or a different AZ. There are no substantial differences between different AZs. If you choose a different AZ, the RO group will reside across AZs and can improve data disaster recovery, but there will be a few milliseconds of network latency.
For other configuration items, see Creating MySQL Instance.
4. Return to the instance list. The status of the created instance is Delivering. If the status changes to Running, the read-only instance has been successfully created.
Configuring an RO group
On the RO group configuration page, you can configure the basic information of the group such as ID, name, delayed replication, replication delay, removal policy, delay threshold, least read-only instances, and read weight.
Note: 
Read-only instances in an RO group can use different specifications, and their read traffic weights can be set.
Read-only instances in the same RO group can have different expiration dates and billing modes.
Once enabled, delayed replication will take effect for all read-only instances in this RO group, but won't change their replication statuses.
The replication delay option will appear only after delayed replication is enabled.
1. Log in to the TencentDB for MySQL console, find the target primary instance or disaster recovery instance in the instance list, and then click instance ID to enter the Instance Management page.
2. On the instance management page, click the Read-Only Instance tab and click Configuration in the RO Group column to enter the RO group configuration page.
﻿
3. On the RO group configuration page, configure the RO group information and click OK.
You can set delayed replication and select to replay by flashbacked position or global transaction identifier (GTID) during the delay to efficiently roll back data and fix failures.
Replication Delay: You can configure the time of delayed replication between a read-only instance and its source instance. The value range is 1–259200 seconds.
Remove Delayed RO Instances: Select whether to enable the removal policy. If a read-only instance is removed, its weight will be automatically set to 0. If a read-only instance is removed when its delay exceeds the threshold, it will become inactive, alarms will be sent to corresponding recipients. For more information on how to configure the read-only instance removal alarm and recipients, see Alarm Policies (TCOP).
Delay Threshold: Set a delay threshold for the read-only instance. When the threshold is exceeded, the instance will be removed from the RO group.
Least RO Instances: This is the minimum number of instances that should be retained in the RO group. When there are fewer instances in the RO group, even if an instance exceeds the delay threshold, it will not be removed.
Assign Read Weight: The RO group supports two weight assignment methods: automatic assignment by the system and custom assignment. The weight value must be an integer between 0 and 100. Below is the list of read weights automatically set for two-node and three-node TencentDB for MySQL instances by the system:
Memory Specification (MB)
1000
2000
4000
8000
12000
16000
24000
32000
48000
64000
96000
128000
244000
488000
Weight
1
1
2
2
4
4
8
8
10
12
14
16
26
50
Rebalance:
If rebalance is disabled, modifying weight will take effect only for new loads but will not affect the read-only instances accessed by existing persistent connections or cause a momentary disconnection from the database.
If rebalancing is enabled, all connections to the database will be temporarily disconnected, and the loads of newly added connections will be balanced based on the set weights.
﻿
Terminating and deleting an RO group
Note: 
RO groups cannot be deleted manually.
An RO group will be automatically deleted when the last read-only instance in it is eliminated.
Empty RO groups cannot be retained.
1. Log in to the TencentDB for MySQL console. In the instance list, click a Source Instance ID to enter the instance management page.
2. On the instance management page, select the Read-Only Instance tab. Click Terminate Instance or Terminate/Return  in the Operation column on the right.
3. In the pop-up dialog box, click Terminate after checking the termination information. And click Yes after reading and agreeing to the termination rules.
FAQs
Why can't I select a specific AZ when creating a read-only instance?
If you can't select an AZ, it means that there are no resources in this AZ. You can choose another AZ as displayed on the actual purchase page, which will not affect your use of the read-only instance.
Can I select an AZ different from that of the source instance when creating a read-only instance?
Yes. When creating a read-only instance, you can choose to create a new RO group for it and select an AZ different from that of the source instance. However, if you select an existing RO group, the AZ of the new read-only instance can only be the same as that of the selected existing RO group, which may not necessarily be the same as that of the source instance.
When Attempting to Create Read-Only Instances Under Existing RO Groups Fails, the Prompt InvalidParameter.RoGroupError.RoCdbTypeError Appears. What Is the Reason?
The instance type of the read-only instance is selected incorrectly. Instance types under the same RO group should be the same; you cannot have both general instances and exclusive instances. Check the instance types of the existing read-only instances under the corresponding RO group and ensure that the type for the new instance is consistent with the existing ones.