正常情况下集群是需要配置时钟同步的，但运维过程中难免出现时钟跳变情况，想了解下tikv对系统时间的依赖性。
测试了下，人为设置系统时间，往前或往后，似乎对请求没有影响，请大佬帮忙理解下。
补充：当前使用的是RawAPI
2 个赞
我只测试过prometheus会有问题，可能查不到某些数据
嗯嗯，貌似没有看到集群对系统时间要求的官方说明，看到会有一些“系统时间跳变的”错误日志，但看当时的读写都没报错。
我觉得在特定情况还是有可能出现问题的。毕竟tikv内部会存时间戳的，写入密集的时候，可能会影响数据正常写入。
嗯嗯，看看有没大佬回答下
往前还是往后？想了一下，个人感觉，往后可能影响不大，如果是往前跳变，TiDB是依赖snapshot的，会不会写不进数据？
我测试的时候往前往后都设置过，没见集群报错
1 个赞
TSO 是时间标签， 除了 系统硬件时钟外，还有逻辑时钟
基本上就不会重复了
TSO 是单调性服务，基本上只会往前
人为往后调拨物理时间，只会让 TSO 小于 之前的，
在 tidb 中，因为事务有TSO 依赖，这样的数据会认为是旧版本的数据，不会允许提交
但是你直接用了 tikv，没有这种依赖的传递要求，写入的数据都采用的put，只不过是增加了很多旧的版本…
2 个赞
RawAPI，我看了这几个单词为啥没反应是直接用了tikv，还是不熟悉啊，
我们用的是raw_put,raw_get这种请求，看起来不依赖时间，只依赖执行的先后顺序
我们存储的比较简单，不需要太复杂的操作，所以我们用了raw api，不走事务
有个事，我很好奇，你们有没有对比过cassandra和tikv，为啥当时用的tikv做的kv的库？
PD 在 2.1 版本中修复了时间回退导致分配更小 TSO 的问题， TiDB 2.1 RC1 Release Notes | PingCAP Docs
从 2.1 版本开始，PD 分配的 TSO 是递增的，不会由于系统时间偏移导致回退，TSO 由物理时间和 18bit 的逻辑时间构成，当 PD 检测到物理时间回退时，会保持之前已分配的最新 TSO 的物理时间部分不变，递增逻辑时间的方式来分配新的 TSO，当 18bit 逻辑时间用光之后，会在物理时间上 +1ms，继续以递增逻辑时间的方式分配 TSO。当 PD 检测到当前物理时间已经超过最新的 TSO 中的物理时间时，会重新转为系统物理时间+逻辑时间的分配方式。
1 个赞
@Gin_，您这里说的是PD的TSO分配。
对于 kv与Tidb的GC处理是否是根据调整的主机系统时间来处理呢？
另外对于表中的currenttimestamp，now()等这种缺省值，应该取的是当前主机的系统时间吧。
还要系统日志，primetheus等记录的时间也是当前主机的系统时间吧。
线上出过你说的问题，当时系统时间超了300多秒，报9005异常
请问: 9005异常，具体是什么报错信息呢？
GC 工作基于 TSO，不受主机时间限制。
now(), sysdate(), current_timestamp() 等取值来自 tidb-server 所在主机，时间日期类型字段使用 current_timestamp 作为默认值的时候，取值也来自 tidb-server 主机。
1 个赞
所有组件的诊断日志，还有 Prometheus 中数据的时间都是取值于所在主机。
会提示以下内容：
{
“code”: 9005,
“error”: “Region is unavailable”,
“description”: “A certain Raft Group is not available, such as the number of replicas is not enough.\
This error usually occurs when the TiKV server is busy or the TiKV node is down.”,
“workaround”: “Check the status, monitoring data and log of the TiKV server.”
}
也就是说这个错误会在TiKV 繁忙或节点宕机时发生
这里有详细的定义
https://github.com/pingcap/tidb/blob/master/errors.toml#L1854
这里是相关的提案
https://github.com/pingcap/tidb/blob/master/docs/design/2020-05-08-standardize-error-codes-and-messages.md
2 个赞