嗯呢 低版本准备绑核

好的感谢

参加云数据库 TiDB 免费试用活动

看了一些案例 应该不是tidb 版本导致的。5.x 也有人遇到过，可能还是有一些大查询能绕过tidb_mem_quota_query参数设置

或者还有什么可以限制tidb server 内存使用的方式

这个咋解决呢，升级版本如何

[image] 确认是tidb 组件占用的

这是我自己的微信公众号发的文章直接复制的带水印了

还有就是可参考运维实战文章太少了，没点k8s 基础就错成本太高了

我也是在测试，性能损失那是一定的，在10-20%，主要是感觉hold 不住，需要k8s 团队配合，还有看下是否强需求吧，是考虑节约成本还是所谓的自动化，我感觉tidb 自身region 基于raft 3副本是可以完成故障转移的，因此并不是强需求，但是可以玩玩，目前准备测试环境整，玩顺了，再上线

我们这也是有固定用户，配置的免密操作，不知道密码是啥，也不敢轻易修改这个用户的密码

感谢，但是我的那张表not null 没设置默认值，同时我经过各种重建表竟然好了

现在正常了

按照官网执行的操作 alter table . set tiflash replica 0; tiup cluster scale-in --node 10.0.1.4:9000

业务反馈他操作表的顺序如下： apk_icon_sample icon字段先是text类型, 然后插入图片, 发现字段长度不够用, 然后truncate table, 然后alter改类型, 然后插数据，一会就出现tiflash问题了 我这边刚才把对应的表drop掉了，最开始怀疑是不是longblob 特殊字段问题，重新创建不包含这个字段的表，然后scale-out tiflash 组建成功，又单独创建了一个只包含longblob的字段的表，scale-out tiflash 也成功了，纳闷了…看来不是这个字段的问题，于是又重新按照原先apk_icon_sample表结构创建一遍，然后s…

我已经把check_time/add_time 字段都改成CURRENT_TIMESTAMP，现在重新扩容tiflash也会失败，错误日志一直报2022.04.06 13:59:05.853604 [ 1 ] Application: basic_string::_M_replace_aux 2022.04.06 13:59:21.359828 [ 1 ] Application: The configuration “path” is deprecated. Check [storage] section for new style. 2022.04.06 13:59:27.4806…

嗯这个是sql_mode 问题

check_time这个应该是sql_mode 的关系,但是还是不清楚为啥会报basic_string::_M_replace_aux问题

对是这个报错