- 综合排序
- 最热优先
- 最新优先
- 来自专栏云上计算
CDH迁移 | CDHHDP迁移之路
很多客户认为CDP是CDH/HDP的高版本，应可以平滑升级，基于开源整合的产品，也可以平滑升级，而TDH是国内自主研发的大数据产品，兼容性不好，升级成本高，其实不然。 星环科技TDH 1）TDH基础存储和计算组件兼容CDH/HDP，迁移成本低； 2）TDH提供迁移工具，数据一键迁移； 3）大量迁移成功案例，不存在迁移风险。 在各个行业的国产替代进程中，该项技术可以允许用户在原有大数据集群（一般采用X86架构）内逐步增加或更换为国产硬件服务器和国产操作系统，可以让用户平滑地迁移到国产化环境中并保证业务不受影响，同时降低了国产化成本 企业业务迁移成本高 •支持的存储过程编译技术主要是HPL兼容的语法比较有限•支持SQL 2003标准与存储过程，降低开发难度；兼容Teradata，Oracle，DB2等方言，方便业务平滑迁移，降低迁移成本 迁移全程用时6个月不到，充分体现了TDH对CDH的兼容性，以及Oracle方言和存储过程支持能力。
3.2K30编辑于 2022-04-04 - 来自专栏云上计算
CDH迁移 | 教你三步实现CDH迁移到星环TDH
TDH的存储与计算组件兼容CDH/HDP，可以实现平滑迁移，大大降低企业迁移成本低。专业的迁移工具实现数据一键迁移，高效便捷。 此外，星环科技已经有大量的迁移成功案例，经验丰富，保障整个迁移过程安全可靠。 本文将基于某金融机构的数据仓库批处理场景来手把手带领大家“三步”完成 CDH到星环TDH的平滑迁移。 在安装好TDH及服务之后，我们需要安装星环大数据平台数据备份恢复软件Transwarp Backup (TBAK），之后我们就可以在TBAK的可视化界面通过简单的“三步”来实现CDH到星环TDH的平滑迁移 三步实现CDH到星环TDH的平滑迁移 Step1配置CDH和TDH集群 该步骤主要是用来配置CDH和TDH集群，为后续数据迁移做准备。 API查询方式 星环TDH对原来基于CDH开发的应用兼容性高，原先业务可以平滑迁移到TDH。
1.5K10编辑于 2022-04-01 - 来自专栏Hadoop实操
如何迁移CDH的opt目录
安装的安装目录默认是在/opt下，随着版本的升级和新组件的安装占用了大量的/opt目录空间，为了确保opt目录有足够的空间来存放CDH的安装包，需要将CDH的安装目录进行迁移，本篇文章Fayson主要介绍如何迁移 2.CDH安装目录迁移 ---- 这里的迁移Fayson使用软链接的方式将CDH的安装目录/opt/cloudera迁移至/data/disk1目录下，具体操作如下： 1.首先将/opt/cloudera 目录mv到需要迁移的目录下 [root@cdh01 disk1]# cd /opt/ [root@cdh01 opt]# mv cloudera/ /data/disk1/ （可左右滑动） ? 3.迁移完成后，需要重启cloudera-scm-agent服务 [root@cdh01 opt]# systemctl restart cloudera-scm-agent （可左右滑动） 4.检查迁移完成后集群是否正常 如上操作就完成了CDH安装目录的迁移。 3.总结 ---- 1.在CDH安装目录迁移完成后需要重启cloudera-scm-agent服务 2.使用软链接的方式可以在不修改配置的情况下完成，更方便。
2K40发布于 2018-08-17 - 来自专栏Kirito的技术分享
平滑迁移 Dubbo 服务的思考
本文便以这个事为一个引子，介绍如何平滑地迁移 Dubbo 服务，达到替换注册中心的效果。 平滑迁移过程 说到注册中心迁移，可能很多人第一时间都能想到双注册双订阅这种方案 双注册和双订阅迁移方案是指在应用迁移时同时接入两个注册中心（原有注册中心和新注册中心）以保证已迁移的应用和未迁移的应用之间的相互调用 ，至此平滑迁移完成。 Dubbo 支持多注册中心的配置，这就为我们平滑迁移提供了很多的便利性。 这样的缺陷，会导致我们在平滑迁移过程中无法对未迁移应用和迁移中应用进行充分的测试。
1.8K30发布于 2020-06-03 - 来自专栏CSDN搜“看，未来”
【MySQL】数据平滑迁移方案思考
文章目录 数据迁移方案 两个方案的bug 数据校验工具 数据迁移方案 这个想一下redis是怎么把数据做持久化的，思路就有了：快照 + 追加日志。 注意点： 1、在完成数据迁移之前，上游业务依然是访问旧数据库的。 2、研发一个数据迁移工具，进行离线数据迁移。 3、不断刷新“追加日志” 4、写一个数据校验脚本。 5、在架构的时候就应该考虑到有一天要迁移，所以这时候就可以平滑迁移了。比方说：使用虚ip的方式。 还有一种方案，是用 双写 的方式。好像在哪里见过，不知道是不是redis恢复数据的时候。 数据完成迁移之前，上游应用业务依旧通过旧的服务访问数据。 注意点： 1、对旧库的修改，在新库上进行相同的修改操作，称之为双写。
2K30编辑于 2022-05-06 - 来自专栏一枝花算不算浪漫的专栏
线上数据平滑迁移思考及拙见
服务重构，老版系统为php代码，新版系统改为Java。 数据层面沿用之前老版服务的数据库结构，部分库字段进行修改。
85720发布于 2019-02-20 - 来自专栏python3
mongodb3 分片集群平滑迁移
分片集群平滑迁移实验(成功) 过程概述： 为每个分片添加多个从节点，然后自动同步。同步完后，切换主节点到新服务器节点。 老服务器的三分片数据 迁移到 新服务器的三片集群 老分片环境： 192.168.168.56 22001 22002 22003 192.168.168.57 22001 22002 22003 192.168.168.58 mongod 和 mongos ####在新服务器启动服务# 启动整个集群，包括：config mongod 和mongos进程 如果启动mongos进程没有报错，则说明mongodb分片集群平滑迁移成功
2.3K10发布于 2020-01-08 - 来自专栏vivo互联网技术
从RabbitMQ平滑迁移到RocketMQ技术实战
本文将介绍基于RocketMQ建设消息中间件平台并实现在线业务无感知的平滑迁移。一、背景说明vivo互联网中间件团队于2016年开始基于开源RabbitMQ向业务提供高可用消息中间件平台服务。 queue由某个节点承载流量后无法快速迁移，强制迁移到其它低负载节点可能会导致queue不可用，这也导致了向集群中添加节点并无法快速提升集群的流量承载能力。 总结：需要建设高性能、高可靠的下一代消息中间件，具备极高的数据可靠性，丰富的功能特性，并且需要完美兼容当前的RabbitMQ平台，帮助业务快速迁移到新消息中间件平台，减少业务迁移成本。 四、平滑迁移建设通过技术调研，确定了基于RocketMQ建设下一代消息中间件平台。 为了实现业务从RabbitMQ平滑迁移到RocketMQ，就需要建设消息网关实现消息从AMQP协议转换到RocketMQ；RabbitMQ与RocketMQ的元数据语义与存储存在差异，需要实现元数据语义的映射与元数据的独立存储
1.9K21编辑于 2022-08-01 - 来自专栏架构师之路
100亿数据平滑数据迁移,不影响服务
种种需求，都需要进行数据迁移，如何平滑迁移数据，迁移过程不停机，保证系统持续服务，是文本将要讨论的问题。 二、停机方案 在讨论平滑迁移数据方案之前，先看下不平滑的停机数据迁移方案，主要分三个步骤。 无论如何，停机方案并不是今天要讨论的重点，接下来看一下常见的平滑数据迁移方案。 三、平滑迁移-追日志法 平滑迁移方案一，追日志法，这个方案主要分为五个步骤。 四、平滑迁移-双写法 平滑迁移方案二，双写法，这个方案主要分为四个步骤。 数据迁移前，上游业务应用通过旧的服务访问旧的数据。 （5）流量切到新库，完成平滑迁移 双写法，四个步骤： （1）服务进行升级，记录“对旧库上的数据修改”进行新库的双写 （2）研发一个数据迁移小工具，进行数据迁移 （3）研发一个数据比对小工具，校验数据一致性 （4）流量切到新库，完成平滑迁移
3.2K60发布于 2018-03-01 - 来自专栏云数据库技术
从 OracleMySQL 平滑迁移到 PostgreSQL，总共分几步？
这是迁移过程中最耗时的环节，也是 NineData 迁移评估的核心价值场景。传统方式需要手动查阅语法差异、编写兼容代码，效率低、易出错。 第五步：收尾 —— 沉淀成果，让迁移可追溯、可审计迁移完成后，需将全过程成果归档，满足团队协作、方案评审、合规审计需求。 总结：平滑迁移 PostgreSQL，就这五步从 Oracle/MySQL 迁移到 PostgreSQL，是一套标准化、可落地的工程化流程：步骤核心工作关键产出工具支持第一步：摸底自动扫描对象与 SQL ，识别不兼容风险不兼容清单NineData 迁移评估第二步：量化自动计算风险等级、兼容性评分迁移评估报告NineData 迁移评估第三步：改造依据自动生成的兼容 SQL 完成代码修改改造后的应用代码NineData 迁移评估第四步：验证SQL 流量回放，真实验证兼容性流量回放报告NineData 迁移评估第五步：收尾报告下载归档，沉淀迁移成果可审计的迁移档案NineData 报告下载这套流程走下来，异构数据库迁移不再是
23310编辑于 2026-03-05 腾讯云金融大数据方案：基于全栈信创架构实现CDH平滑迁移与批处理性能提升71%
与此同时，大量金融机构历史遗留的原CDH组件版本过低，跨版本迁移存在显著的数据丢失与系统宕机风险。 客户核心痛点在于：如何在大批量离线计算与实时计算需求并存的场景下，在绝对保证业务系统连续性的前提下完成底层数据平台的平滑迁移，弥合遗留架构计算能力不足与业务高速增长之间的差距。 零风险平滑迁移保障： 针对CDH迁移风险，制定包含完整迁移预案与充分演练的实施路径。通过引入自动化校验机制，实现新旧平台数据的自动核验与比对，确保业务连续性与数据零误差。 提升批处理效率与扩展集群计算能力 通过引入TBDS大数据集群，系统在计算资源扩展与作业执行效率上实现了精确量化的业务价值提升（数据来源：腾讯云典型案例实际运行指标）： 集群计算资源显著扩容： 在本地部署模式下，新建集群节点数较原CDH 项目成功部署了包含30个数据节点的TBDS大数据集群，彻底替代了老旧的低版本CDH架构。
10010编辑于 2026-05-31Oracle 到 PostgreSQL 迁移，2026 年实现平滑切换
这两年聊 Oracle 迁移项目，一个比较明显的变化是：大家关注的重点已经不再是“能不能把数据迁过去”，而是“能不能在业务中断窗口较小、风险可控的前提下平滑切换”。 “能迁”解决的是数据搬运问题，比如导出、导入、全量迁移、对象转换；“平滑切换”解决的是生产工程问题，比如业务连续性、增量追平、数据校验、切换窗口、失败回滚、任务告警。 这个时候如果没有提前准备好回流和回切方案，所谓“平滑切换”就会面临更高风险。 这也比较符合真实生产环境里的迁移逻辑。成熟的切换方案，不是“目标库准备好了就切”，而是“目标库准备好、数据已经追平、验证结果清楚、异常时还能退回”。只有这四件事同时成立，迁移项目才更接近平滑切换。 总结2026 年做 Oracle 到 PostgreSQL 迁移，更明显的分水岭已经不是“能不能迁”，而是“能不能在低业务中断、低风险的前提下平滑切换”。
22110编辑于 2026-03-31- 来自专栏杨建荣的学习笔记
MySQL中间件集群平滑迁移的初步方案
最近有一套MySQL集群环境的服务器即将过保，为了避免后续带来的一些额外问题，需要提前考虑服务器的迁移计划，但是现在的线上业务，申请维护时间是比较困难的，而且在线变更的容忍时间是很短暂的，一般在业务层也有容错机制 整个集群的迁移计划是按照1:1的模式进行服务器对等替换，也就意味着原来有30个服务器，要对等30个服务器来进行平移，按照之前的实践来看，整体的迁移时间基本控制字5秒以内。 在迁移中，因为从库默认是不接入业务的，所以相应的从库的替换可以平滑实现，即用新的服务器顶上去成为新的从库，如果可以保证IP不变，整体的拓扑结构是没有任何变化的。 在迁移前，需要对已有的中间件进行缩容，先能够逐步减少为1个中间件节点，这个过程可以使用备用连接池技术实现，也可以主动触发应用重连机制实现。
1.2K30发布于 2021-03-16 - 来自专栏CodeGuide | 程序员编码指南
DDD + SpringCloud 第2篇：Stream 让 MQ 平滑迁移
那如果我们想让服务可以平滑的从一套组件切换到另外一套，应该如何处理呢？ 这样的东西我也做过 在我工作的公司，近10年的发展中，Redis 的缓存服务组件陆续的变换了3、4款，目前有2套最终稳定共用的。 那么我为此开发了一款缓存中间件，可以做到动态切换、读写控制、监控管理，可以非常方便的迁移和升级。 那么，在我们使用 MQ 的时候，如果在不改变系统工程代码的情况下，该怎样优雅的从一套MQ迁移到另外一套呢？今天小傅哥就带着大家来办这样一个事。
56710编辑于 2025-08-11 - 来自专栏码农那些事！！！
微服务平滑迁移注册中心 Eureka 到 Nacos
实战项目》 视频教程已经录完了，涉及到Alibaba的各种中间件实战，戳这里--->Spring Cloud Alibaba 实战 视频专栏 开放订阅~ 本篇文章介绍一下如何将注册中心从 Eureka 迁移到 Nacos ，这里面涉及到这个 双注册双订阅模式 除此之外还有一种更加优雅的方式，下篇文章介绍 首先，为啥要迁移呢？ 所以当我们在迁移的过程中，如果发现 Nacso 上新的 provider 有什么异常时，可以将其下线先 轻轻一点真的太方便了 优雅下线 结束上面的小实验，回到正常流程中，我们要来下线这个 provider 这样就完成了这个注册中心的迁移了 整体流程 这里其实就是上线新版本后，等其稳定，下线旧版本的一个规则。 总结 通过本案例，可以快速了解到这个迁移过程中： 这个代码基本都没改！
1.1K20编辑于 2023-05-01 腾讯云TBDS：实现大数据平台自主创新与CDH平滑替换
企业面临CDH/HDP停止更新、开源社区版组件松散、安全风险高、国产软硬件适配困难等核心挑战。国资委79号令明确要求，到2027年央企需100%完成信息化系统安可替代。
13000编辑于 2026-05-30- 来自专栏Hadoop实操
0671-6.2.0-如何将CDH5.12的Hive元数据迁移到CDH6.2
作者：余枫 1 文档编写目的 这里我们假定一个场景，你需要迁移CDH5.12到CDH6.2，CDH5.12和CDH6.2分别是两个不同的集群，我们的工作主要是HDFS数据和各种元数据从CDH5.12迁移到 CDH6.2，本文不讨论HDFS数据的迁移也不讨论其他元数据的迁移比如CM或Sentry，而只关注Hive元数据的迁移。 测试环境 1.Redhat7.4 2.CDH6.2.0 3.MySQL的管理员账号 2 迁移准备 1.准备两个集群，一个是CDH5.12.0，一个是CDH6.2.0。 ? 4.导出CDH5.12.0集群的Hive的元数据 ? 3 迁移步骤 1.将上一步中的元数据导入到CDH6.2.0的MySQL中 ? 3.在将Hive元数据成功迁移到CDH6.2以后，我们知道Hive元数据中保存的表的比如location信息其实对应的还是CDH5.12中的HDFS路径，这样会导致你虽然迁移成功了Hive元数据，但是在
1.9K30发布于 2019-07-17 - 来自专栏特特的专栏
单库单表到分库分表的平滑迁移
架构升级历程参考：数据库架构演变过程这里我们直接一步到位，实现单库单表到垂直拆库，水平分表迁移过程场景汇总新老数据读写老数据是是老数据是是迁移步鄹实现新数据的读和写的能力实现老数据到新数据的同步（监听binlog 实现新数据到老数据的同步（监听binlog的方式）开始灰度新数据的读 新数据读全量后，关闭老数据的读开始灰度新数据的写新数据写全量后，关闭老数据的写线上稳定运行一段时间后，关闭新老数据同步归档老数据，下线老数据迁移前迁移中迁移后总结自此就完成了数据库架构的升级 ，在整个迁移过程中，秉承着对业务影响最小的策略理念执行，最终实现数据和功能平滑迁移到新的数据库架构。
69421编辑于 2024-08-22 - 来自专栏创作是最好的自我投资
OpenTenBase应用落地实践：从MySQL到OpenTenBase的平滑迁移
为了验证并实现将现有基于MySQL的应用平滑、安全、高效地迁移至OpenTenBase分布式集群，并在迁移后确保所有核心业务的正常运行，最终达成提升系统整体性能、可扩展性及可靠性的战略目标。
80930编辑于 2025-09-13 - 来自专栏小泽的专栏
从阿里云解析到 DNSPod，如何实现 DNS 平滑迁移？
操作步骤解析记录迁移导出解析记录登录阿里云 DNS 控制台，选择并点击需要设置的域名。图片进入后单击导入/导出，并选择导出记录。图片图片导出文件类型选择zone，并单击立即导出。 图片导出完成后重命名文件，添加.zone后缀，如下两图所示：图片图片导入解析记录登录腾讯云解析 DNSPod 控制台，单击添加域名：图片添加需要迁移的域名，以dnstest.icu为例：图片添加完成后前往批量操作 -导入记录页面，输入需要迁移的域名，上传刚刚在阿里云导出的zone区域文件，并单击批量导入：图片文件后缀名为.zone，否则将无法正常识别。 生效期间内请不要在阿里云删除域名解析，建议至少等待72小时后再在阿里云平台删除 DNS 解析记录技术支持如在迁移过程中遇到任何问题，请加入DNSPod 官方用户群联系我们协助迁移：https://cloud.tencent.com
2.8K10编辑于 2024-05-21
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号