由真实指标驱动的迁移定容：为什么 8 vCPU 的 EC2 变成了 4 OCPU（以及托管 MySQL 的坑）

按指标定容，而非凭直觉

迁移是停止为无人使用的容量付费的好时机。源服务器是一台 c6g.2xlarge 的 EC2（8 vCPU），但 CloudWatch 里的平均 CPU 是 6.6%——相当于约 0.5 个有效 vCPU。按真实指标而非旧实例为目标定容，把 VM 降到了 4 OCPU / 16 GB 的 A1.Flex，余量充足。

# 该周期内源 EC2 的平均/峰值 CPU（定容依据）
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0aaaa1111aaaa1111 \
  --start-time 2026-03-01T00:00:00Z --end-time 2026-04-01T00:00:00Z \
  --period 86400 --statistics Average Maximum --query 'Datapoints[].{d:Timestamp,avg:Average,max:Maximum}' --output table

对于数据库（RDS db.t3.large），重要的指标不止 CPU：CPU 峰值 99.7%、连接峰值 202、存储用了 30 GB 中的 9 GB。CPU 饱和 + 连接数高 = 数据库是瓶颈，托管 MySQL（MDS）的定容必须尊重这一点。

坑一：已到 EOL 的 shape 和版本

在 MySQL Database Service 的预置中，两个 EOL 差点被忽略：

VM.Standard.E2.1 shape 已 EOL → 使用 MySQL.2 系列（MDS 专用 shape），而非一个生命周期结束的通用计算 shape。

MySQL 8.0 已 EOL（2026 年 4 月）→ 直接预置在 8.4.8 LTS（支持到 2032）。迁到一个几个月后就消亡的版本是注定的返工。

坑二：必须放在 tenancy root 的策略

用 NSG（--nsg-ids）创建 MDS 时，命令以 AuthorizationFailed 失败——尽管用户在 compartment 里有权限。原因是：MySQL 服务需要代表用户管理网络，而那条策略必须放在 TENANCY ROOT，而非 compartment：

# 放在 TENANCY（root）层级的策略，而非 compartment：
Allow service mysql to manage virtual-network-family in tenancy

# 且用户需要：
NETWORK_SECURITY_GROUP_UPDATE_MEMBERS

OCI 上的 AuthorizationFailed 很少是"compartment 缺权限"。对于会触碰你网络的托管服务（MDS、OKE、LB），service 策略放在 tenancy root。

坑三：临时 IP 不会变成保留 IP

MDS 默认获得的私有 IP 是临时的，不会转换为保留 IP。要得到一个稳定地址（应用可以放心指向），路径是删除并以 RESERVED 重建，引用 private-ip-id：

oci network private-ip update --private-ip-id ocid1.privateip.oc1..aaaaEXAMPLE \
  --vnic-id ocid1.vnic.oc1..aaaaEXAMPLE   # 临时默认不会转换
# → 新建一个 RESERVED 并把应用重新指向它

MDS 需要 15–25 分钟才能达到 ACTIVE——规划好窗口。数据库 cutover 之后，我们在放流量之前通过比较记录数（例如 12,636 篇文章）的源 × 目标来验证完整性。

经验教训

1. 按 CloudWatch 定容，而非旧实例。8 vCPU 平均 6.6% = 浪费的容量；真实指标定义目标。

2. 同时检查 shape 和版本的 EOL。预置在 LTS（MySQL 8.4）和受支持的 shape（MySQL.2）上；迁到 EOL 的东西是返工。

3. 托管服务的策略放在 tenancy root。带 NSG 的 AuthorizationFailed = 缺 'Allow service mysql to manage virtual-network-family in tenancy'。

4. 放流量前验证记录数。cutover 后比较源×目标记录数，是防止静默丢失的廉价检查。

结论

迁移是让容量与真实用量对齐的最佳时机——一台跑在 6.6% 的 8 vCPU EC2 并不需要 8 vCPU。但托管 MySQL 用一堆坑收取它的过路费：EOL 的 shape/版本、一条住在 tenancy root 的 service 策略、以及一个不会转换的临时 IP。用指标定容，用清单别绊倒。