DM全量迁移的背后就是做了一次dumpling+lightning，dumpling对上游为 MySQL 且表的主键或复合主键首列是 INT 的场景，会有表内并发效果，就是分批。

可以的，看这个方案： https://docs.pingcap.com/zh/tidb/dev/multi-data-centers-in-one-city-deployment/

2-2-1模式分别放voter、voter、follower，follower的AZ挂了不影响，voter的AZ挂了就把follower改成voter重新选leader就好

用placement-rules设置每个AZ放多少个副本 https://docs.pingcap.com/zh/tidb/dev/configure-placement-rules/

GC lifetime设置的多少啊

找个工具转一下，比如navicat、dbeaver这种 或者把ddl导出来让AI给你转成Oracle格式的

等锁超时了，和tidb没关系，和你的代码有关系，排查一下数据库操作逻辑吧

左边的tikv读写流量比右边高不少，感觉还是热点问题。 看下unified read pool的监控

用hint查tiflash的SQL也把执行计划打出来对比下

explain analyze 把执行计划打出来看看

1、看下store-5节点的磁盘读写延迟是否和其他节点相近，先排查磁盘没问题 2、iops明显高很多，有可能是其他服务在也在大量占用磁盘，用iotop查一下

1、密码不用写在-p后面，交互时再输入 2、deploy命令格式写错了，版本号漏了 tiup cluster deploy <cluster-name> <version> <topology.yaml> [flags]

看下这个有没有帮助：

pd-addr填一个pd地址就可以了

对，0是不限制 [image]

试试改 log.file. max-backups 和 log.file. max-days 这两个参数

dm组件里面就包含了dm-master和dm-worker

1、优化SQL减少内存占用 2、从业务角度对跑批任务做拆分