本文作者：TiDB 社区版主、TiDB 华南地区组织者李文杰老师
导读
近年来，信息技术应用创新进程加快，数据库国产化作为其中的关键一环，涉及全产业链的全栈适配。随着国产数据库和系统的自主发展、技术探索的深入以及国家政策的推动，国产化替代已成为企业发展的必答题。本文将基于 TiDB 社区版主、TiDB 华南地区组织者李文杰老师在深圳交流活动上的分享，深入探讨数据库国产化、TiDB 数据库的优势场景、高可用架构构建、国产化环境切换实践及优化要点，希望能为正在或计划进行数据库国产化改造的企业提供有价值的参考。
国产数据库如何选？
如今，国产数据库百花齐放，包括非关系型数据库、关系型数据库 OLAP、OLTP、时序数据库、文档数据库和分布式数据库等多种类型。在选择合适的国产数据库时，企业需综合考虑多个维度，如数据量规模、延时容忍度和混合负载率。
数据量较小（GB 级别）时，单机内存或单机数据库可能就能满足需求；但当数据量达到 10 TB、百 TB 甚至 PB 级别时，就需要选择更具扩展性的数据库。对于在线交易系统等对延时敏感的业务，数据库的响应速度至关重要；而混合负载率则决定了在线实时业务和统计分析报表类业务能否在同一数据库中高效执行。 
在具体评估时，要结合自身业务的存储、查询、分析需求，对数据库的性能、稳定性、安全性进行技术评估，考量其生态系统的完善程度，包括社区支持和第三方工具支持等，同时也要权衡硬件、软件、运维、升级等成本效益。
TiDB 的选型优势与适用场景
TiDB 在国产化环境中具有天然的选型优势。它适用于分库分表场景，能天然支持超大表存储，有效解决分库分表带来的瓶颈问题。对于综合类业务，无论是 TP 流量访问还是 AP 访问，TiDB 都能良好适配。其纯分布式架构赋予了它强大的扩展性，可在线无缝扩缩容，从容应对业务增长带来的性能和存储压力。
另外，TiDB 高度兼容 MySQL 协议，业务代码几乎无需修改即可使用，极大降低了迁移成本。它还支持超大单表存储且无需分库分表，通过分布式技术支持灵活的在线扩缩容操作。周边配套工具完善，数据迁移方便，有效降低了运维成本。此外，TiDB 拥有活跃的开源社区，技术更新及时，问题回复和解决率高，并且满足国产化和信创要求。
TiDB 如何构建高可用数据库服务
TiDB 的内核架构具备金融级高可用特性，不存在单点瓶颈，采用多副本存储，通过 Multi - Raft 协议同步数据副本，保证数据实时强一致性。TiKV 采用行存，支持高并发交易业务；TiFlash 采用列存，支持复杂分析查询，是名副其实的高性能实时 HTAP 数据库； 同时，TiDB 还支持一键水平扩缩容，操作对业务透明。
在实际应用中，在去年的活动上我也提到了某业务系统采用两地三中心部署方案，这也成为了后续上线的方案原型。
后来在某业务系统中落地实施了两地三数据中心的部署，通过不同的访问入口接入不同的 TiDB server，底层 KV 和 PD 分布在不同的可用区或机房。该系统采用应用双活的容灾策略，实现了数据零丢失（RPO = 0）和故障秒级自动切换（RTO < 60 秒），支持交易和大型数据分析型应用。在系统割接过程中，TiDB 与 MySQL 高度兼容，应用适配几乎无缝迁移。通过提前迁移历史基量数据，整个割接窗口控制在 4 小时内，高效且平稳。割接后，系统访问延迟大幅降低，平均处理性能提升约 30%，数据总存储空间由 40TB 缩减至 10TB，节约了 75% 的存储成本。
不过，在实践过程中也遇到了一些问题。由于基量数据大，迁移耗时久，后续采用提前迁移基量数据，再进行增量同步的方式，并定期校验上下游数据一致性。针对热点问题，通过分析热点产生原因，重新设计表结构，避免连续自增整形字段，引入随机 ID，以及在业务层面避免大范围数据扫描来解决。对于慢查询，利用官方提供的 dashboard 页面找出慢查询语句，交给业务方优化。而 DDL 元数据锁问题，可通过关闭元数据锁功能，并借助业务重试机制保证业务正常运行。 
如何实现优雅地切换到国产环境
1）操作系统迁移：CentOS→CTyunOS无感切换
从 Centos 到 CTyunOS 的操作系统在线平滑替换，通过扩容新节点、缩容旧节点的方式进行。先对管理节点 tiup、监控节点 Prometheus、Alertmanager、Grafana 等进行替换，再依次替换管理节点 PD、存储节点 TiKV 和 TiFlash、计算节点 TiDB 以及其他节点（如 TiCDC）。
在替换过程中，遇到了一些问题，如 PD 节点替换时其他节点宕机导致集群不可用，通过申请冗余机器，先扩容备用节点解决；大集群逐台操作耗时久，批量替换 TiKV 节点易导致集群服务抖动，通过与业务方沟通，在业务低谷期操作，并提前在测试环境验证一次操作的机器数来解决；升级后机器无法重启，修改启动配置文件grub.conf，将crashkernel的值由auto改为512M即可；操作系统内存页 64K 问题影响数据库性能稳定性，通过内核升级或使用回 4K 的版本解决。
2）硬件迁移：X86→ARM混合部署
国产化主机从 X86 到 ARM 的在线平滑迁移，同样采用扩缩容方法。先对管理节点 tiup、监控节点等进行迁移，再依次迁移其他节点。
在迁移过程中，要注意跨平台长期运行可能出现性能不均衡、不稳定的问题，仅建议在扩缩容期间运行。操作前需用 BR 进行全量数据备份，备份 tiup 的元数据和监控数据，准备回滚方案。操作 pd 节点时，单次只操作一个，并标注节点平台。执行扩容的节点的 yaml 文件需对各节点标明arch，如amd64或arm64（aarch64与arm64等同）。迁移完毕后，及时清理旧现场，避免元数据混淆。
此外，ARM 环境下要避免跨 NUMA 访问内存，强烈建议绑核。TiDB 支持在 yaml 文件配置numa node进行绑核，其他数据库可使用numactl或taskset等方式绑核，同时不要忽略网卡中断绑核，通过echo $cpuNumber > /proc/irq/$irq/smp_affinity_list将网络与运行的 CPU core 绑定。
数据库国产化改造总结
数据库产品的性能和稳定性受软硬件因素综合影响，国产化环境下的数据库产品能力的提升，尤其依赖于软硬件全栈的深度适配和优化。不仅需要提供稳定且高性能的存储、计算、网络的资源底座，还需要持续打磨和优化数据库内核，使得在最佳适配的操作系统和内核环境下，实现数据库能力的全面提升。
数据库内核的大事务复制 binlog 提交锁、高可用架构及安全组件优化等直接影响数据库系统的性能和稳定性，需要全面提升内核能力。操作系统在资源分配和系统调用方面影响数据库性能，如内存页大小、内存大页关闭、内存压缩等因素，要针对不同业务场景和数据库产品配置合适的系统和内核参数。虚拟化技术会增加系统资源开销，影响数据库性能和稳定性，需对虚拟化进行全面优化。网络的数据传输效率和稳定性直接影响数据访问性能，应使用高速网络连接，支持 DPU 等架构。存储的介质和架构，如本地 NVME、SSD、云盘等，对数据库性能影响重大，要搭配高性能存储，关注存储的 IOPS 和时延。CPU 架构也会影响数据库的并发处理能力，应使用高性能的多核处理器，并注意 BIOS 设置等操作。
数据库国产化是一个复杂但意义重大的过程，TiDB 在其中展现出了强大的优势和潜力。通过合理选型、精心构建高可用架构、顺利完成国产化环境切换以及持续优化软硬件配置，企业能够在国产化浪潮中实现技术自主可控，提升数据处理能力和业务竞争力。希望本文的分享能为大家在数据库国产化道路上提供有益的借鉴。
分享 PPT 下载
活动预告
🚀 4 月 12 日，TiDB 社区活动（南京站）即将开启，传统技术栈替换和 AI 浪潮正当时，面向未来的国产数据库怎么选择？一键 get 金融、医疗、文娱行业从 MySQL/Oracle/SQL Server/Hadoop 到 HTAP 数据库 TiDB 的国产化实践！欢迎感兴趣的 TiDBer 线上/线下参与！
