多点数千套集群实践：从“MySQL 又不是不能用，为什么选择 TiDB？”到“能用 TiDB 就不用 MySQL”

2024-05-17
北京
本文字数：1996 字
阅读完需：约 7 分钟

原文来源：https://tidb.net/blog/f3386b6b

作者：冯光普 TiDB 成都地区组织者 TiDB MVA 多点数据库团队负责人

背景

作为数字化零售解决方案 SaaS 提供商多点 DMALL 的数据库团队的负责人，我有幸在 2024 年 4 月 20 日的演讲中与大家分享了我们团队在数据库运维方面的经验与挑战，其中深入探讨了在大规模数据库运维中，MySQL 存在的问题，以及分布式数据库 TiDB 带来的创新和优势。在这篇文章中，我将进一步深入探讨我们选择 TiDB 作为数据库解决方案的考量和技术细节。

使用 MySQL 的挑战与痛点

在多点 DMALL，我们面临着所有大型企业共有的数据库运维问题。随着业务的不断增长，MySQL 的单机架构逐渐显得力不从心。

运维层面，实例迁移、主从切换、库表拆分和版本升级等，是 DBA 不得不做的高风险操作，但由于这些变更安全边界低、步骤多、参与方多，因而在执行时效率偏低、也容易出错，过程可能导致业务中断。

在架构层面，对于自建数据库的用户：

维护一套可靠的 HA 门槛不低，HA 组件本身的高可用也是一个问题；
由于 HA 组件与数据库本身是独立的，HA 本身不介入数据库事务提交，在网络抖动时其对主库失联或宕机可能存在误判，因此存在脑裂的风险；
数据持续增长，超过单机容量后，面临着库表拆分的难题，拆分后的业务 SQL 能力有损，要保证拆分过程平滑，那对 DBA 的要求就非常高。

因此，如果在云上，我更加建议大家直接使用云厂商的 RDS 服务，尤其是云原生数据库，比如 AWS 的 Aurora、阿里云的 PolarDB、腾讯云的 TDSQL-C 等；如果一定要自建数据库，建议使用分布式数据库，比如 TiDB。

实例迁移与主从切换

在 MySQL 运维中，实例迁移和主从切换是常见操作，但它们往往涉及变更风险，步骤也比较复杂。例如，主从切换可能导致短暂的服务中断，而实例迁移则需要精心规划，以在资源成本、稳定性、运维代价中取得平衡。

库表拆分与版本升级

随着业务的发展，数据库的库表拆分成为必然，但这对 DBA 要求较高，最好具备实战经验，才能保证拆分过程的平滑。版本升级也同样充满挑战，尤其是跨大版本的升级，如 MySQL 5.7 到 8.0，这不仅涉及到兼容性问题，升级过程也可能影响现有业务的运行。

TiDB 带来的创新

为了应对这些挑战，我们开始探索分布式数据库的可能性，最终选择了 TiDB。TiDB 的多项特性让我们眼前一亮：

透明扩展与 HTAP

TiDB 的透明扩展能力让我们能够轻松应对数据量的增长，而 HTAP 特性使得我们在一个数据库上同时处理事务型和分析型负载，这在以往是难以想象的。

强一致性与高可用性

TiDB 通过分布式事务和多副本机制，保证了数据的强一致性和高可用性。即使在节点故障的情况下，也能保证数据不丢失，服务不中断。

高压缩与多租户资源隔离

TiDB 的高压缩存储引擎，有效节省了存储空间；而多租户能力，可以支持不同业务在充分共享资源池的前提下，也能做到资源隔离，保障了性能和稳定性。

无损变更

TiDB 支持无损变更，无论是节点迁移、规格变更还是扩缩容，都不会影响正在运行的业务，因为无损，DBA 执行变更加从容和高效，与研发之间关系也更加和谐，这对我们来说是一大福音。

优秀的可观测性

TiDB 提供的 TopSQL 和 KeyVisualizer 等工具，让我们能够实时监控数据库性能，快速定位问题，大大提升了研发团队的工作效率，这两个在 Dashboard 中的功能，深受我们研发同学的喜爱。

关系数据库的发展趋势

通过 AWS 从 RDS 到 Aurora 的发展历程，可以看到关系数据库是朝着云原生（按需、弹性、无限）方向发展。特别是 Aurora Limitless Database 的推出，标志着数据库服务进入了一个新的时代，它通过分布式事务路由器和数据分片技术，实现了数据库的无限扩展。从 2009 年的云托管 RDS，到 2023 年的 Aurora Limitless Database，数据库一直在更加自动化、更加弹性、更加分布式。