Traffic playback replays captured production SQL traffic against a destination instance at a configurable rate. Use it to validate instance capacity, assess the impact of schema changes, or reproduce a failure scenario—without disrupting the source database.
How it works
Traffic playback follows four sequential phases:
Capture: PolarDB-X records SQL traffic from the source instance during the time range you specify. SQL Insight and Stress Testing (New Version) must be active on the source instance throughout this period.
Configure: You specify the destination instance, baseline data migration method, playback speed, and the ECS instance that runs the stress testing client.
Replay: The stress testing client replays the captured traffic against the destination instance at the rate you set.
Analyze: The Intelligent Stress Testing Details page compares performance metrics, SQL execution, and configuration parameters between the source and destination.
Use cases
| Scenario | When to use |
|---|---|
| Capacity planning | Verify whether current instance specifications can handle an upcoming traffic spike before scaling up. |
| Schema change validation | Test the impact of DDL changes against real production workloads before deploying to production. |
| Failure reproduction | Recreate a failure on a cloned database to diagnose the root cause and verify the fix. |
Prerequisites
Before you begin, make sure:
SQL Insight and Stress Testing (New Version) is enabled on the source PolarDB-X instance
The PolarDB-X instance is deployed in China (Hangzhou), China (Shanghai), China (Beijing), China (Shenzhen), or Singapore
Usage notes
Deploy the stress testing client and the destination instance in the same region to reduce network latency. For best results, place them in the same virtual private cloud (VPC).
Stress testing does not affect the performance of the source instance, so you do not need to schedule it during off-peak hours.
Before starting, confirm that the stress testing client can establish a stable connection to the destination instance.
Run a traffic playback stress test
Step 1: Configure the source instance
On the instance page, click the SQL Explorer tab, then click Traffic Playback and Stress Test.
Click Create Task.
In the Configure Source Instance step, set the parameters.

Make sure SQL Insight and Stress Testing (New Version) is enabled on the source instance throughout the traffic playback period.
Step 2: Configure the destination instance
In the Configure Destination Instance step, set the following parameters.

| Parameter | Description |
|---|---|
| Database engine | The destination database type. Supported types: ApsaraDB RDS for MySQL, PolarDB for MySQL cluster, or PolarDB-X instance. |
| Benchmark data migration | How to synchronize the source data to the destination instance before replay. See Choose a benchmark data migration method. |
| Destination instance | The destination instance. By default, traffic is sent to the primary endpoint. To test all nodes in a PolarDB for MySQL cluster, click Advanced Settings to specify the cluster endpoint. Advanced Settings is only available when the destination is a PolarDB for MySQL cluster and Benchmark data migration is set to Data Migration Completed. |
| Privileged account of destination instance | The password for the privileged account of the destination instance. |
| Select playback traffic | The time range of captured traffic to replay. |
| Playback speed | The replay rate relative to the original traffic rate. A value of 1 replays at the original rate. The value must be a positive integer. Valid values: 1 to 30. If the specified rate exceeds the maximum the destination instance can handle, the traffic replays at the maximum supported rate. |
| ECS that deploys stress testing program | The ECS instance that runs the stress testing client. Select DAS Automatic Purchase and Deployment to let the system create a pay-as-you-go ECS instance based on the source QPS and playback rate. To use an existing ECS instance, click Add, select the instance, click Generate Deployment Command, and run the command on the ECS instance. Also run sudo yum install -y java-1.8.0-openjdk to install a Java client on the instance. The recommended version is Java 8. |
Choose a benchmark data migration method
Select the method that matches how your baseline data will reach the destination instance.
| Method | When to use |
|---|---|
| Restore by Backup | The source instance data needs to be cloned to the destination. Select By Time Point to restore to a specific point in time, or By Backup Set to restore from a specific backup. If you select By Backup Set and do not have the required permissions, click DAS Service-linked Role to grant the associated role to your account. In the message that appears, click OK. |
| Data Migration Completed | Data from the source is already migrated to the destination. No Data Transmission Service (DTS) task is needed. The table schema and data types of the destination must exactly match those of the source—a mismatch prevents the stress test from running. |
| Enter DTS Task ID | You have an existing DTS migration task. Create the task in the DTS console and enter the task ID in the Migration Task ID field. For more information, see Data migration. |
| Create DTS migration task | Create a DTS migration task directly from this page without going to the DTS console. |
The migration methods available depend on the destination database type.
Step 3: Start the task
Click Next. After the precheck completes, click OK to create the task.
Step 4: Monitor and manage the task
In the Actions column, you can:
Click Details to open the Intelligent Stress Testing Details page and track task status and results.
Click Terminate to stop the task before it completes.
Click Delete to remove the task.
Interpret the results
On the Intelligent Stress Testing Details page, four tabs let you compare the source and destination. Focus on divergences—significant differences between source and destination behavior that indicate the destination may not sustain the target load or configuration.
| Tab | What to check |
|---|---|
| Overview | Side-by-side summary of basic metrics from the source and destination, before and after the stress test. |
| Performance trend comparison | Time-series charts of performance metrics for the source and destination, before and after the stress test. Look for significant divergences that indicate the destination cannot sustain the target load. |
| SQL comparison | Execution performance for individual SQL statements on both instances. This tab is populated only when autonomy features are enabled on the destination instance before the stress test starts. Use this tab to identify queries that degrade under load and determine whether you need to upgrade the database engine or change instance specifications. To enable autonomy features, see Enable or disable autonomy features. |
| Parameter comparison | Values of important configuration parameters on the source and destination. Differences here can explain performance gaps. |
Clean up
After the stress test, go to the Intelligent Stress Testing Details page and release the ECS instance that ran the stress testing client if you no longer need it.