为什么我们要从MySQL迁移到TiDB？

【51CTO.com原创稿件】当一张百亿数据量的表放在你面前，你将面临着什么?加列?哭吧，怎么也得等个几天甚至几周。加索引?哭吧，不论你用 pt-online-schema，还是 gh-ost，你都面临着拷贝一张临时表用以存储临时数据，磁盘已经 80% 了，这一张表就占几百 G，你咋弄?

图片来自 Pexels

我先说几个最让你兴奋和开心的点吧：

在 TiDB 里，你完全不用担心磁盘容量的问题。

在 TiDB 里，原生支持 Online DDL，你完全不用担心第三方改表工具改表出现各种 Bug 的问题，相信用开源工具改过上 T 级别表的同学都遇到过或多或少的各类 error。

在 TiDB 里，加列，主键扩容字段都是秒级的，比如我刚刚就刚对一张 19 亿的表加完了字段，1 秒完事，这在 MySQL 里要 8.0 才可以，而且还要求列在最后才行。

在 TiDB 里，你会发现 count(*) 惊人的快，一张近 20 亿的表 coun(*) 大概在 1 分钟完事儿，当然，这取决于你的 KV 数量和磁盘性能。

在 TiDB 里，从 MySQL 迁移将变得简单，图形化一键迁移，爽不爽?

在 TiDB 里，绝大多数情况你会发现比单机 MySQL 有更好的性能，当然也不排除一些例外，例如 enum 这样奇葩的字段类型。

在 TiDB 里，......，您且往下看，我慢慢和您说。

使用背景

360 云平台对 360 集团各大业务线均有提供服务支持，涉及的数据库支持方案有：MySQL、Redis、MongoDB、ES、GP、PiKA。

其中 MySQL 至今已有过万的实例，目前，对于一些写入量大的业务，已经出现瓶颈。

例如磁盘空间，虽然我们可以通过分库分表的方式，拆分出来，但这对业务和 DBA 来说都是不小的工作量，最痛苦的无异于这些大表的改表。

无论是单表上 T，还是分库分表，对一张大表执行 DDL 的代价是非常大的。

针对业务爆发式增长的数据量，我们开始调研选型是否有其他数据库可以代替传统的 MySQL。

通过调研我们了解到 TiDB，迁移平滑，基本上无需业务变动代码，完全的事务 ACID 支持，分布式的架构，自带高可用、Online DDL。

截止目前，360 云平台这边有三套 TiDB 集群，总节点数在 50+。有 9 个业务线接入使用，有过百亿级表 Online 加索引的案例，总数据量目前在 80T。

版本上，我们从 3.0.1 一路跟随到 3.0.5，DM 版本从内测到 1.0.2 GA 版本，共计提出 9 个 Bug 或改进项反馈。

后续我们计划将 TiDB 上到 360 HULK 云平台上，并定制化开发一些功能为业务提供可视化的服务，以便让 360 集团更多的业务线接触到 TiDB、使用 TiDB。

版本的选择我们之所以从大版本 3 开始，也是看到了一些 2.X 版本的社区反馈，尤其是索引执行计划这块，3.X 版本较之前的版本会好很多。DM 版本我们是直接选取的最新版，后一路跟随新版本升级。

集群架构

整体架构上，我们除了 TiDB 集群外，还用到了 DM 和 Pump、Drainer 套件。

这块主要是由于我们使用 TiDB 的业务有两种：

①老的 MySQL 业务，因单机磁盘受限，导致单实例磁盘无法支撑爆炸式增长的数据量，数据比较重要，需要备份和支持 7*24 小时的恢复。

这类业务我们用到 DM 套件来实现无障碍迁移，1TB 的导入时间在 16 小时，这里如果是比较大的数据源，且 TiDB 是全新集群，可以使用 TiDB-Lightning，速度可以更快。

Lightning 的实测导入速度，37 分钟，导完 2 张大表共计 54G 的数据，符合 100G/H 预估，是 loader 的 3 倍速度，loader 用时 2 小时 4 分钟。

说起 DM 使用这块文章后面会单独分享下这块需要注意的问题，如下图所示：

②全新的业务，或由业务自行导入到 TiDB 集群中，这种业务数据量一般都会比较大，也是看中了 TiDB 支持 ACID 和分布式的特点。

目前网盾业务有多张表都过 10 亿级别，其中有张表到达了 100 亿+，建索引花了近 10 天(这块其实我们应当注意，不是分布式就一张表就完事儿了，因为表量级过大，清理老旧数据都是个问题)。

TiDB 现在支持分区表，但我们在使用过程中发现性能上和普通表有差距，期待后续版本能够让分区表功能和性能更加的完善。

TiDB 在 360 云平台的使用情况

对于这一全新的数据库，我们本着大胆用，不拘泥于传统的态度进行使用。

我们的 MySQL 现在也正在适配 8.0 版本，MongoDB、ES 也都是时刻关注着新版本情况来评估是否适合云平台。

因此 TiDB 的上线也是从离线业务→边缘业务→核心业务来过渡的。

经过大量的测试、也参考了其他公司的使用情况，我们计划将 TiDB 纳入 360 HULK 云平台，并计划后期对其不断完善在云平台中的功能，对全公司业务线开放使用。

定制化开发一些 MySQL 已经具备的，例如 SQL 审核、慢查统计、冗余索引检测、自增索引阈值等各项基础功能等等。

虽然在使用过程中遇到了一些小问题，例如索引的选取、参数的调优，因为一些配置导致的性能抖动，但都得到了 PingCAP 同学快速的响应和回复，这对我们推进 TiDB 有重大的帮助。

一键迁移工具 DM 干货分享

DM 使用经验如下：

①权限

官网手册上只说明需要如下权限：

TiDB Lightning 需要以下权限：

SELECT

UPDATE

ALTER

CREATE

DROP

存储断点的数据库额外需要以下权限：

INSERT

DELETE

但实测过程中发现还需要如下权限：

上游 (REPLICATION SLAVE 权限必须具备，要不增量同步会 access deny)。

下游 (不加 super 会导致 checksum table 无法执行)。

②TiKV Region Score

PD 监控中 -Statistics-balance 中，有 Store-region-score 监控项，这里记录的是各个节点的 Score 得分，正常情况下，我们期望的结果是得分接近的，这说明无需进行 Region 大规模迁移。

③PD 调度原理

Region 负载均衡调度主要依赖 balance-leader 和 balance-region 两个调度器。

二者的调度目标是将 Region 均匀地分散在集群中的所有 Store 上，但它们各有侧重：

balance-leader 关注 Region 的 Leader，目的是分散处理客户端请求的压力。

balance-region 关注 Region 的各个 Peer，目的是分散存储的压力，同时避免出现爆盘等状况。

我们这里重点关注的是 balance-region，当它出现不均衡的时候，我们可以直接在监控中看到类似下图所示：

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!