作者：微信小助手
发布时间：2020-03-12T10:18:50
图片来自 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 里，......，您且往下看，我慢慢和您说。
使用背景
集群架构
说起 DM 使用这块文章后面会单独分享下这块需要注意的问题，如下图所示：
TiDB 在 360 云平台的使用情况
一键迁移工具 DM 干货分享
DM 使用经验如下：
①权限
SELECT
UPDATE
ALTER
CREATE
DROP
INSERT
DELETE
上游 （REPLICATION SLAVE 权限必须具备，要不增量同步会 access deny）。
下游 （不加 super 会导致 checksum table 无法执行）。
②TiKV Region Score
balance-leader 关注 Region 的 Leader，目的是分散处理客户端请求的压力。
balance-region 关注 Region 的各个 Peer，目的是分散存储的压力，同时避免出现爆盘等状况。
我们这里重点关注的是 balance-region，当它出现不均衡的时候，我们可以直接在监控中看到类似下图所示：
如何控制或减小 Region Balance 大规模迁移时对业务的影响；
如何提前规避因磁盘导致的大规模 Region Balance。
high-space-ratio 0.7 #设置空间充裕阈值为 0.7。当节点的空间占用比例小于指定值时，PD 调度时会忽略剩余空间这个指标，主要针对实际数据量进行均衡。
region-schedule-limit 8 #最多同时进行 8 个 Region 调度。这个值主要影响 Region Balance 的速度，值越大调度得越快，设置为 0 则关闭调度。Region 调度的开销较大，所以这个值不宜调得太大。也可以通过减小该值来限制调度region对集群产生的影响。
merge-schedule-limit 12 #最多同时进行 12 个 merge 调度。设置为 0 则关闭 Region Merge。Merge 调度的开销较大，所以这个值不宜调得过大。
leader-schedule-limit 8 #最多同时进行 8 个 leader 调度。这个值主要影响 Leader Balance 的速度，值越大调度得越快，设置为 0 则关闭调度。Leader 调度的开销较小，需要的时候可以适当调大。
max-merge-region-keys 50000 #设置 Region Merge 的 keyCount 上限为 50k。当 Region KeyCount 大于指定值时 PD 不会将其与相邻的 Region 合并。
max-merge-region-size 16 #设置 Region Merge 的 size 上限为 16M。当 Region Size 大于指定值时 PD 不会将其与相邻的 Region 合并。设置为 0 表示不开启 Region Merge 功能。
例如当我们在 Drop 大量的表后，会产生很多的空 Region。在 Region 数量较多的情况下，Raftstore 需要花费一些时间去处理大量 Region 的心跳，从而带来一些延迟，导致某些读写请求得不到及时处理。
如果读写压力较大，Raftstore 线程的 CPU 使用率容易达到瓶颈，导致延迟进一步增加，进而影响性能表现。
因此我们会希望尽快的进行 Region Merge，来避免过多的 Region 对集群造成性能损耗时，我们可以同时调小 max-merge-region-keys、max-merge-region-size，来让其更快的触发 Merge 操作，同时调大 merge-schedule-limit 提高并发度。
例如当我们发现某台 KV 磁盘空间剩余 40% 开始大量调度时，我们可以将 high-space-ratio 调整到 0.7，以临时避免调度对业务产生的影响。
我们也可以控制调度的并发度，来减少对业务产生的影响，实测这都是立竿见影的参数，大家如果遇到这些问题可供参考。
这时 PD 的 store region score 就会相比其他节点出现异常，引起性能抖动和 Duration 升高。
Duration 恢复正常水平，如下图 16:54 分时的情况：
QPS 也不再积压，恢复正常水准：
例如将 Expires 配置为 7，代表 7 天后删除：
[purge]
interval = 3600
expires = 7
remain-space = 15
④关于 DM 使用期间出现数据丢失的问题
在早期还没有 dm-portal 自动化生成 task 时，我们都是自行编写 DM 的 task 同步文件。后来有了 dm-portal 自动化生成工具，只要图形页面点点点就可以了。
我们也已经反馈给了官方。未来不久的版本估计就可以修复。
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD COLUMN `raw_url_md5` CHAR(32) NOT NULL DEFAULT '' COMMENT 'raw_url md5'"]
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD INDEX `idx_rawurl_md5`(`raw_url_md5`)"] [schema=flow]
["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` DROP INDEX `idx_raw_url`"] [schema=flow]
⑤关于 DM 使用期间偶发性 1062 主键冲突的问题
query-error task 能看到具体的报错信息，下游看都没有该值：
mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';
Empty set (0.00 sec)
再去上游看，结果发现也没有值，业务逻辑应该是后来 delete 了：
mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx';
Empty set (0.00 sec)