阿里云SLB、ECS、OSS、RDS四件套迁移实战：顺序、命令与避坑指南

简介：这份文档面向云计算运维、后端开发与架构入门人员，围绕阿里云SLB、ECS、OSS、RDS四大核心服务，梳理各服务的概念体系与在系统数据迁移中的实际应用，帮助读者建立从负载均衡、云服务器到对象存储与关系数据库的整体认知。资源包内含1个docx文件，约1.78MB，以图文并茂的文档形式呈现，便于按章节查阅与整理笔记。内容涵盖OSS的桶、对象与存储类型，RDS的实例、数据库与账户管理，SLB的监听器、后端服务器、会话保持及健康检查等关键知识点，并延伸至产品架构、高可用设计与典型应用场景，目录层级清晰，适合作为迁移方案设计时的速查手册。目前已有777人学习下载，可作为云计算入门与数据迁移实践阶段的参考材料。

1. 阿里云四件套迁移：为什么“搬过去”比“搭起来”更容易翻车

做过一次完整的阿里云 SLB、ECS、OSS、RDS 加系统数据迁移，你大概率会有一个反直觉的结论：新环境搭起来不难，难的是把老系统连数据带流量一起搬过去，还不让业务断。SLB 管入口流量，ECS 跑应用，OSS 存文件和静态资源，RDS 扛结构化数据，这四样东西单独看都是标准产品，可一旦要整体迁移，它们之间的依赖关系就会变成一张牵一发动全身的网。我见过太多团队把 ECS 镜像迁完、RDS 导完，结果 SLB 后端服务器组没同步、OSS 内网 endpoint 没改、应用连的还是旧 RDS 地址，上线当晚直接翻车。这篇笔记就按一线实操的顺序，把 SLB、ECS、OSS、RDS 与系统数据迁移的完整路径拆开讲：先讲清楚每层迁移的选型逻辑，再落到具体命令和参数，最后把那些只有踩过才知道的坑摆出来。适合正在做上云迁移、机房搬迁或者跨账号环境复制的后端和运维同学，新手能照着步骤走，熟手能对着边界条件查漏补缺。

2. 迁移前把四层依赖画清楚：SLB、ECS、OSS、RDS 谁先动

2.1 为什么迁移顺序错了，后面全是返工

四层里最先确定的不是 ECS，而是 RDS。原因很直接：RDS 承载的是有状态数据，迁移窗口最长、回滚成本最高，而且 ECS 上的应用配置、OSS 的访问策略往往都跟数据库地址和账号绑定。常见做法是先把 RDS 的目标实例建好、数据同步跑起来，再动 ECS，最后切 SLB 流量，OSS 则根据是“迁文件”还是“换挂载点”决定放在 ECS 之前还是之后。如果反过来先切 SLB，流量进来了但后端 ECS 连不上新 RDS，用户看到的就是 502 和超时，这种翻车现场我经历过一次就再也不想经历第二次。

依赖关系可以用一张简单的表固定下来，迁移前先填好，后面每一步都对着它检查：

这张表的价值在于：每次改动前问一句“我动的东西有没有人还在依赖旧地址”，能挡掉大部分低级错误。

2.2 迁移前必须盘点的五类信息

动手之前，把下面五类信息整理成一份清单，缺一项都别开始：

第一，网络规划。旧环境的 VPC 网段、交换机可用区、SLB 是公网还是私网、ECS 和 RDS 是否同 VPC。跨 VPC 迁移时，RDS 的内网地址会变，ECS 上的连接串必须同步改。

第二，账号与权限。目标账号的 RAM 用户是否有 ECS、RDS、OSS、SLB 的操作权限，OSS 的 Bucket 策略、RDS 的白名单、SLB 的证书都要提前确认。热搜里常出现的“阿里云认证 sdk”问题，很多就是迁移后 AccessKey 没换、SDK 初始化失败导致的。

第三，数据量级。RDS 的库表大小、OSS 的对象数量和总容量、ECS 系统盘的数据量。这决定你用停机迁移还是在线同步，也决定传输工具的选择。

第四，域名与证书。SLB 上绑的域名、HTTPS 证书、后端 ECS 的健康检查路径。证书如果用了免费证书，注意续期时间，别迁移当天正好过期。

第五，回滚方案。旧环境在切换后至少保留 24 到 48 小时，RDS 保留只读从库或快照，SLB 保留旧后端组，OSS 不删源 Bucket。没有回滚方案的迁移不叫迁移，叫赌博。

2.3 用最小成本验证连通性

