Managing the RO Group of Read-Only Instance
Download
Focus Mode
Font Size
Scenarios
TencentDB for MySQL allows users to create one or multiple read-only instances to form an RO group for read-only instances. This supports read-write separation and use cases with one primary node and multiple secondary nodes, significantly enhancing the read workload capabilities of user databases.
An RO group is a collection of read-only instances that share a single address. Within an RO group, you can configure read-only instance weights for traffic load balancing and set up delayed removal. Users can deploy RO groups as needed and route read requests to read-only instances based on specific rules. Configuring multiple read-only instances within the same RO group provides disaster recovery capabilities.
TencentDB for MySQL supports two types of RO groups: the standard RO group and the analytical RO group. The standard RO group of a two-node/three-node instance can be upgraded to the Proxy-only network mode. After the upgrade, it supports cross-AZ deployment of read-only instances.
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.
Proxy Network Mode: The capability to precisely forward client database requests to target read-only instances through a network approach. If the RO group under a dual-node/three-node primary instance has been upgraded to Proxy Network Mode, you can select Proxy Network Mode when adding a read-only instance to that primary instance. For upgrade operations, see Network Forwarding Feature.
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
Before the creation of read-only instances, you must first create a cloud database primary instance. See Creating a MySQL Instance.
Create Read-Only Instance RO Group
1. Log in to the TencentDB for MySQL console. On the instance list page, click the instance ID or Operation > Manage to go to the instance management page.
2. Select the Read-Only Instance page and click Create to enter the purchase page.
3. On the purchase page, configure the read-only instance and click Buy Now after confirmation.
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 you purchase multiple instances at once, all of them will be assigned to this RO group. The weight assignment method is automatically assigned by the system by default.
RO Group Name: The RO group name does not need to be unique. It supports Chinese characters, English letters, digits,
-, _, and . with a length of less than 60 characters.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.
Note:
If a read-only instance is removed because its latency exceeds the threshold, an alarm will be sent to the user (for details on configuring read-only instance removal alarms and recipients, see Alarm Feature). The instance status will change to service-stopped and synchronizing with a weight of 0. When the latency of the read-only instance is less than the threshold, the instance will rejoin the RO group.
Regardless of whether the delayed read-only instance removal feature is enabled, the read-only instance that is removed due to a failure will automatically rejoin the RO group after it is repaired.
Delay Threshold: Set a delay threshold for read-only instances. Instances exceeding this threshold will be removed from the RO group.
Least RO Instances: The minimum number of instances that must be retained in the group. If the number of existing read-only instances is less than or equal to this minimum and their delay exceeds the threshold, none of the existing read-only instances will be removed.
Note:
When read-only instances are removed due to delays exceeding the threshold, if the minimum number of retained instances is greater than 1, read-only requests will be routed to the remaining read-only instances. If the minimum retained instances is 0, all read-only requests will be routed to the primary instance.
When read-only instance removal due to delays exceeding the threshold is enabled, at least 1 instance is retained, and all read-only instances experience delays exceeding the set threshold, users can still read the delayed data.
Assign Read Weight: Automatically assigned by the system.
Billing Mode: Supports two billing modes: yearly/monthly subscription and pay-as-you-go.
Region: It is the same as the region of the primary instance. Selecting another region is also supported.
Architecture: Single-node. The single-node architecture is cost-effective, but each read-only instance is susceptible to single points of failure. For services requiring high availability, at least two read-only instances should be purchased within the RO group to ensure high availability.
AZ: When you create a new RO group, you can select the same AZ as the primary instance or a different AZ. There is no substantial difference between different AZs. Creating a cross-AZ RO group enhances data disaster recovery capabilities but introduces a few milliseconds of additional network latency.
Instance Specification: Select the instance specification as needed. The minimum specification requirement for read-only instances is 1 GB of memory.
Hard Disk: Select the disk space as needed. The minimum capacity for a read-only instance is 50 GB and must be greater than or equal to the storage capacity purchased for the primary instance.
Data Replication Mode: Asynchronous replication.
AZ: When you create a new RO group, you can select the same AZ as the primary instance or a different AZ. There is no substantial difference between different AZs. Creating a cross-AZ RO group enhances data disaster recovery capabilities but introduces a few milliseconds of additional network latency.
For details about other configurations, see Create Read-only Instance.
4. Return to the instance list. The created instance status will show as Delivering. When the status changes to Running, the read-only instance has been successfully created.
Configure Read-Only Instances RO Group
On the configuration page of the read-only instance RO group, you can configure basic information such as the RO group ID, name, instance delayed replication, delay time, removal of instances that exceed the delay threshold, delay threshold, minimum number of retained instances, and read weight.
Note:
Within the RO group, read-only instances can use different specifications, and the read weight can be set.
Within the same RO group, read-only instances can support different expiration dates and billing methods.
After delayed replication is enabled, the configuration will take effect for all RO instances in the RO group without changing their replication status.
After delayed replication is enabled, the delay time option will appear.
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, select the Read-Only Instance tab, click Configure in the RO group column, and go to the RO group configuration page.
3. On the RO group configuration page, configure the RO group information and click OK.
RO Group Name: Specify the name of the RO group.
Delayed Replication: Can be achieved by setting delayed replication and during the delay period, selecting to initiate recovery to a specified time or GTID (Global Transaction Identifier), to achieve efficient data rollback and rapid fault backtracking.
Replication Delay: The replication delay between the read-only instance and the primary instance. Configurable range: 1 - 259200 seconds.
Remove Delayed RO Instances: Whether to enable the removal policy. Removed instances have their weight automatically set to 0. If a read-only instance is removed due to exceeding the latency threshold, an alarm will be sent to the user. To configure alarms for read-only instance removal and specify recipients, see Alarm Feature.
Delay Threshold: Set a delay threshold for read-only instances. Instances exceeding this threshold will be removed from the RO group.
Least RO Instances: The minimum number of instances that must be retained in the group. If the number of existing read-only instances is less than or equal to this minimum and the delay exceeds the threshold, none of the existing read-only instances will be removed.
Assign Read Weight: The RO group supports two weight setting modes: automatic weight assignment by the system and custom weights. The weight input range is 0 - 100 and must be an integer. The system automatically sets the read weight value list for two-node and three-node MySQL instances:
Instance 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:
When Load Rebalancing is disabled, weight modifications only take effect for new connections. They do not change the read-only instances accessed by existing persistent connections and will not cause database disconnections.
When Load Rebalancing is enabled, all connections are disconnected for seconds. New connections are then load-balanced according to the configured weights.
Configuration for Proxy in Network-Only Mode
If a regular RO group is upgraded to Proxy Network Mode, the configuration adjustments at this point share the same method and effect as those for database proxy addresses. For detailed operation steps, see Viewing and Modifying Access Policies.
Terminating RO Groups of Read-only Instances
Note:
RO group does not support the feature of manual deletion.
RO group is automatically deleted when the last read-only instance in the group is completely destroyed.
Tencent Cloud does not support retaining an empty RO group.
1. Log in to the TencentDB for MySQL console, in the instance list, click Source Instance ID to go to 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 Is It Not Possible to Select a Certain AZ When a Read-Only Instance Is Created?
If a specific AZ is unavailable, it indicates that there are no resources in that AZ. You can select another AZ based on the actual options displayed on the purchase page, which will not affect your use of the read-only instance.
Can Read-Only Instances Be Deployed in Different AZs from the Primary Instance During Creation?
Yes. When creating a read-only instance and selecting a new RO group or Proxy network mode, you can choose an AZ different from that of the primary instance. However, if you select an existing RO group when creating the read-only instance, the AZ of that read-only instance must be the same as the AZ of the selected existing RO group, and it may not be in the same AZ as the primary 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.
Help and Support
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback