看上去是这个情况 1.你访问请求的是4000端口，但haproxy监听的是3390端口，所以你的访问其实没经过haproxy，而是直接打到了tidb server； 2.由于你配置了代理透传proxy-networks指定102和103是代理，当你使用102、103这两个源地址直接连接tidb server的时候，tidb server需要看到请求侧携带真实的IP，但你并非是代理访问而是直接访问，所以不会携带真实IP，这是访问不到的原因。 解决方案也比较明确： 1.改成访问3390端口； 2.加一个proxy-protocol.fallbackable: true这个参数，即如果遇到…

想问问后续是否有解决这个场景下这个问题的计划，或者怎样提交需求。 感觉代码技术层面解决应该不会太复杂。

在我模拟复现的场景中，lightning的配置文件里 关于not-null参数： not-null是设置为false的，这是因为csv实际上来源于另一个非MySQL生态数据库，其中的NULL值需要迁移到tidb； 关于null= ‘\N’ 参数： 目前我们测试过程中，由于源端数据库导出到csv时，NULL值处理为两个连续的分隔符，也就是两个逗号,，如果null=‘\N’，则这种NULL值也无法处理导入到tidb，所以需要把null=设置为’'。 综上，这次的导入受限于源库导出的CSV，而导出的csv中是可以明确区分空字符串和NULL值的（,“”,和,），我们希望lightning也可…

这样肯定是不合理的，最后我们也是用了替换后update的方式，将’'写入到tidb。

要看现在环境的数据量，以及最终的部署架构。 一般来说单纯从没有label到配置label，应该会影响的是单个服务器多个tikv实例的数据分布，默认会在最低级别把region的副本隔离开。参照这个https://docs.pingcap.com/zh/tidb/stable/multi-data-centers-in-one-city-deployment#样例拓扑架构 其次双机房或者多机房通常会设置placement rules，将可能导致region副本数量的变动，leader的迁移调度等等，如果集群中数据量比较大，region数量很多的话，建议谨慎评估影响充分测试。

其实是可以绕过的，你用dumpling可以带时间戳导出指定表指定时间未GC的数据，然后重命名原来的表，用导出的数据再lightning导入回去

建议重点考虑行业的选择 简历部分应该想办法突出一些工作或者项目中的成果，譬如写脚本解决了些什么问题？提升了哪些工作效率？等等。

建议先验证下tiflash的IP+端口的连通性，如果TCPIP不通可以重点关注bond的配置。