专栏 - 骏伯网络：为什么要从 MySQL 迁移到 TiDB ？用 MySQL 不是更省吗？

编者按

骏伯网络作为一家专注于移动互联网营销的公司，随着业务的不断扩展，数据库运维的复杂性和成本逐渐成为制约发展的瓶颈。最终，公司选择从传统的多套 MySQL 架构迁移到 TiDB 这一新兴的分布式数据库平台来解决这一挑战。

本文根据广州骏伯网络科技有限公司系统架构师唐帆，在 TiDB 社区深圳活动上的精彩演讲整理而成。

作者：唐帆｜广州骏伯网络科技有限公司系统架构师

随着业务量的激增，我们遭遇到了数据库性能的瓶颈和高可用性的难题。维护多套 MySQL 数据库不仅运维效率不高，而且难以达到理想的高可用性标准，频繁的服务中断与故障对公司的经济和声誉造成了严重影响。因此，我们迫切需要一种更稳定、高效且易于管理的数据库系统，以支持业务的持续增长和市场竞争力的提升。

本文将详细阐述我们在这一转型过程中遇到的挑战、所采取的策略，以及迁移后实现的积极成效。我们希望通过分享这次转型的深入实践和技术经验，为其他在数据库管理上寻求创新突破的企业提供实用的参考和启发。

业务的挑战：越来越复杂的投放方式

作为一家专注于移动互联网营销的广告公司，我们的业务链路涉及广告主、我们自己、媒体和最终用户。随着公司业务的不断扩展和市场需求的快速变化，面临的业务挑战主要集中在以下几个方面：

数据库运维效率低下：随着业务量的增长，我们使用的多套 MySQL 数据库系统使得运维工作变得复杂且效率低下。数据库的管理和维护需要大量的人力资源，且容易出错。
高可用性未实现：传统的主备高可用架构在遇到硬件故障时存在业务无法自动切换和人工操作失误的风险，一旦数据库出现故障，很可能导致整个业务系统的中断，造成经济损失和客户信任度下降。
故障频发：由于依赖于单点的数据库服务，我们频繁遭遇服务中断的问题。每次故障发生时，运维团队都需要手动介入进行修复，这个过程耗时且容易引发二次故障。
业务连续性难以保障：在广告营销领域，业务的连续性至关重要。数据库的不稳定直接影响到广告投放的效果和客户的服务质量，进而影响到公司的收入和市场竞争力。
数据量增长带来的性能问题：随着数据量的快速增长，尤其是在高并发的场景下，原有的 MySQL 数据库在性能上表现出了瓶颈，无法满足业务对于快速响应的需求。
系统扩展性和灵活性不足：业务的快速发展要求后端数据库系统具有良好的扩展性和灵活性，能够快速适应市场变化和业务需求的调整。原有的数据库架构在这方面表现不足，限制了业务的创新和快速迭代。
成本控制压力：数据库的运维成本随着业务量的增加而不断上升，包括硬件投入、人力资源以及时间成本等。如何有效控制成本，同时提升服务质量，是我们亟待解决的问题。

高昂的故障成本和系统不可靠因素

数据库的稳定性和可靠性是保障企业持续增长的关键因素。然而，随着数据量的不断攀升和业务需求的日益复杂，原有的多套 MySQL 数据库架构开始显现出其局限性，特别是在故障成本和系统不可靠因素方面。

故障成本是企业在数据库系统发生故障时所承受的经济损失，这包括直接的财务损失和间接的商誉损害。我们在 2023 年的前两个季度中，由于数据库故障导致的直接经济损失就已经是 2022 年全年的三倍，这一数字不仅凸显了故障带来的严重后果，也反映了故障频率和影响程度的增加。服务中断意味着广告投放的延误，影响了客户的营销活动，进而可能导致客户流失和收入下降。

系统不可靠的因素主要包括硬件故障、数据库软件的缺陷、以及人为操作的错误等。我们的分析显示，大约 60% 的事故原因可以归咎于系统的不可靠性。硬件故障可能导致数据丢失或服务中断，而数据库软件的缺陷可能引起数据不一致或查询性能下降。此外，人为因素，如不当的数据库配置或错误操作，也可能引发服务不可用。这些不可靠因素共同导致了系统稳定性的下降，影响了业务的连续性和客户满意度。

市场调研与 TiDB 选择背后的故事

面对故障成本的增加和系统不可靠因素的挑战，我们认识到必须采取行动，改进数据库架构以提高整体的可靠性和运维效率。我们设定了几个核心目标：

实现真正的高可用性
对现有业务系统的侵入性要少
保障业务连续性
性能不能降低

寻求可以满足以下功能的数据库：

数据冗余备份：确保在硬件故障、自然灾害或人为错误等情况下，数据能够得到有效的保护和恢复。
自动故障检测和故障转移：能够自动检测故障，并在出现故障时进行自动故障转移。这样可以最大程度地减少数据丢失和服务停机时间。
高可靠性和稳定性：能够在长时间运行过程中保持高可靠性和稳定性确保数据完整。
容易管理和维护：容易管理和维护，以减少运维成本和管理复杂度。

