#查询开启CDC的表SELECT name FROM %s.sys.tables t WITH (nolock) JOIN%s.[cdc].[change_tables] ct WITH (nolock) ON t.object_id = ct.source_object_id
其次，合库合表后，原有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开发规范、运维规范、上线规范，并在公司内部对开发同学进行相关的培训。
开发了实时慢SQL分析工具——TiSlowSQL，该工具可以提供实时、多维度、全视角的SQL报告，帮助我们快速定位慢SQL导致的集群级故障。
为解决监控单点问题，我们自己开发了一套监控工具，对TiDB核心组件进行监控，后续会将监控系统统一迁移到之家云平台。
定期在汽车之家大学举行技术培训，定期在组内进行技术分享，经验总结。
十、总结与展望
汽车之家社区已于9月底正式上线分布式数据库TiDB，目前运行稳定。在其他业务迁移完成之后，之家社区的SQL Server服务会逐步下线。对于本次迁移的过程我们做了以下几点总结：
通过不断的优化SQL，目前线上TP99 稳定，与迁移之前并无太大差别，跟测试效果相符。对用户和业务都无感知。
随着业务的不断扩大，可以更好的应对数据的暴增，再扩容集群就不需要找昂贵的大存储机器，而且可以在线不停业务随时扩容。
本次迁移我们积累了SQL Server转TiDB的很多经验，可以为其他团队使用分布式数据库TiDB提供技术支持，让其他团队在迁移过程中节省时间。
目前正在与TiDB官方沟通，准备把迁移方案和与业务无关的迁移逻辑放到开源社区。
由SQL Server迁移至TiDB，从传统关系型到分布式HTAP ，从商业授权到开源社区，是汽车之家社区历史上一次重大的技术方向转型。之家有很多海量数据的应用场景，这一次从SQL Server到分布式数据库TiDB的迁移，为我们以后其他业务迁移至 TiDB 打下了良好的基础，也与TiDB官方建立了良好的定期沟通机制，希望TiDB官方一如既往的快速迭代，我们也会和TiDB官方合作开发一些比较实用的功能。
汽车之家社区从传统商业数据库到开源分布式数据库的架构变迁
标签：去除 ocs 技术支持 问题 公司 技术培训 uga img 阿里巴巴
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。TEL:0731-84117792 E-MAIL:11247931@qq.com
Copyright © 2019-2022 湖南福仁科技有限公司 版权所有
湘ICP备19013665号-5
视频许可证编号：（湘）字第00637号
湘公网安备 43010402000898号
违法及侵权请联系：TEL:0731-84117792 E-MAIL:11247931@qq.com 本站由北京市万商天勤律师事务所王兴未律师提供法律服务
