jiyf
jiyf
V8
2020-10-29 加入
获赞
83
回答
108
文章
17
    mysql> show create table tidb_mdl_view\G *************************** 1. row *************************** View: tidb_mdl_view Create View: CREATE ALGORITHM=UNDEFINED DEFINER=``@`` SQL SECURITY DEFINER VIEW `tidb_mdl_view` (`job_id`, `db_name`, `table_name`, `query`, `session_i…
    6 个月前
    我试了一下,把满日志的阈值改小就能打印出来了,tidb_slow_log_threshold 单位是 ms,设为1,那么所有的 sql 都能打印出来。 上面 wd0517 提到的 tidb_current_ts 也很好用,只要显式的开启事务就行: ··· begin; show variables like “tidb_current_ts”; exec other_sql; ··· TIDB 里,同一个事务快照读,都是用的同一个开始时间戳。
    8 个月前
    从 ticdc 中获取的应该是准确的。 只读事务,只有开始时间戳,没有提交时间戳 好像是没有查询接口直接获取事务时间戳,只读事务的更不可能。但是有个骚操作看着有可行性,就是 tidb 的慢日志会打印出来 Txn_start_ts,这个应该就是你要的事务开始时间戳。 那就想办法把慢日志打印出来,比如开启慢日志后,把设置慢日志的阈值足够小,让其输出慢日志,或者就改下源码,让它不管什么情况都打印出来,能改 ticdc,稍微改下 tidb 的应该也不难。
    8 个月前
    // number of retries to make of operations. maxRetries = 7 // max number of retries when meets error maxErrorRetries = 3 func defaultS3Retryer() request.Retryer { return retryerWithLog{ DefaultRetryer: client.DefaultRetryer{ NumMaxRetries: ma…
    1 年前
    port Using the “port” parameter, it becomes possible to use a different port to send health-checks. On some servers, it may be desirable to dedicate a port to a specific component able to perform complex tests which are more suitable to health-checks than the application. It is common to run a sim…
    1 年前
    你发的这个备份原理,就是我上面写的这个意思。参考 2、3、4、5。 参考上面的 5,只需要备份一个副本的数据,如果每个 tikv 都物理备份,那就备份了多个副本数据 TiDB的体系,可能没有你说的这样的合适的工具,或者说现在还没开发出来,你说的那个工具是基于mysql体系的myrocks引擎,跟tikv使用rocksdb是不一样的。
    2 年前
    Br 就是物理备份,逻辑备份是指通过 tidb server 以库表的形式导出数据,例如使用 dumpling 工具。 Br 是通过 tikv 扫描当前实例上 region leader 的 key-value 数据,直接生成 rocksdb 的 sst 文件。 Br 备份时,为了获取一致性备份,会有个 [startTs, endTs), 基于 tidb 的 mvcc,也就是说会把扫描出来的,但是不在范围内的版本给过滤掉。 恢复时候的 rewirte key,那是因为 key 包含 tableId、indexId 信息,在恢复的表上,tableId、indexId 可能变化了,通过 rewr…
    2 年前
    之前看 tidb gc 代码时候也有为啥需要两次调用 UnsafeDestroyRange 的疑问: 1. 第一次是按照 safepoint 执行 UnsafeDestroyRange 2. 第二次是在 safepoint 24 小时之后 这个 rfc 有解释为什么第一次不能完全清理完成: And why do we need to check it one more time after 24 hours? After deleting the range the first time, if coincidentally PD is trying to move a Regio…
    2 年前
    mysql是把text字段单独存储的,这一点tidb没有采取这种方式,tidb应该不会有这种性能差异。
    2 年前
    varchar和text类型之间当然是能用varchar就用varchar了,只有varchar实在满足不了text,才会考虑后者,这个跟mysql使用的选择一致吧。在tidb上,编码没有大的区别,存储也没有,都是编码在行记录的value里。
    2 年前
    你这里使用的版本 v5.2.2,在这个版本之前有个 alter table modify column 的 bug,会导致数据乱码: https://github.com/pingcap/tidb/pull/31070 这个 pr 被 merge 进去的时间是 2022 年 4 月 12 号,你可以检查下你版本的时间: [bin]$ ./tidb-server -V 如果时间早于 4 月 12 号,那么恭喜你,很可能你遇到这个 bug 了。 这个 bug 的触发条件是并发执行 alter table modify column,你可以通过命令检查下 ddl 有没有被重复(并发)执行: …
    2 年前
    这里执行计划,那个 TopN_13 算子如果改为带有 keep order true 的 limit 算子就好了: limit 走 updatetime 索引 keep order true,扫出来第一个(满足limit m, n) TopN_7 对各个分区子表(各个分区)返回的 limit 结果,进行一个 topN 计算返回数据 那这个问题就稍微麻烦,如果有这种 order by limit m, n 查询的强需求,还真没有好的查询方法。 或者试着加范围查询,例如 where updatetime > “xx” and updatetime < “xxx” order by upda…
    2 年前
    上面表格列出来的应该是QPS吧,QPS反映的是吞吐量,你都是固定用32线程测的,吞吐量比较稳定是预期行为,你试着把线程数加大看看效果。 如果真是按照 32 线程来测试,根据上面的结果大致计算单个查询的平均时延信息: 读: 1000 ms / (89603 / 32) = 0.357ms 写: 1000 ms / (22392 / 32) = 1.429ms 读写:1000 ms / (42346 / 32) = 0.755ms 对于这样的时延,说明集群处理的非常之快了,目前压测线程数不够。 还有就是对于读压测,很耗 tidb 资源,如果 tidb 压力较大,加 tikv 确实不…
    2 年前
    看着更像是 TiDB 对于分区表下 order by idx_col limit m, n 执行计划太差的问题。 当前的执行计划,是对每个分区计算出 topN 后,把各个分区的数据汇总计算 topN,得到的结果应当是正确的,但是没有用好索引的本身有序性。 因为当前排序的列是主键列 dt,理想的执行计划应该是按照这样的逻辑执行: 分区键是 dt,那么各个分区之间,基于 dt 有序,分区 p1 内的 dt 值都小于分区 p2 的 dt 值 分区内 dt 是索引(主键索引),那么按照 dt 的索引,分区内 dt 是有序的 基于以上的有序性,按照顺序扫描分区表,对于分区表内部,使用 dt 的…
    2 年前
    total_process_keys: 100, total_keys: 4875306766 这里两个值差别很大,要么就是 gc 问题,要么就是版本还多。 你说执行 select name from tb where I_ID >= 1000 order by id asc limit 1 比较慢耗时是多少? 这里 limit 是 1, 1000 代表上一个查出来的 I_ID.
    2 年前
    如果改为执行 select name from tb where I_ID >= 1000 order by id asc limit 1 会慢吗? 完整的 analyze 执行计划看看 processed keys 以及 Total Keys? 这里说删除不一定是 delete from tb where I_ID < k 这种,删除“旧数据”,较大概率删除 I_ID 较小的数据记录都可能造成这种情况。
    2 年前