感谢细心解答!貌似接触到了问题的核心。想要细粒度控制,则必然需要label 精细化到region。我这边还不知道咋对region进行label化,能方便给个例子吗?配置文件中 tikv的label设置
满足的!集群信息:
[image]
创建语句:
[image]
【补充一下】
这套6.0.0版本是通过tiup直接部署安装的,不是通过离线版手动安装:
29731 2022-05-11 19:15:28 tiup cluster deploy tidb_cluster_v6.0 v6.0.0 /home/tidb/.tiup/storage/cluster/topology.yaml --ssh system
我们试过 5.3 版本的CDC,这个问题还没有解决;
是的!我们最开始计划是CDC同步的;CDC同步中也遇到了OOM问题;所以转战 Drainer
[root@lj-zeus-db-yzbx-119140 conf]# cat drainer.toml
WARNING: This file is auto-generated. Do not edit! All your modification will be overwritten!
You can use ‘tiup cluster edit-config’ and ‘tiup cluster reload’ to update the configuration
All configuration items you want to change can be added to:
…
[root@lj-zeus-db-yzbx-119140 ~]# ps aux | grep drainer
tidb 317286 40.9 97.0 322179104 191447764 ? Ssl 13:12 27:02 bin/drainer --node-id=10.200.119.140:8252 --addr=10.200.119.140:8252 --pd-urls=http://10.10.:2379,
http://10.10.:2379,
http://10.10.2379 --data-dir=/tidb/data/drainer-8252 --log-fi…
我这边24h的pump数据、三个实例加起来要4T+,不知道与这个量有没有关系。同时,我这边测试过创建有一个空的DB,然后新建一张表,里面只有一条记录,然后通过drainer做这个DB的同步,init_commit_ts=-1 。发现起进程时,还是一样的问题。
我可以接受从最新的commit_ts开始同步;但是貌似还是需要加载历史DDL操作。如果可以跳过,那是最好了。
感谢解答!确实有很多DDL变更。业务用的很粗。但,我们要如何处理或跳过这个问题嗯?单机 188GB 内存都不够用;
[image]
我们的drainer 已经吃了快150GB 了 还没有起来
299230 tidb 20 0 149.4g 149.2g 12552 S 35.4 79.3 10:10.52 drainer
299230 tidb 20 0 149.4g 149.2g 12552 S 35.4 79.3 10:10.52 drainer
这类超时问题,要如何处理呢?单独连接是可以连通的。
Error: executor.ssh.execute_failed: Failed to execute command over SSH for ‘tidb@10.202.x.x:22’ {ssh_stderr: , ssh_stdout: , ssh_command: export LANG=C; PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin /usr/bin/sudo -H bash -c “test -d /tidb || (mkdir -p /tidb && chown tidb:$(id -g -n tidb) /tidb)”}, cause:…
收到!感谢解答!我再追问一个小问题:
1、我们在业务同步上做了一些自动化的修复脚本,对dm_meta的表结构有依赖。想咨询一下2.0.7版本同同2.0.3版本元数据dm_meta表结构有变更吗?
2、是否建议直接由2.0.3升级至最新dm版本:2.0.7
3、我们这套 DM集群用于AP类场景,对实时性要求不是特别高。
#我想要纸质版书籍#
工作中团队小伙伴可以一起看
[mm]后经PingCAP同学帮忙定位,调整系统内核参数后,本地手动开启脚本后生效。但中控机ansible方式还是有问题,后期转战TiUP。