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

握手协议异常,网络正常吗?
你这是测试环境还是生产,业务访问是否正常,只有一个tiki 是这样报错还是全部都是,其他组件有没有异常日志,集群组件的grata a 的监控信息如何
都去排查一下,整理下集群的现状,不然不好分析问题
集群有状态的tikv和pd都正确起来了,唯独无状态的tidb没有起来。不太像是集群内部的问题,更像是外部网络配置的问题
确认一下tidb网络连通情况或者端口访问问题,机房断电重启后不确定是不是有防火墙或者网络设置内容有变更
请查看一下spark 提交作业的集群机器,去访问tipd集群的网络是否正常
应该要尽量避免让数据库做隐式转换,用不到索引,效率低下而且容易出现各种各样的问题
如果要备份,可以使用BR物理备份工具或者逻辑备份工具dumpling 。
如果数据量不大,比如表在千万行以下可以考虑逻辑备份;如果数据量很大,上亿行、TB级别,建议使用物理备份。
可以到问题专区提一个issue ,如果真的是有功能上的优化点后续应该可以得到优化
你到论坛里搜一搜,集群读写变慢应该怎么排查和处理,会有很多相关内容,应该有你想要的东西的
这个命令是可以执行。
但是记得是导出数据到tidb-server所在节点的机器上的,而不是客户端所在机器的目录
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独享机器,这个时候可以设置它的优先级最高。
所以,这个也是一个不错的思路,感谢分享。