江苏龙网

  1. 主页 > 生活百科 > >

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

mysql

最终的优化结果是 ， QPS 稳定在 3K 左右：

为什么我们要从MySQL迁移到TiDB？

文章插图
 
⑦静默 Region 开启
在实际情况中 ， 读写请求并不会均匀分布到每个 Region 上 ， 而是集中在少数的 Region 上 。
那么可以尽量减少暂时空闲的 Region 的消息数量 ， 这也就是 Hibernate Region 的功能 。
无必要时可不进行 raft-base-tick ， 即不驱动空闲 Region 的 Raft 状态机 ， 那么就不会触发这些 Region 的 Raft 产生心跳信息 ， 极大地减小了 Raftstore 的工作负担 。
截至 TiDB v3.0.5 ， Hibernate Region 仍是一个实验功能 ， 在 TiKV master 分支上已经默认开启 。可根据实际情况和需求来开启该功能 。
参数如下：
raftstore.hibernate-regions: true
为什么我们要从MySQL迁移到TiDB？

文章插图
 

为什么我们要从MySQL迁移到TiDB？

文章插图
 
⑧DM 导入期间 Duration 升高
在 DM 导入集群期间 ， 确实会因为写热点的问题导致集群整体 Duration 更高 ， 因为 IO 争用会更明显 。这里其实也是可以通过一些参数来让集群运行的更快的 。
为什么我们要从MySQL迁移到TiDB？

文章插图
 
如下参数从原值调到-新值：
raftstore:Apply-pool-size: 3-4store-pool-size: 3-4storage:scheduler-worker-pool-size: 4-6server:grpc-concurrency: 4-6rocksdb:max-background-jobs: 8-10max-sub-compactions: 1-2可以看到效果如下：QPS 不再抖动 ， Duration 也恢复到正常的水平 。
为什么我们要从MySQL迁移到TiDB？

文章插图
 
⑨DM Debug 相关
DM 还有个注意点就是 dm-worker.toml 配置文件里的配置 log-level=“debug” 是不生效的 ， 启动的时候默认有个 -L=info 选项 ， 会覆盖掉配置文件里的 ， 默认 -L 优先级高于配置文件 ， 人工排查时自行启动 。
也就是说当需要对 dm-worker 开启 debug 模式 ， 要人工拉起进程并指定 -L 选项=debug 。
⑩TiDB load data 速度不理想
TiDB 目前 load data 的导入速度不及 MySQL ， 如果依赖 load data 的话 ， 这块可以调优一下参数 。
storage:scheduler-concurrency: 204800000raftstore:raft-max-inflight-msgs: 4096我们的场景是 TiKV 上没有明显的瓶颈 ， 主要慢在了 scheduler latch wait duration ， 可以调下参数看看：
为什么我们要从MySQL迁移到TiDB？

文章插图
 
调优完成后是有提升 ， 但提升不大 ， 我们得知新版本的 TiDB 在 Load data 这块又有速度提升 ， 比较期待新版本 。
其他干货打包分享①TiDB 列数超限
MySQL 是 1024 ， TiDB 目前限制是 512 列 。如果你的表有非常多的列 ， 那么这块要提前注意下是不是可以拆分出去 。
②GC can not work
GC 的数据包括两部分 ， 一部分是 DML 和 DDL  ， DDL 的 GC 的对象信息包含在 mysql.gc_delete_range 和 mysql.gc_delete_range_done  ， 分别记录的是待 GC 的对象以及已经 GC 的对象 。mysql.gc_delete_range_done表里面没有数据不代表 GC 异常 。
官方建议更换规则：
sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d]))
为什么我们要从MySQL迁移到TiDB？

文章插图
 
③TiDB or 条件优化
在 TiDB 中 ， 如下查询是不能用到索引的：
select * from manual_domain where host_md5= '55fbea39965484a61xxxxxxxxxx'or domain_md5 = '55fbea39965484a61xxxxxxxxxx';MySQL 中用到了 index_merge ， TiDB 计划 4.0 支持 ， 可以先用 union all 来处理这种 a or b 。
④Coprocessor CPU 消耗过大
业务反馈查询变慢 ， 发现是另外一个业务全表扫 insert into select 导数据导致的 。
为什么我们要从MySQL迁移到TiDB？

文章插图
 
去 CPU 占用率高的这台机器上搜索对应的 log ， 关键字 slow ， 发现如下情况：
[2019/09/18 10:04:37.339 +08:00] [INFO] [tracker.rs:150] [slow-query] [internal_key_skipped_count=46649] [internal_delete_skipped_count=0] [block_cache_hit_count=1596] [block_read_count=9] [block_read_byte=31933] [scan_first_range="Some(start: 7480000000000002285F72800000000021E9BD end: 7480000000000002285F72800000000024199A)"] [scan_ranges=1] [scan_iter_processed=46650] [scan_iter_ops=46652] [scan_is_desc=false] [tag=select] [table_id=552] [txn_start_ts=411244239493267464] [wait_time=2ms] [total_process_time=1.41s] [peer_id=ipv4:192.168.1.248:45686] [region_id=835437]


推荐阅读


上一篇：茶友的品茶心得,江西茶业开年大事暨泰斗品茶论道高峰论坛

下一篇：茶叶蛋的配料有哪些呢,怎样做好吃的茶叶蛋呢