优点： 1、实现了应用混合部署资源隔离，为区域库做准备 2、brustable能力调整符合业务逻辑，动态调整资源 3、在线ru调整在花费想象力情况下，还有很多使用业务场景 不足 1、 ru资源度量过于抽象 2、建议能够从物理资源进行分配如4c8g 3、提升io隔离能力

dr auto sync 改写为in sql模式: 3 个 Voter 副本在主 AZ，2 个 Follower 副本和 1 个 Learner 副本在从 AZ，请专家看看是否可以支持 create placement policy test_policy LEADER_CONSTRAINTS=“[+az=primary]” FOLLOWER_CONSTRAINTS=“{+az=dr:2}” LEARNER_CONSTRAINTS=“{+az=dr:1}” create database testdb placement policy=test_policy;

能聚个例子吗？哪些场景in sql 不能覆盖

想到了一个点，如果读取的时候利用mvcc确定某个读取时间点，这个情况下数据肯定的apply到rocksdb kv内，这样如果再利用readindex是不是读取效率就降低了，要等当前的index apply之后才读取到

我的理解向第二层合并后第一层就没有a了

1）可以优化：调小max-merge-region-size、 max-merge-key、patrol-region-interval 2）如果开启了ddl on table ，可以关闭这个功能。默认是关闭的

系统部署后会在tikv节点有一个临时文件，这个临时文件就是解决应急情况下tikv空间不够情况下的应急处理。

[mm] 祝新年全家身体健康，平安，快乐

请给一个提示？

哪个版本?

从上面链接看，pd tso wait （异步等TSO时间）/rpc duration（从调用开始整个个响应)。那应该是rpc duration包涵了pd tos wait 时间吧？

请求支持，点对点应答

那A这个选项scheduler pool 进行读写冲突检测是检测啥内容？

那tikv scheduler pool应该是会进行检查write cf和lock cf的冲突检查的吧？

(1)请问在tikv scheduler pool是不是会进行检查write cf和lock cf的冲突检查? (2)另外是不是还有好像还有一个快照snapshot的对比动作。检查写写冲突，如果写写冲突就回滚

没看懂啊

是不是如下情况 1）只有leader 才发送heartbeat 心跳来检查，flower 不需要发送heartbeat? 2）为啥heartbeat time interval 一定小于 min（election time out）？ 3）当heartbeatElapsed >= r.heartbeatTimeout ，心跳已经超时了，为啥还是维持leader？这种情况应该处理处理？我的理解是当leader超过heartbeatTimeout，就要进行election_time,当超过electionTimeout后其他flower 就看谁先把自己的term+1,谁就就是leader

恩，明白了，default cf 不是在dml期间写入的。是在发起commit 后写write cf

也就是说： 悲观锁模式下，在执行行dml过程中就要写入tikv default cf和lock cf信息，是吗？