AliCloudDB’s Secrets for Scaling During Double‑11 Traffic

Elastic Scaling

Most users perform elastic scaling before Double‑11. Two types exist: in‑machine upgrade (e.g., 6G/6C to 12G/12C) when resources suffice, and cross‑machine upgrade when they do not. In‑machine scaling upgrades the standby instance first, restarts it, then switches primary‑standby roles, avoiding a primary restart. Cross‑machine scaling migrates data using the latest backup and real‑time logs, which can be time‑consuming if backups are large.

Access Links

Two modes: High‑Security and Standard. High‑Security adds a proxy layer that parses requests, applies SQL interception rules, prevents SQL injection, reduces connection drops by ~90%, supports both internal and external IPs, and buffers short‑lived connections, at the cost of ~5% higher latency.

Architecture Design

Like building a solid house, the database foundation must be robust. During Double‑11 traffic spikes, hidden issues surface, so a well‑designed architecture is essential.

Read/Write Separation

RDS supports read‑only nodes; the primary handles writes and latency‑sensitive operations, while read‑only nodes handle complex analytics. This requires MySQL 5.6 or later and supports up to five read‑only nodes. Parallel replication reduces primary‑standby lag.

Engine & Field Choices

TokuDB offers 5‑7× higher compression than InnoDB, suitable for write‑heavy, read‑light workloads, with fast online DDL. However, it adds latency and is unsuitable for large fields. Large fields (VARCHAR(8000), TEXT, BLOB) increase binlog volume; consider splitting them into separate tables or external storage.

Index Design

Common mistakes include creating single‑column indexes for each predicate (MySQL uses only one) and overly large composite indexes. For a query like

SELECT person_role_id FROM movie WHERE movie_id=1000 AND role_id=1 ORDER BY nr_role DESC

, a composite index on (movie_id, role_id, nr_role, person_role_id) is optimal.

High‑Availability Configuration

RDS provides primary‑standby HA within a single AZ or across multiple AZs. Synchronization uses async or semi‑sync binlog replication. Multi‑AZ setups improve fault tolerance but may reduce write performance due to semi‑sync latency. Cross‑data‑center disaster recovery can be achieved with DTS between regions (e.g., Hangzhou and Shanghai).

Performance & Parameter Optimization

When QPS spikes (e.g., >20 k), analyze slow‑query logs, identify missing indexes or poor schema design, and add caching. Key parameters to tune include rds_max_tmp_disk_space, tokudb_buffer_pool_ratio, max_statement_time, and rds_threads_running_high_watermark for high‑concurrency scenarios.

Since 2015, Alibaba Cloud’s disaster‑recovery service enables automatic failover within 30 minutes, ensuring continuous operation during extreme events such as network outages or power failures.