大咖观点 | 从数据库国产化替代到XC替代

（文章内容引自“白鳝的洞穴”）

最近和几个企业用户交流关于数据库国产化替代的事情，他们说目前要求又有所收紧。从以前的关键系统XC替代，其他系统国产化替代已经变成全面XC替代了。

对于要求的升级，目前他们的压力很大。因为最近十年间，他们用MySQL替代了大量的Oracle数据库，甚至有些年新建系统默认使用MySQL。目前，仅MySQL数据库实例就有上千个。如果要实现完全合规，二次迁移的压力很大。

MySQL是国内党政、央国企流行度最高、装机量最大的开源数据库。根据一项非官方统计，目前有接近300万套MySQL数据库在党政、央国企等的数据中心运行，其中超过一半都面临向XC数据库迁移的需求。

短期内想要实现迁移，完全平替是成本最低的选择。

目前在XC名录中，MySQL内核兼容的数据库有腾讯云TDSQL（集中式、分布式）/万里数据库GreatDB（集中式）/GoldenDB（分布式）/PolarDB-X(分布式）这几款数据库产品。OceanBase、TiDB与MySQL客户端协议兼容，不过内核是完全不同的，在一些兼容的细节上存在一定问题。

其他XC数据库虽然也与MySQL存在较强兼容性，不过大部分是SQL层面上的兼容。如果遇到一些十分特殊的SQL语句，还是要做一定的改造。

目前，国产数据库基于MySQL内核开发的数据库有很多，分布式数据库居多。因为分布式数据库在全局事务处理、数据分片方面的特殊性，实际上，大多数基于MySQL内核的国产分布式数据库在SQL语法上都与原生MySQL的SQL语法有一定差异。再考虑到迁移成本、运维难度等方面因素，对于数据库规模不大、业务并发量并不大的党政系统而言，不太建议使用分布式数据库进行替代。

如果想要把大量的MySQL数据库或云上MySQL RDS数据库平替为XC数据库 ，选择内核兼容的产品，迁移难度是最低的。因此，TDSQL、万里数据库、GoldenDB和PolarDB这四个产品是作为首选的。

其中，GoldenDB和PolarDB均为分布式数据库，并且都支持租户管理，在分布式数据库中创建一个集中模式的租户来替代原有的MySQL数据库实例，也是目前使用这两种数据库的用户中比较普遍的模式。

PolarDB目前主要以云上部署为主，对于已经大规模使用阿里云的用户来说，如果在价格相差不大的情况下，可以作为首选。GoldenDB的客户群体主要面向金融、运营商、能源等大型用户，可以使用租户方式，将集中式的MySQL实例迁移到GoldenDB分布式数据库集群中。从GoldenDB 6.1开始已经全面兼容MYSQL 8.0，因此如果对许可证价格不太敏感的用户来说，GoldenDB也是平替MySQL的一种选择。

TDSQL的集中式与分布式MySQL均通过了XC测试，如果要将集中式MySQL数据库迁移到TDSQL分布式数据库，难度相对较大。不过，如果要迁移到集中式数据库，则相对容易。这也是目前的金融、国税等用户使用TDSQL最常用的方式。

在这四个数据库产品中，万里数据库GreatDB是唯一一个客户端与内核100%兼容MySQL的产品。如果原有的数据库均为集中式架构，选择GreatDB迁移适配的成本相对更低。万里数据库拥有一批MySQL社区的活跃贡献者，在MySQL的技术储备上是有一定优势的。

GreatDB 与 MySQL 的高兼容性从技术底层保障了数据迁移的安全性与强一致性。其特有的不停机迁移方案无需依赖第三方工具，依托 MySQL 架构体系的适配性，通过数据库底层原生复制机制实现数据同步，既提升迁移效率，又避免因业务中断造成的损失，进一步强化了业务安全性。

虽说这几种数据库与MySQL都有较强的兼容性，不过想要做到基本不改代码实现平滑迁移也并非易事。遇到问题如何能更加快速、比较简单地解决问题也是比较重要的。

就以MySQL迁移中经常遇到的保留字问题来说：当遇到SQL语句里出现了GreatDB的保留字，导致SQL无法正常执行时，GreatDB提供了一种十分简便的处置方案：只需通过【反引号】将相关变量名引用起来，即可避免因关键字冲突导致的语法错误，确保应用代码的正常执行。

对于广大MySQL数据库用户来说，XC提到的产品选择也不是盲选。数据库产品在一些细节上的处理、服务支撑的力度都决定了用户的选择。

前阵子和万里数据库的同学一起交流了数据库替代工作中的不停机快速切换、双轨制运行、系统回切等用户的关键系统切换中最为关心的问题，目前GreatDB提供的全系列工具里都有比较好的支持，并且在最近的一些项目中颇受顾客好评。有些时候，用户在做选择时，最后打动用户的很可能就是一个很小的细节。