在我们的数据库转型过程中，团队进行了深入的市场调研，以确定最佳的技术方案。除了 TiDB，调研的方向还涵盖了以下几个数据库解决方案：

MySQL 原生集群：考虑使用 MySQL 的原生集群功能来提升现有系统的可用性和扩展性。但部署和管理复杂，性能相对较差。
MySQL 高可用组件：评估了多种数据库高可用性组件，但改造倾入性强，改造成本高且有较大的学习成本。同时，在处理大量数据或高并发时性能一般。
PG 集群：探索了基于 PostgreSQL 的集群技术，评估其是否能满足公司的业务需求和性能指标。虽支持主从和流复制，但兼容性不佳，改造成本高。
云服务：云服务可提供便捷的数据库管理能力和弹性扩展优势，但由于迁移至云服务的成本过于高昂，这一方案最终未被采纳。

在综合评估 TiDB 以及上述方案后，我们最终决定以 TiDB 作为数据库转型的核心技术选型。这一选择旨在依托 TiDB 的特性解决当前面临的性能瓶颈与高可用难题，同时为未来业务发展搭建稳定可靠的数据支撑平台。

MySQL 迁移到 TiDB 的迁移过程与收益

验证流程

迁移测试：在迁移之前，团队对 TiDB 进行了彻底的测试，以确保其能够兼容现有的 MySQL 业务逻辑。这包括了对数据类型、SQL 语法、存储过程和触发器的兼容性测试。
业务功能回归测试：迁移后，执行了一系列回归测试来验证业务功能是否正常运行。这确保了迁移没有引入任何新的问题，并且所有业务流程都能在新数据库上顺利执行。
标准性能测试：进行了标准的性能基准测试，以评估 TiDB 在不同负载下的表现。测试包括了查询响应时间、事务处理速度和并发处理能力。

部署架构

物理机部署：选择了四个物理机来部署 TiDB 集群，以确保足够的计算和存储资源。
PD 节点：设置了三个 Placement Driver (PD)节点，负责集群的元数据管理和调度。
监控节点：部署了一个专门的监控节点，用于实时监控 TiDB 集群的状态，及时发现并处理潜在的问题。

验证结论

TiDB 迁移成本非常低，项目代码几乎无须改动，数据迁移使用官方 Dumpling、DM 等可实现全量、增量迁移
TiDB 高可用方面在 3 副本情况下可支持 1 台物理机故障，且故障能自动转移
TiDB 可完整兼容现有主营项目，服务运转正常
TiDB 压测性能略优于 MySQL 单机版本

迁移流程

技术经验

Batch 语法：利用 TiDB 的 Batch 语法，优化了单表批量操作，减少了因大事务导致的性能问题。
批处理能力：通过IMPORT INTO和SELECT ... INTO OUTFILE实现了高效的数据批处理，提升了数据处理速度。
资源管控：使用了 TiDB 的资源管控特性，通过资源组(RG)对不同业务负载进行资源管理和优先级调度，优化了资源使用。
慢查询优化：面对慢查询问题，实施了实时监控，并采取了优化措施，如索引调整和查询重写。
IO 热点：针对 IO 热点问题，通过优化业务逻辑和改进索引设计，减少了对特定数据集的密集访问。

迁移收益

将多套 MySQL 迁移至 TiDB 后，我们在业务支撑、技术效能与成本控制等维度均获得了显著收益。

技术效能显著提升：40 多套业务系统整合为单一 TiDB 集群，运维管理效率提升 10 倍以上；性能上，TiDB 在高并发与大数据量处理场景表现突出，配合资源管控特性，实现了资源的精细化分配与调度。
业务支撑能力增强：即便经历 10 次物理宕机或服务故障，系统稳定性与数据一致性仍得到可靠保障；其自动故障转移能力经测试验证，有效支撑了业务的高可用性需求。
成本控制成效明显：得益于 TiDB 与 MySQL 的高度兼容性，迁移过程中代码改动量大幅减少，结合硬件需求降低，节约了长期运营开支。

结语

总体来看，这次数据库迁移不仅让系统性能与稳定性实现跃升，更关键的是为我们互联网营销业务的核心需求提供了精准适配的技术底座。面对营销场景中流量骤增的脉冲式压力、用户行为数据的爆炸式增长，以及市场策略快速迭代的高频需求，TiDB 凭借弹性扩展能力、高并发处理效率和稳定可靠的运行表现，成为了业务敏捷响应的“强后盾”。

我们的实践印证，TiDB 不仅通过简化运维、提升效率让技术团队从繁琐的底层维护中解放出来，更以灵活的架构支撑着业务的快速上线、用户需求的精准触达。这种技术与业务的深度协同，让我们能更聚焦于打磨营销策略、优化用户体验，在瞬息万变的市场竞争中始终保持敏锐与领先。

骏伯网络：为什么要从 MySQL 迁移到 TiDB ？用 MySQL 不是更省吗？

编者按