其次，合库合表后，原有SQL Server中各个表的自增主键ID冲突，所以新增实现RowDataMergeTranslator，其功能是，读取内存中的 RowData然后进行转换，将从SQL Server中读取的行数据，丢弃其原有的主键列，转而使用TiDB生成。并根据配置文件决定哪些表需要实现这一特性。
record.removeColumnByName(config.getDiscardKey());最后的Applier并未做改动，处理好的数据直接写入TiDB。
自此合库合表的事情我们解决了。
六、增量同步与实时校验
在实现这部分需求的时候，我们应用了SQL Server的CDC，并在增量同步的基础上增加了延迟验证数据正确性的功能。
更多关于CDC的内容，这里不再赘诉，你只需要知道它能获取到增量数据。
#CDC官方文档https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-ver15需要注意的是，CDC开启的时机需要在全量同步之前，保证CDC记录可以覆盖全量同步过程中产生的增量数据。
根据以上的流程图可以看到，Producer从SQL Server中读取CDC日志，并将其转化成一条包含表信息、列信息和行数据的消息，投递到Kafka中。下游的消费者在拉取到消息之后，把数据转化成兼容MySQL的SQL语句在TiDB中执行（这里也实现了合库合表），从而实现整个数据增量同步的过程。
这里还有另一个消费者实现数据校验功能，它会延迟五秒消费同一队列，并通过提取主键（或索引）的方式从TiDB中查出该条已经写入的数据，将两侧的整行数据做比较（本实践中去除主键后比较），如果有问题会进行尝试重新写入，如出现异常则向相关人员发送报警。
在实现了这些并进入到测试阶段后，我们发现了一个问题，1000+回复表，对应1000+CDC日志表，一个Producer就需要开启1000+线程，以设计的5s间隔去轮询这些表时，服务器CPU直接就跑满了，产生了大量线程等待，轮询CDC日志的及时性无法保证。通过分析业务和DBA查询得知，其实之家社区每天产生的回复有95%都集中在最新的5%的帖子当中，换言之，我们只有几十张表需要如此高频的去检索CDC日志，其他的表我们通过增加轮询间隔、分批部署等方式，将这个问题解决了。
细心的同学读到这里会发现，校验功能其实逻辑上并不严谨，如果说在五秒钟内上游数据产生了变更，就有可能会产生拿着新数据去校验老数据的问题。这里有两个解决方案，一、采用单partition的topic和单个消费程序，保证增量同步和校验的顺序严格一致，但此种方案性能相对较低，可用性无法保证。二、我们将SQL Server中的表行加入上版本戳（rowversion），将版本戳一并同步到TiDB中，校验时比较该值，如不一致则放弃本次校验，本方案会损失一定的校验样本，但可通过增加Partition和消费者提高性能和可用性。
七、回滚方案
之前我们提到了，当项目切换到TiDB以后，需要预防其出现不可预估的问题，能够随时切回SQL Server才能保障万无一失。
TiDB的binlog使得这件事情轻而易举，我们使用官方提供的Pump和Drainer将binlog抽取到Kafka之中，解析数据变更的内容，根据业务ID计算出数据在SQL Server中原本属于哪个库哪个表，然后进行数据同步。
通过业务ID决定数据写到哪个库表八、之家社区业务TiDB迁移改造
就业务的改造这一环节，因历史积淀，需修改的地方很多，分布于各个项目之中，我们采取通过接口查找实现、搜索代码、DBA帮助抓取SQL的方式，保证涵盖了100%的相关业务，只有这样才能保障上线后无故障。
数据访问层增加对MySQL语法的支持。
去掉SQL Server中的存储过程。
SQL Server和TiDB（MySQL）的语句和函数支持不尽相同，逐个改造、测试并优化。
根据TiDB索引的原理以及梳理出来的SQL语句，重新建索引。
与此同时，我们针对每一条改造后的SQL都进行了优化，使可以精确的命中最优的索引，从而实现了在十亿级数据量下，TP业务99%的响应时间在12ms，99.9%的响应时间在62ms。
九、TiDB周边体系建设
除以上迁移流程所涉及到的功能点以外，我们还制定了一些开发规范和一些实用工具的研发，用以保障TiDB在汽车之家更好的应用。
我们建立了完善的TiDB开发规范、运维规范、上线规范，并在公司内部对开发同学进行相关的培训。