Multiple read-only instance groups (RO groups) can be configured for TencentDB for MySQL instance. RO groups can handle read-only requests from primary instance and improve the overall read overall performance of MySQL. Tencent Smart Advisor-Chaotic Fault Generator provides a simulated fault scene in which MySQL read-only instance groups are unavailable. The scene can be used to verify the following scenes:
1. In the event of cross-availability zone RO groups, whether RO groups in another availability zone can provide normal services to the outside when the single cross-availability zone fails.
2. Impact of RO group instance fault on business (whether the primary node can withstand read pressure).
Note:
This fault action will perform an environmental check to check if a read-only instance is configured for the number of user security groups and MySQL instances. If your instance does not meet this condition, fault injection will fail. To create a read-only instance for a MySQL instance, refer to TencentDB for MySQL documentation Creating a Read-Only Instance.
Fault Description
This fault action will block RO group instances in the user-assigned injection range so that they are unavailable to the outside world, and existing connections in the instances in fault-related RO groups will be interrupted.
Experiment Implementation
Step 1: Experiment Preparations
A TencentDB for MySQL instance, for which a read-only instance has been configured.
A CVM instance for testing database connection. (Users can select other connections for verification tests)
2. Go to Template Selection interface, click Skip and create a blank experiment.
3. Fill in the basic information of the experiment.
4. Fill in experiment action group information, select Database for Instance Type, MySQL for Instance Object, and click Add Instance.
5. Click Add Now to add a fault action, select Read-only instance group unavailable fault action, and click Next.
6. Fill in fault action parameters.
Now, a primary availability zone RO group is selected for the fault injection range so that the fault will be injected into an RO group instance of the selected MySQL instance in the primary instance availability zone.
Note:
Duration of Continuous Kill Connection (s) : Current action will create a continuous kill connection task to kill existing persistent connections. This parameter is used to specify the duration of a continuous kill task. If you have a large number of MySQL connections, this parameter can be increased so that all connections can be killed within the duration. The default time is 60s.
Fault Injection Scope: Select the availability zone where a fault is to be injected.
Primary availability zone: RO groups of the availability zone where the primary instance is located.
Non-primary availability zone: RO groups of the availability zone where other non-primary instances are located.
All availability zones: RO groups of all availability zones.
Assigned availability zones: RO group for availability zones assigned.
7. Click Next, go to Global Configuration. For Global Configuration, refer to Quick Start. After confirmation, click Submit to create an experiment.
Step 3: Experiment Execution
Before a Fault Occurs:
Before a MySQL RO group instance fault occurs, fault injection will be performed for selected read-only instance based on the injection range configured in previous step. Use CVM instance to log in to current RO instance, and create a client connection.
Go to DBbrain to check current connections created by CVM.
Experiment Execution:
1. Go to Experiment Details, click Execute on Action Card, and start executing an experiment action.
After fault injection, click Details to check execution result information.
Now, it can be seen that existing connections have been interrupted.
2. Click Execute a recovery action.
After a successful recovery action, reconnect the RO instance through CVM. After recovery, this RO instance can be reconnected, and the fault has been cleared.
Yes
No
Was this page helpful?