正式迁移前，先在目标环境起一台临时 ECS，装好客户端，手动测试到新 RDS 和内网 OSS 的连通性。这一步花十分钟，能省掉后面几小时的排查。

# 测试到 RDS 的连通性，替换为实际地址和端口 mysql -h rm-xxxxxxxx.mysql.rds.aliyuncs.com -P 3306 -u testuser -p -e "SELECT 1;" # 测试 OSS 内网 endpoint 连通性，使用 ossutil 或 curl curl -I http://oss-cn-hangzhou-internal.aliyuncs.com # 查看本机路由和 DNS 解析，确认走的是内网 ip route get 100.64.0.1 nslookup rm-xxxxxxxx.mysql.rds.aliyuncs.com

逻辑说明：第一条命令验证 RDS 账号、白名单、网络是否通；第二条验证 OSS 内网 endpoint 是否可达，注意内网 endpoint 带-internal后缀；第三条确认 ECS 的默认路由和 DNS 解析结果，如果解析到公网地址，说明 VPC 或 DNS 配置有问题。参数上，RDS 地址在控制台“数据库连接”里看，OSS endpoint 在 Bucket 概览页看，内网和外网地址不要混用。

3. RDS 与系统数据迁移：DTS 加物理备份怎么选

3.1 逻辑迁移和物理迁移的适用边界

RDS 迁移有两条路：逻辑迁移和物理迁移。逻辑迁移用 DTS 或者 mysqldump，适合数据量在几十 GB 以内、可以接受一定停机窗口、需要跨版本或跨引擎的场景。物理迁移用备份文件恢复，适合上百 GB 的大库、要求停机时间极短、版本一致的场景。我一般会先看数据量：小于 50GB 且允许半小时停机，走 DTS；大于 100GB 或者停机窗口只有几分钟，走物理备份加增量同步。

DTS 的优势是支持结构迁移、全量迁移和增量同步，能在业务不停的情况下把数据追平，最后短暂切换。物理迁移的优势是快，但要求源和目标版本一致，且恢复期间目标库不可写。热搜里“阿里云 rds 使用”相关的问题，很多集中在迁移后连接数、参数组不一致上，这个后面避坑章节会展开。

3.2 用 DTS 做在线迁移的配置步骤

DTS 的配置分四步：创建迁移任务、配置源和目标、选择迁移对象、启动预检查并启动任务。

# 这里用阿里云 CLI 演示创建 DTS 迁移任务的关键参数 # 实际生产建议在控制台操作，CLI 适合批量或自动化场景 aliyun dts CreateMigrationJob \ --RegionId cn-hangzhou \ --MigrationJobClass "large" \ --MigrationJobName "rds-migrate-prod" \ --SourceEndpoint.InstanceType "RDS" \ --SourceEndpoint.InstanceID "rm-old123456" \ --DestinationEndpoint.InstanceType "RDS" \ --DestinationEndpoint.InstanceID "rm-new789012" \ --MigrationObject '{"Databases":[{"DBName":"appdb"}]}' \ --MigrationMode '{"StructureMigration":true,"DataMigration":true,"IncrementMigration":true}'

逻辑说明：MigrationJobClass决定 DTS 任务的规格，大库选 large 或以上，否则同步速度跟不上；SourceEndpoint和DestinationEndpoint分别指向旧和新 RDS 实例；MigrationObject指定要迁移的库，可以精确到表；MigrationMode三个布尔值分别控制结构、全量和增量，增量同步依赖 binlog，源库必须开启 binlog 且保留足够时长。参数上，如果源库是 MySQL 8.0，注意 binlog 格式必须是 ROW，否则增量同步会失败。

启动后不要急着切，先看延迟。DTS 控制台会显示增量同步的延迟时间，等延迟稳定在秒级且业务低峰期，再做应用连接串切换。切换时先停写、等延迟归零、改连接串、验证、再开写。

3.3 物理备份恢复的关键命令

如果走物理备份，流程是：在旧 RDS 上创建物理备份、下载备份文件、上传到目标 RDS 的 OSS Bucket、在目标实例上恢复。

# 在旧实例创建物理备份后，通过 RDS 控制台下载 # 上传到目标实例同地域的 OSS Bucket ossutil cp backup.tar.gz oss://rds-backup-bucket/hangzhou/ --region cn-hangzhou # 在目标 RDS 控制台选择“从 OSS 恢复”，指定 Bucket 和文件路径 # 恢复完成后验证数据一致性 mysql -h rm-new789012.mysql.rds.aliyuncs.com -u admin -p -e " SELECT table_schema, SUM(data_length+index_length)/1024/1024 AS size_mb FROM information_schema.tables WHERE table_schema='appdb' GROUP BY table_schema;"

