本地盘的pv就是这样的，本地盘没法飘。只能删了pvc重建。
坏一台物理机可以直接删了pvc删了pod重建。
你说的其他的可以的是不用本地盘吗？具体你贴的yaml文件比较长,着急下班先不看了。一般来说我们绑定本地盘的机器坏掉就这样操作的：删pvc、删tikv、等待节点补上。
2 天前
场景描述：
有些情况下，join比较耗时，可以用这个提前join好放那里。每次查询不需要临时join，相当于join结果的缓存，这是能节省很多计算资源的。
痛点描述：
就是写少读多的业务需要频繁的计算，浪费不少资源
功能描述：
join、复杂查询
使用意向：
自动更新，如果需要手动更新，那业务还得改，不符合tidb的风格。如果这个是个临时1年内的方案，那完全可以忍一忍，忍到自动更新出来。因为业务上线就得跑很久。
2 天前
下面是cache的代码和用cache的代码，逻辑很清晰。
https://github.com/pingcap/tidb/blob/master/pkg/store/copr/coprocessor_cache.go
https://github.com/pingcap/tidb/blob/master/pkg/store/copr/coprocessor.go#L1698
4 天前
不是整个region的数据都缓存上来，是针对一次扫描的结果缓存起来。这个我看过代码，没疑问。
至于缓存失效，毕竟几万个region，也不是每次都所有更新的。
另外每次查询都可以看到coprocessor的cache命中情况。explain看下就行
4 天前
没关吧，我看默认是1G缓存啊。哪个版本关了？我一直用着很好的啊。
tikv-client.copr-cache 从 v4.0.0 版本开始引入
本部分介绍 Coprocessor Cache 相关的配置项。
capacity-mb
缓存的总数据量大小。当缓存空间满时，旧缓存条目将被逐出。值为 0.0 时表示关闭 Coprocessor Cache。
默认值：1000.0
单位：MB
类型：Float
4 天前
你说的是tidb的那个coprocessor cache吗？
如果是coprocessor cache 是这样工作的：
tidb的所有查询会以 region 为单位拆分开。假如说需要扫描一批数据，会下推到 扫描各个region的一批数据，那对应的过滤条件走完后就扫描到了这些数据。
这些结果如果超出了缓存从阈值，就缓存起来，下次直接去对应的reigon读取一下apply index，如果region没有过变更，cache就有效，可以继续用。否则就失效，从region中读取数据。
4 天前
tiup 不熟，这个错误是 tiup升级tikv的时候，要获取tikv上还有没有leader，为了平滑升级。
你完全可以通过 pd-ctl store 看看。
手动操作的逻辑是：
scheduler add evict_leader_scheduler xxx (要升级的tikv)
然后 tikv重启替换新版。然后再执行 scheduler remove evict_leader_scheduler
然后再执行下一个。
你看看对你有没有帮助吧。tiup命令我是不清楚。
5 天前
那个sql在疯狂扫描，当然会拖慢集群。你一开始贴了个点查的，实际上不是点查的事儿。
你把那个慢的sql
explain 下，看看执行计划，该用上索引就用索引。
5 天前
看这个输出，time 85.2ms ，虽说对于点查也不算快，但是没有慢到3分钟的情况，难道客户端返回用了很久？你从客户端ping一下tidb server的地址看看延迟。
5 天前
CREATE TABLE t (a INT PRIMARY KEY, b INT);
INSERT INTO t VALUES (1, 1);
INSERT INTO t VALUES (2, 2);
BEGIN;
UPDATE t SET a = 3 WHERE a = 1;
UPDATE t SET a = 1 WHERE a = 2;
UPDATE t SET a = 2 WHERE a = 3;
COMMIT;
在上述示例中，通过执行三条 SQL 语句对两行数据的主键进行交换，但 TiCDC 只会接收到两条 UPDATE 变更事件，即将主键 a 从 1 变更为 2，将主键 a …
5 天前
这个顺序如果不对的话，换成delete+replace结果也是错的吧。
这样做的目的是为了降低下游的压力。
batch默认是100.worker count 也改成了64.
其实我是想实现这种效果：
如果压力小，就攒一攒batch，一秒钟给下游执行一次就行。
如果压力大，就在batch满的情况下，多用几个worker发送。
现在的情况好像是 worker有空闲的就不batch了。这个顺序能调整吗？
6 天前
// replace and delete are naturally reentrant.
// use delete+replace to represent update can make update reentrant.
// but there are no ways to make update idempotent,
这里面说 delete+replace 是为了让update 幂等，直接把 update 换成 replace into不能做到幂等吗？我这个不太理解。
另外：values 压缩这个事儿，有没有办法优先压缩values，比如…
6 天前
建议表妹改改论坛的回帖给分规则，要么就别处理正儿八经的灌水帖子了。否则隐藏的刷分帖子反而影响更坏。你看你都被误导了，那其他人岂不是更容易被误导吗。我前几天搜索dm的问题，就搜到了一些一本正经胡说八道的答案，如果没有一点判断力，跟着一本正经胡说八道的方案去做，浪费时间浪费精力。
@Billmay表妹
6 天前
没有更多内容了