为什么我们要从MySQL迁移到TiDB？
|
调度期间，不可避免的会出现 IO 争用、磁盘的 lantency，都会出现不同程度的上涨，从业务上的反馈看，就会出现积压，响应不及时等等。而当 Region Balance 完成后， Duration 等都会恢复正常水平。 因此，我们要关注的地方有两点： 如何控制或减小 Region Balance 大规模迁移时对业务的影响; 如何提前规避因磁盘导致的大规模 Region Balance。 对于第一点，我们迁移的时候是有参数可以控制的。这里无论是磁盘空间阈值，还是 Region Balance 调度速度，或者 Drop 大量表后调整空 Region Merge 的速度，其实都是可以通过 pd-ctl 的 config set 命令来实时调节。 例如： 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 功能。 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 分时的情况： （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
