ITPub博客

一、问题描述：tikv实例OOM，并且所有的tikv实例内存使用率非常高，超过90%天天报警；参数都是默认的！二、具体我的排查过程1、查看Block cache 配置是否不合理2、Raftstore Apply 速度跟不上 Raft Log 接收速度3、coprocessor 响应过大引起的 OOM4、网络问题或 gRPC 线程被打满导致 Coprocessor 响应堆积5、协程 (Corouti

问题描述：tidb 4.0.8+dm 1.0正在同步中的某个task任务：具体有如下的表task_3324.yaml- db-name: "glsdb"tbl-name: "ygz_rate_config"- db-name: "glsdb"tbl-name: "tax_entry_tmp_hst"- db-name:

问题介绍：tidb 4.0.8+dm 1.0dm_worker_3324_2目前运行在/data01的目录下，因为/data01空间不足，现在需要把dm_worker_3324_2这个worker相关的目录移动到新的目录/data02下，需要修改目录/data01为/data02。注意：ansible-playbook start.yml --tags=dm-worker -l  dm-

https://docs.pingcap.com/zh/tidb-data-migration/v1.0/skip-or-replace-abnormal-sql-statements被动跳过 SQL 语句假设业务上可以接受下游 TiDB 不执行此 DDL 语句（即继续保持原有的表结构），则可以通过使用 sql-skip 命令跳过该 DDL 语句以恢复迁移任务。操作步骤如下：一：使用 query-

一：环境介绍：因公司t采用dm 1.0版本，故本过程基于DM集群1.0版本，官方建议使用dm 2.0;  tidb集群版本4.0，上游mysql 社区版5.7.281）上游mysql：SIM:root:[(none)]>select version(); +------------+ | version()  | +------------+ | 5.7.28-l