没太看明白，比如一台机器有一个内网地址192.168.0.1，有一个基础网络IP 10.0.0.1 ，那topology里都用192.168的内网地址来部署就行了，这样集群内部通讯使用独立的交换机性能更好，10的地址是用来人工登录服务器的，现在问题是什么呢

导出成csv，用 LOAD DATA导入

【PingCAP 10周年祝福语 】: 相约下一个十周年！ 【你对TiDB 印象最深刻的事情】: tiup和tiflash的上线

数据库一般没这种参数吧，毕竟重启对生产系统影响也挺大的，我感觉这种主要得查查是什么原因导致占用这么多内存，该优化SQL优化SQL，该扩容扩容，另外我看tidb和tikv是混部的，这种也容易相互影响

这个参数不会让tidb重启，只会终止最耗内存的sql，tidb节点重启一般都是操作系统OOM把tidb进程kill掉 https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage/

16G确实太小了，官方建议的生产环境配置是64G，我们这边ticdc 平时内存也得用10G左右，高峰能到20G以上

8.0以后的版本才有的 [image] https://docs.pingcap.com/zh/tidb/v8.1/release-8.1.0/

看文档tidb-jdbc对性能上没什么特别的提升，至于性能瓶颈和优化分布式场景这里主要看tidb节点上层有没有负载均衡吧 [image]

是这个吧

都是私有云，公有云应该不会考虑，tidb用的物理机 【使用的 TiDB 版本】 6.1.6 【节点数量有多少】 tikv 32节点

我看开了多个帖子，直接这个帖子说吧，tiproxy里基于地理位置的负载均衡可以让亚洲的tiproxy连接亚洲的tidb，欧洲的tiproxy连接欧洲的tiproxy，如果想同时用两边的tiproxy并且两边同时要高可用，那你应该搞4个tiproxy，亚洲2个，欧洲两个，亚洲的应用连亚洲的tiproxy的虚IP，欧洲的应用连欧洲tiproxy的虚IP

虚ip不能和其他ip冲突，找公司网络或者基础设施的同事申请一个吧

不用额外的机器，预留一个虚拟IP配进来就可以了

是的，不过需要把 policy设置为location提升策略的优先级

配置虚拟 IP ha.virtual-ip 和 ha.interface，连接vip就行，负载一般不会再tiproxy上面，配置要求不高，多节点主要还是为了高可用

一般这种用做灾备吧，我们是2套tidb集群，1:1配置，用ticdc做同步

逻辑上属于集群，因为各组件（PD/TiDB/TiKV/TiFlash）以独立进程运行而且通过网络协议通信（即使在同一台机器），遵循 TiDB 分布式架构的交互逻辑，所以称为集群没什么问题。但是没有高可用，混合部署也会资源争抢，除了测试一般不这么部署。

还是用centos7.9

如果是虚拟机或者云主机可以忽略，调整不了cpu频率