从 SQL Server 到 MySQL （一）：异构数据库迁移

时间 2019-11-17

原文原文链接

背景

沪江成立于 2001 年，做为较早期的教育学习网站，当时技术选型范围并不大： Java 的版本是 1.2，C# 还没有诞生，MySQL 尚未被 Sun 收购，版本号是 3.23。工程师们选择了当时最合适的微软体系，并在往后的岁月里，逐步从 ASP 过分到 .net，数据库也跟随 SQL Server 进行版本升级。html

十几年过去了，技术社区已经发生了天翻地覆的变化。沪江的技术栈还基本在 .net 体系上，这给业务持续发展带来了一些限制。人才招聘、社区生态、架构优化、成本风险方面都面临挑战。集团通过慎重考虑，发起了大规模的去 Windows 化项目。这其中包含两个重点子项目：开发语言从 C# 迁移到 Java，数据库从 SQL Server 迁移到 MySQL。mysql

本系列文章就是向你们介绍，从 SQL Server 迁移到 MySQL 所面临的问题和咱们的解决方案。git

迁移方案的基本流程

设计迁移方案须要考量如下几个指标：github

迁移先后的数据一致性
业务停机时间
迁移项目是否对业务代码有侵入
须要提供额外的功能：表结构重构、字段调整

通过仔细调研，在平衡复杂性和业务方需求后，迁移方案设计为两种：停机数据迁移和在线数据迁移。若是业务场景容许数小时的停机，那么使用停机迁移方案，复杂度低，数据损失风险低。若是业务场景不容许长时间停机，或者迁移数据量过大，没法在几个小时内迁移完成，那么就须要使用在线迁移方案了。web

数据库停机迁移的流程：sql

201803/migration-db-offline-readonly.png

停机迁移逻辑比较简单，使用 ETL（Extract Translate Load）工具从 Source 写入 Target，而后进行一致性校验，最后确认应用运行 OK，将 Source 表名改掉进行备份。数据库

在线迁移的流程：微信

在线迁移的方案稍微复杂一些，流程上有准备全量数据，而后实时同步增量数据，在数据同步跟上（延迟秒级别）以后，进行短暂停机（Hang 住，确保没有流量），就可使用新的应用配置，并使用新的数据库。数据结构

须要解决的问题

从 SQL Server 迁移到 MySQL，核心是完成异构数据库的迁移。架构

基于两种数据迁移方案，咱们须要解决如下问题：

两个数据库的数据结构是否能够一一对应？出现不一致如何处理？
MySQL 的使用方式和 SQL Server 使用方式是否一致？有哪些地方须要注意？
如何确保迁移先后的数据一致性？
在迁移中，如何支持数据结构调整？
如何保证业务不停状况下面，实如今线迁移？
数据迁移后若是发现业务异常须要回滚，如何处理新产生的数据？

为了解决以上的问题，咱们须要引入一整套解决方案，包含如下部分：

指导文档 A：SQL Server 转换 MySQL 的数据类型对应表
指导文档 B：MySQL 的使用方式以及注意点
支持表结构变动，从 SQL Server 到 MySQL 的 ETL 工具
支持 SQL Server 到 MySQL 的在线 ETL 工具
一致性校验工具
一个回滚工具

让咱们一一来解决这些问题。

SQL Server 到 MySQL 指导文档

很是幸运的是，MySQL 官方早就准备了一份如何其余数据库迁移到 MySQL 的白皮书。 MySQL :: Guide to Migrating from Microsoft SQL Server to MySQL 里提供了详尽的 SQL Server 到 MySQL 的对应方案。包含了：

SQL Server to MySQL - Datatypes 数据类型对应表
SQL Server to MySQL - Predicates 逻辑算子对应表
SQL Server to MySQL – Operators and Date Functions 函数对应表
T-SQL Conversion Suggestions 存储过程转换建议

须要额外处理的数据类型：

SQL Server	MySQL
IDENTITY	AUTO_INCREMENT
NTEXT, NATIONAL TEXT	TEXT CHARACTER SET UTF8
SMALLDATETIME	DATETIME
MONEY	DECIMAL(19,4)
SMALL MONEY	DECIMAL(10,4)
UNIQUEIDENTIFIER	BINARY(16)
SYSNAME	CHAR(256)

