为什么我们要从MySQL迁移到TiDB？( 二 ) _MySQL

文章插图

②全新的业务，或由业务自行导入到 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 ScorePD 监控中 -Statistics-balance 中，有 Store-region-score 监控项，这里记录的是各个节点的 Score 得分，正常情况下，我们期望的结果是得分接近的，这说明无需进行 Region 大规模迁移。
③PD 调度原理
Region 负载均衡调度主要依赖 balance-leader 和 balance-region 两个调度器。
二者的调度目标是将 Region 均匀地分散在集群中的所有 Store 上，但它们各有侧重：