L实例（需先迁到云服务再迁移到自建） mysqldump导出导入 全量迁移 不依赖网络，操作较为复杂，只能全量迁移，不支持增量数据同步 停服时间窗较长场景 主从复制replication 全量+增量迁移 操作复杂 仅适用于源端和目标端均为自建MySQL数据库，由于源端和目的端版本
不停服切换方案 应用层切换不停服方案 若只涉及到应用层的切换，可参考章节 停服切换方案 中提到的应用灰度切流方案，切换期间不停服。 数据层或应用整体切换不停服方案 准备工作： 华为云应用层和数据层已完成迁移； 华为云应用层和数据层已完成业务验证，可正常使用。 业务切换： 修改两边
云上可扩展性 云相较于传统IDC非常大的一个优势具备丰富的资源和强大的扩展能力；根据业务场景的不同需求，可以将扩展能力分成如下3类： 纵向（垂直）扩展：适用于单体应用、独立应用、有状态应用等场景下，随着业务不断发展和变化，需要快速升级硬件以应对业务变化。如在进行一些促销活动时，对
部署主要是进行云上目标环境的资源开通和配置，并做好上云前的各项检查和测试，并进行迁移环境的准备。 要按照应用部署架构设计方案进行云上资源的开通和配置，云上资源开通主要有如下3种方式： 在云平台Console控制台手动创建云资源。 编写脚本或通过自动化平台对接，调用云平台的API接口，批量发放云资源，每个云服务都有
Master高可用：ES Master节点3AZ分布（2+2+1）。在任意一个可用区不可用时，集群依旧有超过半数的法定主节点选举个数，保证Master的正常选主。 数据节点：ES Data节点3AZ分布（2+2+1）。索引shard分片至少设置2副本，加上主分片副本有3副本。假如3AZ中任意一个AZ整
250K 2~5ms 125MB/s/TiB 100 百万级 1~3ms 250MB/s/TiB 100 百万级 1~3ms 500MB/s/TiB 200 百万级 1~3ms 1000MB/s/TiB 200 百万级 1~3ms SFS通用型 容量型 50 100K 7ms 性能型 200
幅加速新产品的TTM和已有产品的迭代周期。如果新产品的TTM从6个月缩短至3个月，假设新产品每个月带来200万元的收入，那么提前3个月上市将带来600万元的额外收入。对于已有产品，如果将其版本迭代周期从3个月缩短至1个月，假设新版本每个月能带来100万元收入，那么新版本提前2个月上市将带来200万元额外收入。
设计切换方案 如何选择停服不停服 停服切换方案 停写不停读切换方案 不停服切换方案 父主题： 应用迁移上云
停服切换方案 停服时长评估 基于华为云的迁移经验，切换期间大部分应用停服时长在0.5小时~3.5小时，下面停服时长可供参考： 表1 停服时长分析 上云迁移停服时长评估 总停服时长（36~211分钟） 源端停机（12~75分钟） 增量数据同步及校验（6~40分钟） 目的端拉起（18~96分钟）
-port）； 使用备份功能将rdb文件输出到S3中。 备份数据上传至OBS： EC2：使用OBS Browser/obsutil工具将备份文件（aof/rdb）上传至DCS所在的Region的OBS。 S3：创建OMS任务，将S3中的rdb备份文件迁移传输到DCS所在的Region的OBS。
业务系统的可用性SLO 业务系统全年可用性SLO从99%提升到99.95%。 新产品或新版本的TTM 将新产品的TTM从6个月缩短至3个月，已有产品的迭代周期从3个月缩短至1个月。 不合规及安全事件造成的经济损失 将不合规及安全事件数量减少75%，经济损失减少75%。 IT基础设施的TCO
计划开始时间 计划结束时间 1 XXX 1.1 - - - 必须解决 - - - - - 2 1.1 - - - 必须解决 - - - - - 3 1.2 - - - 必须解决 - - - - - 4 1.3 - - - 必须解决 - - - - - 5 1.3 - - - 必须解决 -
如何选择停服不停服 业务切换是整个上云迁移的关键环节，出问题会直接影响企业业务，不同业务对停服的要求是不一样的，比如，有些业务在切换期间是不允许停服的，停服会造成较大的业务损失；有些业务在切换期间是允许停服的，比如办公OA系统，夜间非工作期间可以停服；有些业务系统，为了更好的客户
切换方案不同，对应的Runbook的操作步骤也不同。切换方案可以分停服切换和不停服切换。不停服切换方案对应用架构的要求比较高，通常需要对应用架构进行大规模改造，所以业界普遍采用的切换方案是停服切换。下面以停服切换为例，介绍Runbook设计的注意事项。 设计正向操作步骤 依据切
停写不停读切换方案 停写不停读，主要指切换期间，为了追求较好的用户体验，保持一部分读的服务不停服，保持在线可使用状态；为了保持数据一致性，写的服务仍然采用停服方式进行切换。从业务对外体验上，多数用户感知不到停服的影响，比如某购物平台，用户仍然可以浏览商品，但是不能下单，下单时可友好的提示：系
多个分项确认人在线刷新确认进展）。 引导人通常是1~2个，是整个切换的总指挥（对于大规模切换，参与人员多，操作时间长的场景，也可以设计2~3名引导人，互为备份），引导人需要对整个Runbook非常熟悉，尤其对于每个步骤执行时序，多个步骤的并行情况要熟悉。 父主题： 设计Runbook
务迁移方案的设计。 设计数据迁移方案 大数据的数据迁移涉及到3类数据，如下表： 表1 大数据迁移的三类数据 分类 说明 元数据 Hive元数据或外置元数据 存量数据 历史数据，短期内不会变化 增量数据 数据定期更新 这3类数据的迁移方法如下： 表2 大数据三类数据的迁移方式 数据分类
切换相关人员通知和核对 企业项目经理 确认切换参与人员是否可以出席 是 否 企业项目经理 第三方配合切换当晚参与人员和联系方式确定 是 是 企业项目经理 停服切换期间，运营中心值班人员就位 是 是 企业内部发送内部通知 企业项目经理 切换通知群名：XX项目切换群 是 是 云厂家建立后端保障团队 云厂家项目经理
开发 5 测试 3 生产 1 业务重要性 一般 5 重要 3 核心 1 关联性 简单 5 复杂 3 非常复杂 1 基础架构复杂度 简单（实例数1~3） 5 复杂（实例数4~10） 3 很复杂（实例数11~） 1 允许停服时长 120分钟以上 5 60~120分钟 3 <60分钟 1
切换 大数据的切换主要是指大数据应用的切换，其切换演练和正式切换的步骤请参考章节切换。本节重点介绍大数据应用切换的3个切换点，以便更好的指导大数据应用的切换。 双跑场景：大数据应用分别在源环境和目标环境各部署一套，实现双跑，切换点在域名，业务切换时只需要进行域名的切换，将业务流量切换到新应用。
