search

cosven / cosven.github.io

个人零碎笔记，博客草稿，阅读笔记
10 stars 0 forks source link

每周阅读 #62

Open cosven opened 5 years ago

cosven commented 5 years ago

2019-08 月之前

整理成文：http://cosven.me/blogs/100

cosven commented 5 years ago

2019-08-05 ~ 2019-08-11

整理成文：http://cosven.me/blogs/98

cosven commented 5 years ago

2019-08-12 ~ 2019-08-25

整理成文：http://cosven.me/blogs/99

cosven commented 4 years ago

2019-10-14 ~ 2019-10-30

整理成文：http://cosven.me/blogs/104

cosven commented 4 years ago

2019-10-30 ~ 2019-11-01

排查 TiDB 卡主的问题

[tidb@172.xx.xx.xx ~]$ cat /proc/18097/limits
Limit                     Soft Limit           Hard Limit           Units
Max open files            1048576              1048576              files

[tidb@172.xx.xx.xx ~]$ sudo lsof -p 18097 | wc -l
293955
[tidb@172.xx.xx.xx ~]$ sudo lsof -p 18097 | egrep "TCP|UDP" | wc -l
293576

[tidb@172.xx.xx.xx ~]$ sudo lsof -p 18097 -i | wc -l
lsof: no pwd entry for UID 65534
lsof: no pwd entry for UID 65534
295312

~ > k exec -it targetdb-tidb-tikv-1 -- lsof | wc -l
  295757

Paper Reading: Simple Testing Can Prevent Most Critical Failures

cosven commented 4 years ago

2019-12-08 ~ 2019-12-30

整理成文：http://cosven.me/blogs/105

cosven commented 4 years ago

2020-03-16 ~ 2020-03-20

TiKV Percolator 相关

GC 怎样判断一个 secondary key 是应该提交还是回滚呢？

回答：看代码应该是会出现 primary key 不存在的情况。但不知道为啥？ 不存在时，有可能当成 rollback，也有可能报错，TiDB 端可以传参到 TiKV。 相关代码：ResolveLockRequest，CheckTxnStatus。

几个 TODO

参考资料：

https://pingcap.com/docs-cn/stable/reference/garbage-collection/overview/#resolve-locks

Resolve Locks 这一步的任务即对 safe point 之前的锁进行回滚或提交，取决于其 Primary 是否被提交。如果一个 Primary 锁也残留了下来，那么该事务应当视为超时并进行回滚。这一步是必不可少的，因为如果其 Primary 的 Write 记录由于太老而被 GC 清除掉了，那么就再也无法知道该事务是否成功。如果该事务存在残留的 Secondary 锁，那么也无法知道它应当被回滚还是提交，也就无法保证一致性。

https://pingcap.com/blog-cn/tidb-transaction-model/

另外，在实际实现的过程中还会遇到一个问题，当 gc 一个 key 时发现 meta 中有锁（可能是由于清除 secondary lock 时客户端崩溃或者其他原因），你并不能简单删除之，因为如果这个 key 中的锁是 secondary lock，在 gc 进程去查看这个锁对应的 primary key 的对应版本是提交还是回滚时，如果 primary key 的那个版本已经被 gc 删除掉了，对于 gc 进程来说就没有办法确定该事务到底是提交还是回滚，可能出现数据误删的情况。TiKV 通过对事务的 primary key 的 meta version 进行一个特殊的标记，由于没有集中事务管理器的存在，判断一个事务的执行状态只有 primary key 的 meta 中有记录，所以在 gc 时会绕过这些 primary key 的 version 解决了这个问题，保证了数据的安全。

事务隔离级别 Read Committed vs Consistency Read

？

cosven commented 3 years ago

2020-10-12 ~ 2020-10-16

  1. 通过 CLONE_NEWNS
  2. 进入指定进程的 namespace，在里面创建一个 fuse，并 mount 上
  3. 只有该进程能看到这个挂载点

具体的几个问题

  1. __chaosfs__test__ 目录是怎么回事？ 大概意思是 move mount 可以避免之前的 fd 使用终断
  2. 真实的数据保存在哪里呢？ 透传给了系统
  3. 如果只有指定进程能看到这些数据，那本地如果方便的确认它是否真的生效了呢？ docker 共用一个 namespace

Alpine 镜像问题

mkdir /lib64
ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2
cosven commented 3 years ago

2020-10-19 ~ 2020-10-23

有趣的字符串

常用 K8s 组件维护

cosven commented 3 years ago

2020-12-11

RocksDB Comapction 流程 - 学习

Status DBImpl::CompactRange(const CompactRangeOptions& options,
                            ColumnFamilyHandle* column_family,
                            const Slice* begin, const Slice* end)
  1. 先检查 memtable 中是否和当前 compaction range 有重叠，如果有重叠，则需要 flush
  2. 下