在实际进行中，还额外遇到了一个用来解决树形结构存储的字段类型 Hierarchyid。这个场景须要额外进行业务调整。

咱们在内部作了针对 MySQL 知识的摸底排查工做，并进行了若干次的 MySQL 使用技巧培训，将工程师对 MySQL 的认知拉到一根统一的线。

关于存储过程使用，咱们和业务方也达成了一致：全部 SQL Server 存储过程使用业务代码进行重构，不能在 MySQL 中使用存储过程。缘由是存储过程增长了业务和 DB 的耦合，会让维护成本变得极高。另外 MySQL 的存储过程功能和性能都较弱，没法大规模使用。

最后咱们提供了一个 MySQL 开发规范文档，借数据库迁移的机会，将以前相对混乱的表结构设计作了统一了约束（部分有业务绑定的设计，在考虑成本以后没有作调整）。

ETL 工具

ETL 的全称是 Extract Translate Load（读取、转换、载入），数据库迁移最核心过程就是 ETL 过程。若是将 ETL 过程简化，去掉 Translate 过程，就退化为一个简单的数据导入导出工具。咱们能够先看一下市面上常见的导入导出工具，了解他们的原理和特性，方便咱们选型。

MySQL 同构数据库数据迁移工具：

mysqldump 和 mysqlimport MySQL 官方提供的 SQL 导出导出工具
pt-table-sync Percona 提供的主从同步工具
XtraBackup Percona 提供的备份工具

异构数据库迁移工具：

Database migration and synchronization tools ：国外一家提供数据库迁移解决方案的公司
DataX ：阿里巴巴开发的数据库同步工具
yugong ：阿里巴巴开发的数据库迁移工具
MySQL Workbench ：MySQL 提供的 GUI 管理工具，包含数据库迁移功能
Data Integration - Kettle ：国外的一款 GUI ETL 工具
Ispirer ：提供应用程序、数据库异构迁移方案的公司
DB2DB 数据库转换工具：一个国产的商业数据库迁移软件
Navicat Premium ：经典的数据库管理工具，带数据迁移功能
DBImport ：我的维护的迁移工具，很是简陋，须要付费

看上去异构数据库迁移工具和方案不少，可是通过咱们调研，其中很多是为老派的传统行业服务的。好比 Kettle / Ispirerer，他们关注的特性，不能知足互联网公司对性能、迁移耗时的要求。简单筛选后，如下几个工具进入咱们候选列表（为了作特性对比，加入几个同构数据库迁移工具）：

工具名称	热数据备份保证一致性	batch 操做	支持异构数据库	断点续接	开源	开发语言	GUI
mysqldump	V 使用 `single-transaction`	X	X	X	V	C	X
pt-table-sync	V 使用 transaction 或 `lock table` 的 FTWRL	V	X	V	V	Pell	X
DataX	X	V	V	X	V	Java	X
yugong	X	V	V	V	V	Java	X
DB2DB	X	V	V	X	X	.net	V
MySQL Workbench	X	?	V	X	V	C++	V

因为异构数据库迁移，真正可以进入咱们选型的只有 DataX / yugong / DB2DB / MySQL Workbench。通过综合考虑，咱们最终选用了三种方案， DB2DB 提供小数据量、简单模式的停机模式支持，足以应付小数据量的停机迁移，开发工程师能够自助完成。 DataX 为大数据量的停机模式提供服务，使用 JSON 进行配置，经过修改查询 SQL，能够完成一部分结构调整工程。 yugong 的强大可定制性也为在线迁移提供了基础，咱们在官方开源版本的基础之上，增长了如下额外功能：

支持 SQL Server 做为 Source 和 Target
支持 MySQL 做为 Source
支持 SQL Server 增量更新
支持使用 YAML 做为配置格式
调整 yugong 为 fat jar 模式运行
支持表名、字段名大小写格式变化，驼峰和下划线自由转换
支持表名、字段名细粒度自定义
支持复合主键迁移
支持迁移过程当中完成 Range / Time / Mod / Hash 分表
支持新增、删除字段

关于 yugong 的二次开发，咱们也积累了一些经验，这个咱们下篇文章会来分享。

一致性校验工具