逻辑说明：物理备份文件必须放在目标 RDS 同地域的 OSS Bucket，跨地域恢复会失败；恢复期间目标实例不可写，要提前安排停机窗口；恢复后用 information_schema 对比库表大小，再抽查几张核心表的行数和最新时间戳。参数上，--region要和 RDS 地域一致，Bucket 权限要给 RDS 服务授权。

3.4 系统数据迁移不只是数据库

“系统数据”往往还包括 ECS 上的配置文件、日志、用户上传的附件。这些数据分两类：一类是应用配置，跟着 ECS 镜像走；另一类是运行时产生的文件，如果已经用了 OSS，迁移重点是 Bucket 同步；如果还在 ECS 本地盘，需要用 rsync 或 ossutil 搬到 OSS。

# 把 ECS 本地目录同步到 OSS，保留目录结构 ossutil sync /data/uploads/ oss://app-uploads-bucket/uploads/ \ --delete \ --exclude "*.tmp" \ --jobs 10 # 用 rsync 在两台 ECS 之间同步配置和日志 rsync -avz --progress /etc/app/ root@new-ecs:/etc/app/

逻辑说明：ossutil sync会对比源和目标，只传差异文件，--delete表示目标端删除源端已不存在的文件，--exclude过滤临时文件，--jobs控制并发数。rsync 适合 ECS 之间的同步，-a保留权限和时间戳，-v输出详情，-z压缩传输。注意 rsync 走 SSH，要提前配好密钥，别在迁移窗口里输密码。

4. ECS 与 SLB 迁移：镜像复制和后端组切换的实操

4.1 自定义镜像跨地域复制的正确姿势

ECS 迁移最稳的方式是自定义镜像。先在旧实例创建镜像，再复制到目标地域，然后用镜像创建新实例。

# 创建自定义镜像 aliyun ecs CreateImage \ --RegionId cn-shanghai \ --InstanceId i-old123456 \ --ImageName "app-server-v1" \ --Description "prod app server before migration" # 复制镜像到目标地域 aliyun ecs CopyImage \ --RegionId cn-shanghai \ --ImageId m-xxxxxxxx \ --DestinationRegionId cn-hangzhou \ --DestinationImageName "app-server-v1-hz" # 用目标镜像创建实例 aliyun ecs RunInstances \ --RegionId cn-hangzhou \ --ImageId m-yyyyyyyy \ --InstanceType ecs.c6.xlarge \ --SecurityGroupId sg-xxxxxxxx \ --VSwitchId vsw-xxxxxxxx \ --Amount 2

逻辑说明：CreateImage会短暂影响实例性能，建议在低峰期做；CopyImage跨地域复制时间取决于镜像大小，几十 GB 的镜像可能要半小时以上；RunInstances创建实例时注意安全组和交换机要和目标 RDS、OSS 在同一 VPC。参数上，InstanceType按原实例规格选，Amount按后端服务器数量填。

镜像复制完成后，新 ECS 启动后第一件事是改配置：RDS 连接串、OSS endpoint、SLB 注册地址、日志路径。这些如果写在配置文件里，用 sed 批量替换；如果走配置中心，改配置中心的值。

4.2 SLB 后端服务器组的平滑切换

SLB 迁移的核心是后端服务器组。新 ECS 就绪后，先挂到 SLB 的新后端组，权重设低，观察健康检查通过，再逐步调权重，最后把旧后端组权重降到零并移除。

# 查询 SLB 实例的后端服务器组 aliyun slb DescribeVServerGroups \ --RegionId cn-hangzhou \ --LoadBalancerId lb-xxxxxxxx # 添加新 ECS 到后端组，权重设为 10 aliyun slb AddVServerGroupBackendServers \ --RegionId cn-hangzhou \ --VServerGroupId rsp-xxxxxxxx \ --BackendServers '[{"ServerId":"i-new123456","Weight":10,"Port":8080}]' # 观察一段时间后，调整旧后端权重 aliyun slb SetVServerGroupAttribute \ --RegionId cn-hangzhou \ --VServerGroupId rsp-xxxxxxxx \ --BackendServers '[{"ServerId":"i-old123456","Weight":0,"Port":8080}]'

逻辑说明：AddVServerGroupBackendServers把新 ECS 加入后端组，权重 10 表示只接收少量流量，用于灰度验证；SetVServerGroupAttribute把旧后端权重设为 0，相当于摘除但不删除，方便回滚。参数上，Port要和 ECS 上应用监听的端口一致，健康检查路径在监听配置里设置，确保新 ECS 能返回 200。

