【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】任何版本
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
如标题，最近业务调整数据高可用架构需要部署 TiDB 的主从集群，实时同步工具使用 TiCDC，但是对于一个集群而言想要申请单独的 TiCDC 机器部署，成本高。
业务特点是 TP 流量占据80%+ 20%中低强度AP流量，集群整体写QPS在万级。
目前计划通过TiCDC和其他组件混合部署来达到这一目的，社区各位大佬你们的最佳实践是什么，TiCDC 更应该和谁混部，tidb or tipd ?
我们是和pd的非leader节点混部了，怕影响到业务，pd的非leader节点反正也不提供服务。如果是leader节点，从影响范围上来看可能pd出问题影响更大，那部署到tidb节点可能更好一点，最多只影响这一个tidb节点。
混合部署建议还是用numa做下简单隔离，防止对其他组件造成过多影响。
我觉得tidb好一点，毕竟tidb是无状态的，pd可是大脑。
ticdc还是比较消耗资源的，一般pd的配置较低，和pd混合部署，大脑角色更容易崩溃，个人感觉，不管和谁混合在一起，还得看他们资源的空闲情况。资源隔离操作是需要的。
cdc有点费内存，所以和pd在一起相对来说，安全一些，
不建议混布，不给自己找不自在 
物理机的话不混部确实有点浪费，我们的3台pd配置也都是112C，512G 3T NVME的SSD，单独给一个非leader的pd用太浪费。。。
也是想到了这一点，计划和非 pd leader 进行部署。
但是在具体实践的时候，这里有一个情况，一开始部署确实是在非 Leader 节点上，但是pd leader是有可能漂移的，如果哪天漂移到TiCDC的那台机器上，这种情况如何应对，再手动介入去把 Leader transfer 走？
都知道不应该混部，都知道有风险，但是还是无可奈何花落去。
一边是有业务需求
另一边是有充足资源剩余：512GB 的内存，112 CPU 给一个非 Leader 的pd 独用，太浪费了。。。。
嗯，可以手动切走，之前也特意问过官方除非是一些极端情况，正常pd切换出现的概率还是很小的
拆分一下，不管通过是虚拟化，还是cgroup 的方式隔离下，这样会好点
但是 IO 的隔离会比较难，出现冲突的时候，就会比较被动了
IO的问题，pd 和 cdc 分别使用不同的SSD，可以隔离IO资源。
机器数量不好申请增加，硬盘这块倒是相对宽松可以申请的
pd看负载，一般pd节点需要资源不多
那就用一台机器，cpu 和 内存给足，disk io 分开，通过 numa 和 cgroup 的方式隔离
https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment
- 设置 PD 的优先级，为了避免出现跨区域 AZ 的 PD 成为 Leader，可以将本区域 AZ 的 PD 优先级调高（数字越大，优先级越高），将跨区域的 PD 优先级调低。
member leader_priority PD-10 5 member leader_priority PD-11 5 member leader_priority PD-12 5 member leader_priority PD-13 5 member leader_priority PD-14 1
可以参考这个文档，给pd设置优先级，常用的优先级最高，备用的一个优先级次高，大部分时间只负责投票的优先级最低。
这种情况下哪怕优先级最高pd1的挂了，只要pd1再起来，leader也会自动切回到pd1上去。
缺点当然也有，就是如果pd1快速重启一次，等于要在短时间内切换2次pd leader。反而造成不必要的抖动。还有就是在设置了优先级的情况下，人为切换pd leader也会很快切回去，如果没注意可能会有点奇怪。
可以自己权衡是否要这么做。
将 TiCDC 与 TiDB 集群混合可能是最合适的，以确保 TiDB 主服务器和从服务器之间的实时同步
调整pd leader 优先级，缺点确实很明显，容易二次影响集群。不过如果有3台pd机器，只部署2个TiCDC的情况下，可以只把TiCDC和两个非Leader的pd混部，另一个pd独享机器，这个时候可以设置它的优先级最高。
所以，这个也是一个不错的思路，感谢分享。
兄弟你想表达的是啥，看不明白你前后表述的语义
从库资源怎么样，一般从库压力都比较小的，可以尝试吧cdc混部到从库服务器上·，我的cdc是和从库的tidb节点部署在一起的。