在 ETL 以后，须要有一个流程来确认数据迁移先后是否一致。虽然理论上不会有差别，可是若是中间有程序异常，或者数据库在迁移过程当中发生操做，数据就会不一致。

业界有没有相似的工具呢？有，Percona 提供了 pt-table-checksum 这样的工具，这个工具设计从 master 使用 checksum 来和 slave 进行数据对比。这个设计场景是为 MySQL 主从同步设计，显然没法完成从 SQL Server 到 MySQL 的一致性校验。尽管如此，它的一些技术设计特性也值得参考：

一次检查一张表
每次检查表，将表数据拆分为多个 trunk 进行检查
使用 REPLACE...SELECT 查询，避免大表查询的长时间带来的不一致性
每一个 trunk 的查询预期时间是 0.5s
动态调整 trunk 大小，使用指数级增加控制大小
查询超时时间 1s / 并发量 25
支持故障后断点恢复
在数据库内部维护 src / diff，meta 信息
经过 Master 提供的信息自动链接上 slave
必须 Schema 结构一致

咱们选择 yugong 做为 ETL 工具的一大缘由也是由于它提供了多种模式。支持 CHECK / FULL / INC / AUTO 四种模式。其中 CHECK 模式就是将 yugong 做为数据一致性检查工具使用。 yugong 工做原理是经过 JDBC 根据主键范围变化，将数据取出进行批量对比。

这个模式会遇到一点点小问题，若是数据库表没有主键，将没法进行顺序对比。其实不一样数据库有本身的逻辑主键，Oracle 有 rowid， SQL Server 有 physloc。这种方案能够解决无主键进行比对的问题。

如何回滚

咱们须要考虑一个场景，在数据库迁移成功以后业务已经运行了几个小时，可是遇到了一些 Critical 级别的问题，必须回滚到迁移以前状态。这时候如何保证这段时间内的数据更新到老的数据库里面去？

最朴素的作法是，在业务层面植入 DAO 层的打点，将 SQL 操做记录下来到老数据库进行重放。这种方式虽然直观，可是要侵入业务系统，直接被咱们否决了。其实这种方式是 binlog statement based 模式，理论上咱们能够直接从 MySQL 的 binlog 里面获取数据变动记录。以 row based 方式重放到 SQL Server。

这时候又涉及到逆向 ETL 过程，由于极可能 Translate 过程当中，作了表结构重构。咱们的解决方法是，使用 Canal 对 MySQL binlog 进行解析，而后将解析以后的数据做为数据源，将其中的变动重放到 SQL Server。

因为回滚的过程也是 ETL，基于 yugong，咱们继续定制了 SQL Server 的写入功能，这个模式相似于在线迁移，只不过方向是从 MySQL 到 SQL Server。

其余实践

咱们在迁移以前作了大量压测工做，并针对每一个迁移的 DB 进行线上环境一致的全真演练。咱们构建了和生产环境机器配置同样，数据量同样的测试环境，并要求每一个系统在上线以前都进行若干次演练。演练以前准备详尽的操做手册和事故处理方案。演练准出的标准是：可以在单次演练中不出任何意外，时间在估计范围内。经过演练咱们保证了整个操做时间可控，减小操做时候的风险。

为了让数据库的状态更为直观的展示出来，咱们对 MySQL / SQL Server 添加了细致的 Metrics 监控。在测试和迁移过程当中，能够便利地看到数据库的响应状况。

为了方便 DBA 快速 Review SQL。咱们提供了一些工具，直接将代码库中的 SQL 拎出来，能够方便地进行 SQL Review。再配合其余 SQL Review 工具，好比 Meituan-Dianping/SQLAdvisor，能够实现一部分自动化，提升 DBA 效率，避免线上出现明显的 Slow SQL。

最后

基于这几种方案咱们打了一套组合拳。通过将近一年的使用，进行了 28 个通宵，迁移了 42 个系统，完成了包括用户、订单、支付、电商、学习、社群、内容和工具的迁移。迁移的数据总规模接近百亿，全部迁移项目均一次成功。迁移过程当中积累了丰富的实战经验，保障了业务快速向前发展。

原文连接: https://blog.alswl.com/2018/03/sql-server-migration-1/

欢迎关注个人微信公众号：窥豹

3a1ff193cee606bd1e2ea554a16353ee