# First Time on Managed MySQL: A Practical Guide to Huawei Cloud RDS

> Migrating from self-hosted MySQL on ECS to Huawei Cloud RDS for MySQL — a step-by-step guide covering connectivity, configuration, and the key pitfalls that catch first-time RDS users.

---

LLMS index: [llms.txt](/llms.txt)

---

Most teams who've run MySQL on ECS before have a well-worn mental model: SSH in, edit `my.cnf`, tail the error log, restart the service. When switching to a managed RDS service for the first time, the technical lift is actually small — but the places where things go wrong are predictable, and almost always tied to habits carried over from self-hosted setups.

This guide walks through the full process of connecting your application to a new Huawei Cloud RDS for MySQL instance, with specific attention to the differences that tend to surprise teams coming from self-hosted MySQL.

---

## Implementation Steps

### 1. Create the RDS Instance

When provisioning the instance in the Huawei Cloud console, one decision matters above everything else: **the Region and VPC must match your business ECS**.

This is not adjustable after the fact. Once an RDS instance is created, its VPC assignment is fixed. If you later discover the RDS and ECS are in different VPCs, your options are to rebuild the instance or configure VPC peering — both are avoidable headaches. Getting Region and VPC right at creation time is the foundation for everything that follows.

### 2. Initialize the Database and Credentials

Once the instance is running, use the RDS console to:

- Create the target database(s) for your application
- Create a dedicated database user — **do not use the root account** for application connections
- Grant only the permissions the application actually needs: typically `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, and `DROP`

Least-privilege matters here. An application account that can only do what it needs limits the blast radius if credentials are ever compromised.

### 3. Update the Application Configuration

Locate your application's database configuration file and update the connection parameters:

| Parameter | Old Value (self-hosted) | New Value (RDS) |
|---|---|---|
| Host | ECS internal IP | RDS internal domain or internal IP |
| Port | 3306 | 3306 (default, may vary) |
| Database | original database name | database created in step 2 |
| User | original account | account created in step 2 |
| Password | original password | password set in RDS console |

**Prefer the RDS internal domain name over the internal IP.** The domain name remains stable across primary/standby failovers; the IP address may change. Using the domain means your application survives a failover without a config update.

### 4. Verify Network Connectivity

Before restarting your application, test the connection from the ECS directly:

```bash
mysql -h <RDS-internal-address> -u <username> -P 3306 -p
```

Or test the port first if MySQL client isn't installed:

```bash
telnet <RDS-internal-address> 3306
```

**If this fails, check the security group first** — it's the most common cause of connectivity failures for new RDS users. See the section below.

### 5. Start the Application and Run Full Tests

With connectivity confirmed and config updated, start the application and run a complete functional regression. Verify that all read and write paths work as expected before treating the deployment as done.

---

## Things That Catch First-Time RDS Users

These are the areas where managed RDS behaves differently from self-hosted MySQL — and where most issues originate.

### ⚠️ Security Group Rules (the #1 issue)

RDS does not expose port 3306 to anything by default. You need to explicitly allow access:

1. Find the **security group** attached to your RDS instance
2. Add an **inbound rule**: Protocol TCP, Port 3306, Source = the internal IP of your ECS (e.g. `192.168.1.10/32`)

Resist the temptation to set the source to `0.0.0.0/0`. That exposes the database port to the entire VPC or beyond. Restrict it to the specific IPs that need access.

### ⚠️ Character Set and Timezone

A freshly created RDS instance doesn't necessarily default to `utf8mb4`. If your application handles emoji, East Asian characters, or any non-BMP Unicode, verify this before loading data:

```sql
SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'time_zone';
```

Set these explicitly in the RDS console under **Parameter Groups**:

```
character_set_server = utf8mb4
collation_server     = utf8mb4_unicode_ci
time_zone            = Asia/Shanghai
```

Timezone mismatches are particularly insidious — they cause `DATETIME` values to shift silently on read, and the symptom often looks like a bug in application logic rather than a configuration issue.

### ⚠️ Key Parameters to Review

RDS ships with a default parameter group that may differ from your self-hosted configuration. Three parameters deserve specific attention:

**`lower_case_table_names` (table name case sensitivity)**

On RDS for MySQL 8.0, **this parameter cannot be changed after instance creation**. You must decide at provisioning time:

- `0` — case-sensitive (Linux default, recommended for production)
- `1` — case-insensitive (common on Windows; needed when migrating from a Windows-hosted MySQL)

If you're migrating an existing database, verify what the source instance uses before creating the RDS instance.

**`innodb_flush_log_at_trx_commit` and `sync_binlog`**

Both default to `1` on RDS, meaning every transaction commit forces a disk flush. This is the safest configuration but has a write performance cost.

| Setting | Write Performance | Data Safety |
|---|---|---|
| Both = 1 | Lower | Highest (minimal data loss on crash) |
| flush=2, sync=0 | Higher | Lower (up to ~1 second of data loss possible) |

If your workload is write-intensive and you've benchmarked a bottleneck here, you can tune these — but understand the trade-off before doing so.

### ⚠️ You No Longer Manage the OS

This is the most significant mindset shift, and it's worth being explicit about it.

With self-hosted MySQL, your operational toolkit is SSH + a text editor + `systemctl`. With RDS, none of that exists. There's no shell, no config file to edit directly, no `service mysql restart`.

The mapping looks like this:

| Self-hosted operation | RDS equivalent |
|---|---|
| Edit `my.cnf` | Console → Parameter Groups |
| `tail -f error.log` | Console → Log Management |
| Manual backup via `mysqldump` | Console → Backup and Recovery |
| Monitor slow queries | Console → Slow Query Logs |
| Restart the service | Console → Restart Instance (use with caution) |

This is a feature, not a limitation — it means Huawei Cloud is handling HA, failover, and backup infrastructure. But it requires learning to operate through the console and API rather than the command line.

### ⚠️ Set a Backup Policy That Fits Your Business

RDS enables automated backups by default, but the default settings may not match your recovery requirements. Configure these early:

- **Backup window**: set to off-peak hours (e.g. 02:00–04:00)
- **Retention period**: default is 7 days; adjust to 14–30 days based on criticality
- **Test restores periodically**: a backup you've never restored from is a backup you can't rely on

---

## Summary

The migration itself is straightforward: update the connection config, align a handful of parameters, confirm the network path is open, and test.

The places that actually cause problems are almost always the same three: security group rules blocking port 3306, character set or timezone mismatches discovered only after data is in the database, and `lower_case_table_names` set wrong because it wasn't checked before the instance was created.

Address those three upfront and the rest of the cutover is mostly mechanical.