Understanding Cloud MySQL: Instance Types, Replication Modes, and High Availability

When using MySQL in the cloud, many users have questions about CDB; this article introduces key concepts to better understand cloud MySQL.

1. Instance Types

Cloud MySQL currently supports three architectures: Basic, High‑Availability, and Single‑Node High‑IO.

Basic is a single‑node deployment with low cost and high price‑performance, but data safety and availability are not guaranteed, so it is not recommended for production.

High‑Availability uses a primary‑plus‑replica model with real‑time hot standby, offering automatic fault detection and failover. Replication can be asynchronous, semi‑synchronous, or strong synchronous; the default is asynchronous, but it can be upgraded to strong synchronous with a primary‑plus‑two‑replica configuration.

Single‑Node High‑IO deploys on a single physical node with local NVMe SSD storage, providing strong I/O performance for read‑only instances and read‑write separation scenarios.

2. Replication Modes

Asynchronous Replication : After the master executes an update, it immediately returns a response to the client and then replicates the data to the slave. The master does not wait for the slave, offering high performance but risking data inconsistency if the master fails before the slave catches up.

Semi‑Synchronous Replication : The master sends updates to the slave, which writes them to the relay log and then acknowledges success; the master waits for this acknowledgment before responding to the client. If the slave becomes unavailable, the master temporarily falls back to asynchronous mode.

Strong Synchronous Replication : The master waits until the slave has fully executed the update before responding to the client, ensuring maximum data consistency. The cloud service uses a primary‑plus‑two‑replica setup where only one replica needs to succeed, improving availability.

3. High‑Availability Implementation

When the primary host fails, the client’s connection (via VIP:Port) is switched to the replica, which continues to serve reads and writes. The platform creates a new primary‑replica pair, imports the latest backup, and synchronizes binlogs. After synchronization, a manual or automatic switch occurs with only a brief interruption.

If the replica host fails, the platform automatically rebuilds the replica on a healthy machine, imports the backup, and resynchronizes with the primary, restoring the high‑availability state without affecting the client.

4. Instance Upgrade

Upgrading includes both version upgrades and hardware scaling. After initiating an upgrade, the platform creates a new instance pair, imports the latest backup, and synchronizes binlogs. Users can switch to the new instance immediately or during a maintenance window; the switchover takes seconds and does not interrupt normal database usage.

The upgrade time depends on backup import speed (approximately 50 GB/h) and binlog replay, which varies with data volume.

5. Binlog Overview

Binlog records all data‑changing statements and is essential for replication and point‑in‑time recovery. Cloud MySQL generates a new binlog file every 1 GB (or 256 MB for some instances). Binlogs are retained for five days; recovery is limited to this window.

When downloading binlogs for local analysis, ensure the MySQL client version matches the CDB version (recommended mysqlbinlog 3.4+).

6. Rollback Methods

Rollback restores the database to a previous point using backups and binlogs. Three modes are available:

Normal rollback : Imports a full backup and applies selected databases/tables; no speed limit but slower.

Fast rollback : Imports only the selected database‑level backup and binlog; cross‑database operations may fail.

Ultra‑fast rollback : Imports only the selected table‑level backup and binlog; requires manual table selection and recreation if the table was dropped.

7. Slow Query Optimization

Slow queries are SQL statements that consume excessive time. The default slow‑query threshold is 10 seconds; lowering it to 1 second helps identify problematic queries. Enabling log_queries_not_using_indexes records full‑table scans without indexes, but should not be left on permanently due to disk impact.

8. MySQL Storage Discrepancy

The space reported by queries can differ from the console due to MySQL’s “hole” effect—fragmented space not reclaimed. Running OPTIMIZE TABLE during low‑traffic periods can reclaim this space.

Source: https://cloud.tencent.com/developer/article/1579285