切换过程中要盯着 SLB 的监控：后端响应时间、健康检查状态、连接数。如果新 ECS 的健康检查不通过，先查安全组是否放行 SLB 的健康检查网段，再查应用是否正常启动。

4.3 域名解析和证书的收尾

SLB 切换完成后，如果域名解析指向的是 SLB 的公网 IP，需要确认解析没有缓存问题。HTTPS 证书如果换了新的，要在 SLB 监听上更新证书，并验证证书链完整。

# 验证 HTTPS 证书和响应 curl -I https://app.example.com --resolve app.example.com:443:1.2.3.4 # 查看证书有效期 echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null | openssl x509 -noout -dates

逻辑说明：--resolve强制指定 IP，绕过本地 DNS 缓存，验证新 SLB 是否正常；openssl s_client查看证书的生效和过期时间。参数上，-servername用于 SNI，多域名证书必须带这个参数。

5. OSS 迁移与权限配置：别让内网 endpoint 成为黑匣子

5.1 Bucket 跨账号或跨地域复制的三种方式

OSS 迁移分三种情况：同账号跨地域复制、跨账号复制、本地到 OSS。同账号跨地域用 OSS 控制台的跨区域复制功能，配置简单但要求源和目标 Bucket 同账号。跨账号用 ossutil 的 sync 或者 OSS 的跨账号授权。本地到 OSS 用 ossutil 或 OSS Browser。

# 配置 ossutil，使用目标账号的 AccessKey ossutil config -e oss-cn-hangzhou.aliyuncs.com -i LTAI5txxxx -k xxxx # 跨账号同步，源 Bucket 需要给目标账号授权 ossutil sync oss://source-bucket/ oss://dest-bucket/ \ --jobs 20 \ --update \ --delete # 查看同步结果和失败列表 ossutil ls oss://dest-bucket/ -s --limited-num 100

逻辑说明：ossutil config设置 endpoint 和 AccessKey，注意 AccessKey 要有源 Bucket 的读权限和目标 Bucket 的写权限；sync的--update表示只传源端更新的文件，--delete删除目标端多余文件，--jobs提高并发。跨账号时，源 Bucket 的 Bucket Policy 要允许目标账号的 RAM 用户读取，否则会报 AccessDenied。

5.2 内网 endpoint 和权限策略的坑

OSS 迁移后最常见的问题是应用还在用外网 endpoint，导致流量走公网、产生费用、速度慢。ECS 和 OSS 同地域时，必须用内网 endpoint，格式是oss-cn-<region>-internal.aliyuncs.com。

# Python SDK 使用内网 endpoint 的示例 import oss2 auth = oss2.Auth('LTAI5txxxx', 'xxxx') # 注意 endpoint 带 -internal bucket = oss2.Bucket(auth, 'oss-cn-hangzhou-internal.aliyuncs.com', 'app-uploads-bucket') # 上传文件 bucket.put_object_from_file('uploads/test.jpg', '/data/test.jpg') # 生成带签名的下载 URL，有效期 3600 秒 url = bucket.sign_url('GET', 'uploads/test.jpg', 3600) print(url)

逻辑说明：oss2.Auth用 AccessKey 初始化，生产环境建议用 STS 临时凭证；Bucket的 endpoint 必须带-internal，否则走公网；sign_url生成临时下载链接，适合私有 Bucket。参数上，3600是 URL 有效期，按业务需要调整，别设太长。

权限策略方面，RAM 用户的最小权限原则要落实：只给需要的 Bucket 和操作，别用主账号 AccessKey。热搜里“阿里云存储桶”相关的问题，很多是 Bucket 权限设成了公共读写，迁移时顺手改成私有加签名 URL。

5.3 迁移后的数据一致性校验

OSS 迁移完不能只看文件数量，要校验关键文件的 MD5 或 CRC64。

# 用 ossutil 计算源和目标的 CRC64 ossutil hash crc64 oss://source-bucket/uploads/test.jpg ossutil hash crc64 oss://dest-bucket/uploads/test.jpg # 批量校验，输出不一致的文件 ossutil sync oss://source-bucket/ oss://dest-bucket/ --dry-run

逻辑说明：hash crc64计算单个文件的 CRC64 值，对比源和目标；sync --dry-run模拟同步，列出需要传输的文件，如果输出为空说明两边一致。参数上，CRC64 是 OSS 默认的校验算法，比 MD5 更适合大文件。

6. 迁移避坑与排查：五条血泪经验

6.1 现象：DTS 增量同步延迟一直涨

