create table select 语法是不支持的，不过可以参考上面这位大佬的方式绕过。 这个语法之所以不支持，有一方面的考虑是分布式大事务处理的效率问题，而且除了比较小的表外，稍微大一点的表很容易出现超过事务限制的问题。 上面这个 insert into select 的方式也会有相同的问题，这个时候怎么处理呢？比较好的方式是放弃大事务的原子性和一致性，通过一些手段切分大事务变为多个小事务实现插入，这些方法之一就是用集群的非事务特性功能来实现、或者另外写脚本完成。 如果需要强烈保证事务特性，可以通过其他工具完成，比如使用dumpling+lightning导出导入、使用spark…

没有这功能。 如果你的表不大，可以试试小表缓存功能或者临时表。

已预约，期待活动多多开展

握手协议异常，网络正常吗？ 你这是测试环境还是生产，业务访问是否正常，只有一个tiki 是这样报错还是全部都是，其他组件有没有异常日志，集群组件的grata a 的监控信息如何 都去排查一下，整理下集群的现状，不然不好分析问题

集群有状态的tikv和pd都正确起来了，唯独无状态的tidb没有起来。不太像是集群内部的问题，更像是外部网络配置的问题 确认一下tidb网络连通情况或者端口访问问题，机房断电重启后不确定是不是有防火墙或者网络设置内容有变更

请查看一下spark 提交作业的集群机器，去访问tipd集群的网络是否正常

应该要尽量避免让数据库做隐式转换，用不到索引，效率低下而且容易出现各种各样的问题

如果要备份，可以使用BR物理备份工具或者逻辑备份工具dumpling 。 如果数据量不大，比如表在千万行以下可以考虑逻辑备份；如果数据量很大，上亿行、TB级别，建议使用物理备份。

可以到问题专区提一个issue ，如果真的是有功能上的优化点后续应该可以得到优化

你到论坛里搜一搜，集群读写变慢应该怎么排查和处理，会有很多相关内容，应该有你想要的东西的

这个命令是可以执行。 但是记得是导出数据到tidb-server所在节点的机器上的，而不是客户端所在机器的目录

hhh，一针见血

pd在使用过程当中带来的风险点，主要是同步延迟很大时如果有重启，它会拉取全部落后的数据重新进行排序、整合再写入下游，这个时候会消耗很多的内存和CPU。如果落后很多，由于GC safe piont 最多只能保证 24h （默认），一旦超过这个时间 GC TTL，任务会失败。 也就是，一个同步任务，它最多是有落后24小时，这个时候重启会有瞬时的 CPU 和内存冲击，大概率会影响 pd leader 。 所以不让 ticdc 同步任务落后很多，是一个关键点。这就要求管理员一收到延迟告警，就必须尽快及时处理。 如果也做好了资源隔离，总体安全还是可控的。

从库压力是相对较小的，不过由于集群之间的网络防火墙等设置，CDC虽然部署在下游，但是还是有上游集群的tiup管理的，总的来说管理起来不是很方便。 如果网络通畅无阻，部署在下游也是可以考虑的。

解决方案： 由于 pd 节点独占机器，剩余资源过多，尤其是非 Leader 的 pd 节点，几乎不用什么资源。所以建议还是 TiCDC 和 tipd 进行混部。 TiCDC 和 tipd 进行混部时，要求 TiCDC 和 pd 节点使用不同的磁盘，隔离IO，避免相互干扰。同时通过 设置numa 隔离CPU、 cgroup 隔离内存使用。在内存和CPU充足的前提下，可以保证在一台机器上部署 TiCDC 和 pd 比较安全，且可以充分利用资源，提高机器使用率。 另外，也可以对 pd 节点设置 Leader 分布的优先级，设置指定 Leader 优先选举的节点。如果有3台pd机器，只部署2个Ti…

兄弟你想表达的是啥，看不明白你前后表述的语义

调整pd leader 优先级，缺点确实很明显，容易二次影响集群。不过如果有3台pd机器，只部署2个TiCDC的情况下，可以只把TiCDC和两个非Leader的pd混部，另一个pd独享机器，这个时候可以设置它的优先级最高。 所以，这个也是一个不错的思路，感谢分享。