云环境下数据库迁移之路

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 云环境下数据库迁移之路 中国移动信息技术中心 演讲人:韩宇峰
2. 目录 1 迁移面临的挑战 2 迁移过程的实践 3 未来的计划和展望
3. 为什么要迁移? 中国移动信息技术中心近年来不断在云化建设、应用上云、服务上云等 方面努力。目标之一就是推动数据库的转型,将传统的关系型数据库逐步迁 移到云环境上,从而适应业务和技术的飞速发展。 Ø 数据应用模式不断丰富 Ø 数据体量急剧增长 Ø 业务种类增多,规模扩大 Ø 灵活扩展,快速伸缩 Ø 托管运维,专人专职 Ø 稳定可靠,健壮易用
4. 数据库的现状如何? 了解我们的现状,有助于制定目标和计划,确保数据库平稳迁移上云。 选型多样化 ü 国外收费、国内收费、开源免费 ü OLTP、OLAP、HTAP ü 主备式、集中式 部署复杂 ü 主机类型繁多,操作系统版本多 ü 部署的数量多,节点数量评估比较随意 业务耦合深 ü 业务的复杂逻辑依靠数据库完成 ü 数据模型庞大,缺少适度的拆分 标准不一致 ü 同一数据库产品,版本不一致 ü 工具不统一,采集信息不统一 ü 参数调优不同,系统优化不同
5. 有什么困难? 困难和期望并存,如何解决问题? 功能 性能 生态 工具 可靠 兼容 扩展 故障 方法 过程和方案 总结 目标和输出 缺少
6. 目录 1 迁移面临的挑战 2 迁移过程的实践 3 未来的计划和展望
7. 迁移过程中的目标? “以终为始”,先确定目标再围绕着目标开始数据库的云环境迁移过程。 l 代码改造不可避免, 要保证业务的一致性 业务 稳定 平滑 过渡 l 迁移过程要尽量降 低对用户的影响 l 针对现网环境的问 题要有应对措施 稳定 可靠 有路 可退 l 万一出现不可恢复的 灾难,要有备份通路
8. 我们计划怎么做? 云 环 境 下 数 据 库 迁 移 业务稳定 选择适当的业务场景 评估数据库产品是否满足技术需求 进行功能改造及回归测试 进行性能测试和参数测试 平滑过度 通过生产数据验证数据处理的一致性 通过生产数据验证处理性能满足需求 采用灰度分流机制进行少量实际业务验证 使用挡板+模拟器屏蔽对外部系统影响 稳定可靠 注入异常测试风险预警能力 设计故障点测试抗破坏能力 制造人为故障测试恢复能力 测试系统的扩展能力 有路可退 制定应急切换方案 进行应急切换演练
9. 选择合适的场景(一) 我们面临的业务场景非常庞杂,在云化迁移时对数据库的需求也各不相同, 为了更好地做出选择,我们对常见的业务场景做了梳理,选择风险相对可控, 借鉴意义较高的场景开展工作。 业务场景 用户感知度 数据体量 SQL复杂程度 是否具备并行条件 版本迭代速度 评分 充值支付 明显(1分) 大(3分) 正常(2分) 部分具备(2分) 正常(2分) 10分 查询办理 明显(1分) 大(3分) 复杂(1分) 完全具备(3分) 正常(2分) 10分 短信上下行 一般(2分) 中(2分) 正常(2分) 部分具备(2分) 慢(3分) 11分 卡套包销售 明显(1分) 中(2分) 复杂(1分) 部分具备(2分) 快(1分) 7分 权益营销 一般(2分) 大(3分) 正常(2分) 部分具备(2分) 快(1分) 10分 运营报表 无感知(3分) 中(2分) 复杂(1分) 不具备(1分) 正常(2分) 9分
10. 选择合适的场景(二) 有了场景的初步筛选还不够,我们还需要从以下方面做进一步的评估,以确 保后续工作的开展。 部署方案 ü 对异地多活、异构 部署等特性的需求。 ü 现网数据库的使用 情况,CPU、内存、 存储、连接数等。 ü 并行机制和模拟外 围系统的能力。 测试方案 ü 现网数据库的容量、 表结构、业务峰值 等。 ü 数据库的高级特性 使用情况。 ü 是否可以模拟接口 响应。 风险性 ü 周边系统的耦 合程度。 ü 服务的设计是 否支持分流。 ü 用户感知度&可 停服时长。
11. 数据迁移 优先选择进行数据迁移,一方面是为后续的基础功能测试提供真实的数据结 构和数据体量,另一方面是为了尽早发现兼容性问题为后续功能改造提供依 据,让后续的基准测试和功能改造可以并行。 源数据库分析 Ø 兼容性 Ø 一致性 Ø 实效性 Ø 增量同步 结果归档 兼容适配 Ø 全量同步 结果检查 兼容性检查及建议 迁移方案 迁移实施
12. 基准测试 基于业务场景对数据库的需求,结合导入的业务数据,对数据库进行基准测 试,确保基础功能能够满足业务场景的要求。 基础功能 可维护性 • • • • • • • • • • • • • • • 兼容分析 语法兼容 对象兼容 驱动兼容 字符兼容 中间件兼容 软硬件兼容 事务能力 性能测试 迁移工具 同步工具 可视化管理 监控告警 SQL分析 备份恢复 • • • • • • 可靠性 扩展能力 高可用切换 RPO和RTO 自动检测 异常隔离 服务恢复 异地容灾 • • • • 计算均衡 数据均衡 水平扩缩容 多中心部署 安全性 • • • • • • 身份认证 权限管理 操作审计 黑白名单 漏洞修复 入侵检测
13. 功能测试 功能测试包括以下的改造要点,核心原则是:数据层大改动,接口层适当动, 核心逻辑尽量不动。 应用侧改造 数据库改造 Ø Ø Ø Ø Ø 语法 对象 驱动 兼容性 工具集 Ø Ø Ø Ø Ø Ø 驱动程序 SQL语句 数据对象 API接口 工具脚本 模拟器 测试重点 Ø 功能正确性 Ø 数据一致性 Ø 异常处理能力 应用侧改造驱动数据库侧完善产品功能,测试反馈应用改造的问题完善业务场景。
14. 性能测试(一) 我们把性能测试分为基础测试、进阶测试和最终结论3个部分。 基础 • 接口性能 • 数据库性能 • 模拟器性能 进阶 结论 • 复杂SQL效率 • 数据量引发的 性能衰减 • 疲劳测试 • 性能指标 • 性能对比
15. 性能测试(二) 性能测试中发现问题后我们从以下方面进行性能调优。 代码层面 1. SQL语句 2. 库表结构 3. 分库分表 数据库层面 1. 索引设置 2. 数据库参数 运维层面 1. 2. 3. 4. 主机参数 容器参数 中间件参数 部署架构
16. 并行测试 我们需要在不影响生产业务的情况下,将全量业务数据的操作反馈到目标 数据库上,验证数据处理的一致性。 写入队列 SQL抽取 1 2 3 消费入库 4 结果检查
17. 扩展测试 业务的快速发展带来了数据量的飞速增长,数据的价值被不断的挖掘,业务 的复杂度也越来越高。因此我们对数据库的扩展性也有越来越高的要求。一 方面需要扩展存储能力,另一方面需要扩展计算能力。 扩展前 发现问题 ü 通过导入海量数据模拟 大规模数据增长 ü 通过并行复杂业务SQL 模拟计算需求增长 扩展中 关注影响 ü ü ü ü 关注扩展操作的执行时间 关注扩展期间的业务连续性 关注扩展期间的报错信息 关注扩展期间数据库的整体 运行情况 扩展后 检查结果 ü 检查扩展后的数据一致性 ü 检查扩展后各个节点的数 据均衡性 ü 检查存储能力、计算能力 是否满足要求
18. 破坏测试 为了验证数据库云化迁移后的抗风险能力,我们结合实际生产出现的问题设 计了一些破坏性的测试案例。 删库、删文件、删系统 拔网线、down掉网卡 单台主机宕机、多台主机宕机 CPU、内存、磁盘使用率飙高 关注点: 1. 是否可以及时发 现问题 2. 出现问题期间对 业务的影响 3. 出现问题后多久 可以恢复 4. 恢复期间业务是 否丢失
19. 镜像分流 通过镜像分流测试进一步综合验证改造后系统的功能、性能和稳定性。 流量镜像 外围模拟 性能满足 功能正确 1. 业务是否正确处理 2. 数据一致性是否满足 3. 应用日志是否有报错 稳定性 1. 日常业务量性能是否满足要求 2. 观察数据库的顶级SQL执行时 长是否有波动 3. 导入更多数据模拟数据积累后 观察性能
20. 灰度分流 正式上线之前我们还要进行灰度分流验证,确保新版本出现问题时的影响范围 可以控制到最小,这个步骤我们总结了2条基本原则和4种分流方式。 放量配置 用户一致 按功能分流 ü 逐个功能进行迁移验证,适合 功能比较多的系统 ü 出现问题时单个功能受影响 ü 可能涉及数据同步工作 按渠道分流 ü 适用于不涉及普通用户的系统, 比如网关类系统 ü 出现问题时影响某一个渠道 按用户分流 ü 基于手机号码或者省份编码进行 分流,适合面向普通用户的系统 ü 出现问题时只影响部分用户 按流量分流 ü 基于业务量进行分流,有利 于控制新版本的负载压力 ü 对数据的同步要求比较高
21. 主备倒换 数据库的云化迁移过程是一个涉及代码、架构、数据多方面的复杂技术方案。 不可能保证100%的无故障,所以我们需要plan B。 1. 数据同步机制 2. 数据一致性稽核 3. 版本迭代处理 4. 数据补偿方案 5. 回切方案及演练
22. 十一步法 场景选择 数据迁移 基准测试 功能测试 性能测试 测试环境五步,验证数据库兼容性、业务满足度 并行测试 扩展测试 破坏测试 镜像分流 灰度分流 生产环境六步,验证真实生产下稳定性和可靠性 主备倒换
23. 各个阶段总结(一) 阶段 主要工作 重点考虑 输出交付 场景选择 根据现有数据库使用情况, 选择合适的业务场景。 用户感知度、数据体量、SQL 复杂度、并行条件、版本迭代。 1. 业务场景评估报告 2. 时间进度计划 3. 各阶段部署方案 数据迁移 进行数据迁移,如果有不 适配的数据类型、sql语句、 函数等需要进行改造。 兼容性、一致性、实效性、 同步工具。 1. 数据迁移方案及报告 2. 系统改造方案 基准测试 结合导入的业务数据,对数 据库进行基准测试。 基础功能、可维护性、可靠 性、扩展能力、安全性。 1. 基本功能测试方案、 报告以及结论 功能测试 业务侧和数据库侧配合进行改 造,并进行功能验证测试。 驱动、语法、对象、接口、 脚本等。 1. 系统改造方案 2. 功能测试报告 3. 问题列表及解决方案 性能测试 进行完整的性能测试 代码、数据、运维,3方面 进行调优。 1. 性能测试报告 2. 问题列表及解决方案
24. 各个阶段总结(二) 阶段 主要工作 重点考虑 输出交付 并行测试 现有系统并行,以真实数据 验证数据库处理能力。 SQL抽取、异步处理、 有序消费、数据验证。 1.并行测试场景的验证方案 2.测试报告及结论 扩展测试 针对数据库的存储和计算的 扩展能力进行测试。 扩展方案、扩展期间影响范 围、扩展后数据一致且均衡。 1.扩展测试方案及结论 2.改进建议及应对措施 破坏测试 结合实际生产出现的问题, 验证数据库抗风险能力。 发现问题、解决速度、 业务影响、数据一致。 1.破坏测试方案及结论 2.改进建议及应对措施 镜像分流 镜像生产流量,综合验证改造 后系统的功能、性能和稳定性。 功能正确、性能满足 长时间稳定运行。 1.镜像分流测试方案及结论 2.问题列表及解决方案 灰度测试 按一定规则进行分流,新数据 库承载一部分生产数据。 放量配置、用户一致 1.灰度测试方案及结论 2.问题列表及解决方案 主备倒换 生产业务全量割接, 旧系统作为备份通路。 数据同步、一致性、数据补 偿、回切方案、版本迭代。 1.应急切换方案 2.数据同步及稽核方案 3.上线运行报告
25. 目录 1 迁移面临的挑战 2 迁移过程的实践 3 未来的计划和展望
26. 未来计划 围绕更多、更复杂的业务场景开展数据库云化迁移,逐步完善我们积累的方 法论的同时,也不断打磨数据库产品。 打磨产品 业务 场景 云化迁移 完善方法
27. 展望将来 • 提升健壮性和稳定性, 抗冲击能力更强。 1 2 • 更适合混合场景的数据库 4 • 适配国产化主机、操作系 • 更完善的容灾、多活方案 • 工具化、可视化 • 生态完善、社区活跃 3 • 能够主动发现问题并预警 统,提升自主可控程度
28.

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-24 23:01
浙ICP备14020137号-1 $访客地图$