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

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 功能。

TIPS：理解了作用和原理，上述参数都可以根据需求自行控制。
例如当我们在 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 ，以临时避免调度对业务产生的影响。
我们也可以控制调度的并发度，来减少对业务产生的影响，实测这都是立竿见影的参数，大家如果遇到这些问题可供参考。
对于第二点，尤其是使用 DM 期间，将 DM-worker 和 TiKV 混合部署的情况下，要注意清理全量备份留下的文件和 Relaylog 。

文章插图

默认调度策略是当磁盘剩余的有效空间不足 40% ，处于中间态时则同时考虑数据量和剩余空间两个因素做加权和当作得分，当得分出现比较大的差异时，就会开始调度。
所以 DM 导入完成后，要记得删除全量备份。就是 dumped_data.task_xxx 文件夹，这个全量备份一般都会比较大，如果 dm-worker 和 TiKV 混部，就会出现某个 TiKV 节点磁盘已使用率高于其他。
这时 PD 的 store region score 就会相比其他节点出现异常，引起性能抖动和 Duration 升高。

文章插图

一直等待其追上后，才会像下图这样：

文章插图

此时， balancer 已达平衡状态：

文章插图

Duration 恢复正常水平，如下图 16:54 分时的情况：

文章插图

QPS 也不再积压，恢复正常水准：

文章插图

关于 relay-log ，默认是不清理的，就和 MySQL 的 expire_logs_days 一样，这块可以通过 dm-worker 的配置文件来进行配置。
例如将 Expires 配置为 7 ，代表 7 天后删除：
[purge]interval = 3600expires = 7remain-space = 15Expires 来控制保留天数。默认 expires=0 ，即没有过期时间，而 remain-space=15 意思是当磁盘只剩于 15G 的时候开始尝试清理，这种情况我们极少会碰到，因此这个清理方式其实基本上是用不到的。
所以建议有需要删除过期 relay-log 的小伙伴，直接配置 Expires 保留天数就可以了。
DM 导入完成后，应该提供是否在完成后自动删除全备文件的选项，可以默认不删，由使用者决定是否删除。
从使用者角度来说，全量备份目录无论是全量一次性导入还是 all 增量同步，后续都不会再使用到。