为什么我们要从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，当它呈现不平衡的时辰，我们可以直接在监控中看到相同下图所示：

（编辑：湖南网）

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