原因：源 RDS 的 binlog 保留时间太短，或者写入量超过 DTS 规格。解决：先查源库SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'，确保保留时间大于迁移窗口；再升 DTS 规格，或者分批迁移大表。

6.2 现象：新 ECS 连不上 RDS，报 timeout

原因：安全组没放行、RDS 白名单没加新 ECS 内网 IP、或者 VPC 不同。解决：在 RDS 控制台把新 ECS 的 IP 加入白名单，检查安全组入方向是否放行 3306，确认 ECS 和 RDS 在同一 VPC。如果跨 VPC，用云企业网打通。

6.3 现象：SLB 健康检查失败，后端 ECS 被摘除

原因：健康检查路径返回非 200、端口不对、或者 ECS 安全组没放行 SLB 的健康检查 IP。解决：在 ECS 上curl健康检查路径，确认返回 200；检查 SLB 监听的健康检查配置，端口和后端应用一致；安全组放行 SLB 的健康检查网段。

6.4 现象：OSS 上传报 AccessDenied

原因：AccessKey 权限不足、Bucket Policy 限制、或者 endpoint 用错。解决：用 RAM 用户检查权限策略，确认有目标 Bucket 的 PutObject 权限；检查 Bucket Policy 是否拒绝了当前账号；确认 endpoint 是内网还是外网，跨地域用外网。

6.5 现象：迁移后应用报数据库连接数满

原因：新 RDS 的参数组和旧实例不一致，最大连接数设小了。解决：对比新旧实例的参数组，把max_connections调到相同或更大；检查应用连接池配置，迁移后没改地址可能导致连接泄漏。

7. 迁移后的验证清单与一个自动化校验脚本

迁移完成不等于结束，我一般会跑一遍验证清单，再留一个自动化脚本定期检查。验证清单包括：RDS 主从状态、ECS 应用日志无 ERROR、SLB 后端全部健康、OSS 关键文件 CRC64 一致、域名解析指向新 SLB、证书有效期大于 30 天。

下面这个脚本把核心检查串起来，放在跳板机上每天跑一次，输出异常项。

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """迁移后核心组件健康检查脚本""" import subprocess import sys def check_rds(host, port, user, password): """检查 RDS 连通性和连接数""" cmd = f"mysql -h {host} -P {port} -u {user} -p{password} -e 'SHOW STATUS LIKE \"Threads_connected\";'" result = subprocess.run(cmd, shell=True, capture_output=True, text=True) if result.returncode != 0: return f"RDS 连接失败: {result.stderr}" return f"RDS 连接正常: {result.stdout.strip()}" def check_slb_health(lb_id, region): """检查 SLB 后端健康状态""" cmd = f"aliyun slb DescribeHealthStatus --RegionId {region} --LoadBalancerId {lb_id}" result = subprocess.run(cmd, shell=True, capture_output=True, text=True) if "unhealthy" in result.stdout.lower(): return "SLB 存在不健康后端" return "SLB 后端全部健康" def check_oss_file(bucket, key, endpoint): """检查 OSS 文件是否存在""" cmd = f"ossutil ls oss://{bucket}/{key} -e {endpoint}" result = subprocess.run(cmd, shell=True, capture_output=True, text=True) if "NoSuchKey" in result.stdout or result.returncode != 0: return f"OSS 文件缺失: {key}" return f"OSS 文件存在: {key}" if __name__ == "__main__": checks = [ check_rds("rm-new789012.mysql.rds.aliyuncs.com", 3306, "admin", "yourpassword"), check_slb_health("lb-xxxxxxxx", "cn-hangzhou"), check_oss_file("app-uploads-bucket", "uploads/health.check", "oss-cn-hangzhou-internal.aliyuncs.com"), ] for c in checks: print(c) if any("失败" in c or "缺失" in c or "不健康" in c for c in checks): sys.exit(1)

逻辑说明：check_rds用 mysql 客户端查连接数，返回非零说明网络或账号有问题；check_slb_health调阿里云 CLI 查后端健康状态，输出里出现 unhealthy 就告警；check_oss_file用 ossutil 检查关键文件是否存在。参数上，RDS 密码建议用环境变量传入，别硬编码；SLB 的 region 和实例 ID 按实际填；OSS endpoint 用内网地址。

这个脚本我一般放在 cron 里，每天早高峰前跑一次，输出发到运维群。迁移后前两周每天看，稳定后改成每周一次。说个我自己的习惯：每次迁移完，我会把旧环境的配置导出成一份文档，和新环境逐项对比，差异项标红。这个动作看起来笨，但帮我挡过好几次“以为改了其实没改”的低级错误。希望帮到你。

本文还有配套的精品资源，点击获取