Mastering Tencent Cloud MySQL: Instance Types, Replication, HA & Upgrades

1. Instance Types

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

Basic: a single node with low cost, but without data safety or availability guarantees; not recommended for production.

High‑Availability: primary‑secondary mode with real‑time hot standby, automatic fault detection and failover. Replication can be asynchronous, semi‑synchronous, or strong synchronous; default is async, upgradeable to strong sync with a primary and two secondaries.

Single‑Node High‑IO: a single physical node using local NVMe SSD, offering high I/O performance and cost‑effectiveness, typically used for read‑only instances to offload read traffic.

2. Replication Methods

Asynchronous replication

Master returns a response immediately after updating data, then replicates to the slave. This yields high performance and the slave’s unavailability does not affect the master, but data may be inconsistent if the master fails before the slave catches up.

Semi‑synchronous replication

Master sends updates to the slave, which writes them to the relay log and then acknowledges; the master waits for this acknowledgment before responding to the client. If replication errors occur, the master pauses and falls back to asynchronous mode.

Strong synchronous replication

Master waits until the slave has executed the updates before acknowledging the client, ensuring maximum consistency. Tencent Cloud MySQL strong sync uses a primary with two slaves, requiring only one slave to succeed.

3. High‑Availability Implementation

Primary node failure

Clients connect to the primary via VIP:Port; the slave continuously syncs via binlog.

If the primary host crashes, clients are automatically redirected to the slave, and the cloud creates a new primary‑slave HA instance, imports the latest cold backup, and syncs binlog.

After binlog catch‑up, the new primary takes over; the switch incurs only a brief, second‑level interruption.

Slave node failure

The client experience remains unchanged. The cloud automatically rebuilds the slave on a healthy host, imports the cold backup, and resynchronizes with the primary, restoring HA status.

4. Instance Upgrade

Upgrading includes both software version upgrades and hardware scaling.

After initiating an upgrade in the console, the cloud creates a new instance pair, imports the latest backup, and synchronizes binlog with the primary.

Once synchronization completes, users may switch immediately or during a maintenance window; the switchover takes seconds and the old instance is reclaimed.

The upgrade process does not interrupt database operations. The time consumed depends on backup import speed (≈50 GB/h) and binlog catch‑up.

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) and retains them for five days. To parse downloaded binlogs locally, the client MySQL version must match the CDB version; using mysqlbinlog 3.4 or newer is recommended.

6. Restore Methods

Restoring reverts the database to a previous point using cold backup and binlog. Three modes are available:

Normal restore: imports the full backup and then applies selected databases/tables; no speed limit but slower.

Fast restore: imports only the selected database‑level backup and binlog; cross‑database operations may cause failure.

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

7. Slow Query Optimization

Slow queries are SQL statements that consume excessive time, often causing high CPU usage. The default slow‑query threshold is 10 s; lowering it to 1 s helps identify problematic queries. Enabling

log_queries_not_using_indexes

records full‑table scans, but should not be left on permanently due to disk impact.

8. Space Accounting

Discrepancies between space reported by queries and the console arise from the MySQL “hole” effect—fragmentation that is not immediately reclaimed. Running

OPTIMIZE TABLE

during low‑traffic periods can reclaim this space.

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