为什么我们要从MySQL迁移到TiDB？
|
⑧DM 导入期间 Duration 升高 在 DM 导入集群期间，确实会因为写热点的问题导致集群整体 Duration 更高，因为 IO 争用会更明显。这里其实也是可以通过一些参数来让集群运行的更快的。
如下参数从原值调到-新值： raftstore: apply-pool-size: 3-4 store-pool-size: 3-4
storage: scheduler-worker-pool-size: 4-6
server: grpc-concurrency: 4-6
rocksdb: max-background-jobs: 8-10 max-sub-compactions: 1-2 可以看到效果如下：QPS 不再抖动，Duration 也恢复到正常的水平。
⑨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 的话，这块可以调优一下参数。 我们的场景是 TiKV 上没有明显的瓶颈，主要慢在了 scheduler latch wait duration，可以调下参数看看： storage: scheduler-concurrency: 204800000
raftstore: raft-max-inflight-msgs: 4096
调优完成后是有提升，但提升不大，我们得知新版本的 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])) ③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 导数据导致的。
去 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] 根据 table_id 去通过 information_schema.tables 表查一下，可以通过上述方式来定位到是哪张表导致的问题。 TiDB enum 导致的性能问题： enum 在 TiDB 3.0.2 进行 where 条件查找是，发现不能下推到 TiKV。官方说4.0GA 修复。临时办法是修改到其他类型。 （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
