Sqlserver

该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D 我们用了两章文章 从 SQL Server 到 MySQL（一）：异构数据库迁移 / 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 介绍我们遇到问题和解决方案。 不管是离线全量迁移还是在线无缝迁移， 核心 ETL 工具就是 yugong。 Yugong 是一个成熟工具， 在阿里巴巴去 IOE 行动中起了重要作用， 它与 Otter / Canal 都是阿里中间件团队出品。 它们三者各有分工： Yugong 设计目标是异构数据库迁移； Canal 设计用来解决 MySQL binlog 订阅和消费问题； Otter 则是在 Canal 之上，以准实时标准解决数据库同步问题。 Otter 配备了相对 yugong 更健壮管理工具、分布式协调工具， 从而长期稳定运行。Yugong 设计目标则是一次性迁移工作，偏 Job 类型。 当然 yugong 本身质量不错，长期运行也没问题。 我们有个产线小伙伴使用我们魔改后 yugong， 用来将数据从管理平台同步数据到用户前台，已经稳定跑了半年多了。 ...

该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D （image via https://pixabay.com/en/military-stealth-bomber-refueling-602729/ ） 在上篇文章 从 SQL Server 到 MySQL （一）：异构数据库迁移 - Log4D 中，我们给大家介绍了从 SQL Server 到 MySQL 异构数据库迁移的基本问题和全量解决方案。 全量方案可以满足一部分场景的需求，但是这个方案仍然是有缺陷的： 迁移过程中需要停机，停机的时长和数据量相关。 对于核心业务来说，停机就意味着损失。 比如用户中心的服务，以它的数据量来使用全量方案，会导致迁移过程中停机若干个小时。 而一旦用户中心停止服务，几乎所有依赖于这个中央服务的系统都会停摆。 ...

该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D 背景 沪江成立于 2001 年，作为较早期的教育学习网站， 当时技术选型范围并不大： Java 的版本是 1.2，C# 尚未诞生，MySQL 还没有被 Sun 收购， 版本号是 3.23。 工程师们选择了当时最合适的微软体系，并在日后的岁月里， 逐步从 ASP 过度到 .net，数据库也跟随 SQL Server 进行版本升级。 ...