你的问题是修改密码会不会同步到下游？

大过年的加班加点好不容易开发完号称很紧急的需求，业务一个电话：领导说不上了

不求全部带走，只求曾经拥有

IP:端口，你少写了端口了。 可以tiup cluster display 查看

@ CuteRay 说的对，tiup playground 默认只能127连，指定host就行了。

我记得遇到过的，tidb server OOM重启了，客户端就是会报这个错啊。

OOM了把，去看看各个组件启动时间。

没这说法

这个也算不上啥安全隐患吧。Oracle 备份也不用输密码啊，默认认为你能登录到操作系统就是可信任用户了

股票走势分析 预测买卖点

我修改过DB的数据目录，先缩容再扩容。 你这里只有一个worker节点，那就先扩容再缩容。但是端口就不一样了。如果在意的话再折腾一遍。

不会是.tiup下面的内容被手动清理过了吧？ 或者你这台就不是中控机？ 看看这个目录下有文件夹吗？ /home/sunbox/.tiup/storage/cluster/clusters/

GPT这太6了吧。

这还不简单吗？加个条件过来下。 SELECT DISTINCT CONCAT(TABLE_SCHEMA,'.',TABLE_NAME) FROM information_schema.PARTITIONS t WHERE TABLE_SCHEMA NOT IN ('INFORMATION_SCHEMA','mysql','sys','PERFORMANCE_SCHEMA','METRICS_SCHEMA') AND partition_name IS NOT NULL;

应该是老师口误了，以文档为准。可以测试下就知道了。聚簇表和非聚簇表还不太一样。

不应该是select tidb_version()吗？

得找到hint没了的原因，正常肯定不会的

除了扩容，如果gc时间设置比较长的话，临时改短也是一种应急的办法。 gc时间设置太长，就即使你drop或truncate表也不会马上释放空间。之前遇到过这个问题。。。

其实你可以认为节点状态ok扩容就完成了。tiup cluster display 看状态。 后面的数据均衡跟扩容没啥关系了，后台job，不扩容也会存在数据均衡的。