Add document of GC #679

MyonKeminta · 2018-04-18T07:22:13Z

And moved some description of GC from history-read.md to the new separated file

MyonKeminta · 2018-04-18T07:22:37Z

@zhangjinpeng1987 @shenli PTAL

shenli · 2018-04-18T07:25:51Z

LGTM
/cc @queenypingcap

QueenyJin · 2018-04-18T08:41:35Z

@lilin90

lilin90 · 2018-04-18T09:21:33Z

op-guide/gc.md

+
+TiDB 采用 MVCC 的方式来进行并发控制。当对数据进行更新或者删除时，原有的数据不会被立刻删除，而是会被保留一段时间，并且在这段时间内这些旧数据仍然可以被读取。这使得写入操作和读取操作不必互斥，并使读取历史数据成为可能。
+
+存在超过一定时间并且不再使用的版本会被清理，否则它们将始终占用硬盘空间，并对性能产生负面影响。我们使用一个垃圾回收 (GC) 机制来清理这些旧数据。


"我们" -> "TiDB" + a whitespace

lilin90 · 2018-04-18T09:26:18Z

op-guide/gc.md

+
+## 工作方式
+
+TiDB 会周期性地进行 GC 。每个 TiDB Server 启动后都会在后台运行一个 gc_worker ，每个集群中会有其中一个 gc_worker 被选为 leader ， leader 负责维护 GC 的状态并向所有的 TiKV region leader 发送 GC 命令。


Please delete the extra whitespaces between English characters and Chinese punctuation:

After "GC"

After "gc_worker"

After the 1st "leader"

Before the 2nd "leader"

"region" -> "Region"

lilin90 · 2018-04-18T09:27:23Z

op-guide/gc.md

+10 rows in set (0.02 sec)
+```
+
+其中， `tikv_gc_run_interval` ， `tikv_gc_life_time` ， `tikv_gc_concurrency` 这三条记录可以手动配置。其余带有 `tikv_gc` 前缀的记录为当前运行状态的记录， TiDB 会自动更新这些记录，请不要手动修改它们。


Ditto. Delete 6 extra whitespaces.

"请不要手动修改它们" -> "勿手动修改"

lilin90 · 2018-04-18T09:30:52Z

op-guide/gc.md

+
+其中， `tikv_gc_run_interval` ， `tikv_gc_life_time` ， `tikv_gc_concurrency` 这三条记录可以手动配置。其余带有 `tikv_gc` 前缀的记录为当前运行状态的记录， TiDB 会自动更新这些记录，请不要手动修改它们。
+
+`tikv_gc_run_interval` 是 GC 运行时间间隔。 `tikv_gc_life_time` 是历史版本的保留时间，每次进行 GC 时，会清理超过该时间的历史数据。这两项配置不应低于 10 分钟，默认值均为 10 分钟。可以直接用 SQL 修改其数值来进行配置。比如，如果我们想保留一天以内的历史数据，就可以执行：


Delete one extra whitespace

Delete "我们"

lilin90 · 2018-04-18T09:36:25Z

op-guide/gc.md

+
+1. 随着版本的不断增多，数据占用的磁盘空间会随之增加。
+2. 大量的历史版本会在一定程度上导致查询变慢，主要影响范围查询（如 `select count(*) from t`）。
+3. 如果在运行中突然将 `tikv_gc_life_time` 配置调小，可能会导致短时间内大量历史数据被删除，造成 I/O 负担。


Please use the bulleted list, because the 3 items above have no necessary logic in order. Usually, we use the numbered list for steps.

lilin90 · 2018-04-18T09:36:43Z

op-guide/gc.md

+2. 大量的历史版本会在一定程度上导致查询变慢，主要影响范围查询（如 `select count(*) from t`）。
+3. 如果在运行中突然将 `tikv_gc_life_time` 配置调小，可能会导致短时间内大量历史数据被删除，造成 I/O 负担。
+
+`tikv_gc_concurrency` 是运行 GC 的并发数。默认该选项为 1 ，即单线程运行，逐个向每个涉及的 region 发起请求并等待响应。可以增加该数值以改善性能，最大不能超过 128 。


region -> Region

lilin90 · 2018-04-18T09:48:17Z

op-guide/gc.md

+
+### 1. Resolve Locks
+
+TiDB 的事务是基于 Google Percolator 模型实现的，事务的提交是一个两阶段提交的过程。第一阶段完成时，所有涉及的 key 会加上一个锁，其中一个锁会被设定为 Primary ，其余的锁（Secondary）则会指向 Primary ；第二阶段会将 Primary 锁所在的 key 加上一个 Write 记录，并去除锁。这里的 Write 记录就是历史上对该 key 进行写入或删除，或者该 key 上发生事务回滚的记录。 Primary 锁被替换为何种 Write 记录标志着该事务提交成功与否。接下来，所有 Secondary 锁也会被依次替换。如果替换这些 Secondary 锁的线程死掉了，锁就残留了下来。在 GC 过程中如果遇到了时间戳在 safe point 之前的这样的锁，就会根据该事务提交与否，将该锁也替换成 Write 记录。


Ditto. Delete extra whitespaces.

lilin90 · 2018-04-18T09:51:23Z

op-guide/gc.md

+
+TiDB 的事务是基于 Google Percolator 模型实现的，事务的提交是一个两阶段提交的过程。第一阶段完成时，所有涉及的 key 会加上一个锁，其中一个锁会被设定为 Primary ，其余的锁（Secondary）则会指向 Primary ；第二阶段会将 Primary 锁所在的 key 加上一个 Write 记录，并去除锁。这里的 Write 记录就是历史上对该 key 进行写入或删除，或者该 key 上发生事务回滚的记录。 Primary 锁被替换为何种 Write 记录标志着该事务提交成功与否。接下来，所有 Secondary 锁也会被依次替换。如果替换这些 Secondary 锁的线程死掉了，锁就残留了下来。在 GC 过程中如果遇到了时间戳在 safe point 之前的这样的锁，就会根据该事务提交与否，将该锁也替换成 Write 记录。
+
+这一步是必不可少的，因为如果它的 Primary 的 Write 记录被 GC 清除掉了，我们就再也不知道这个事务到底是成功了还是没成功，于是也就无法保证一致性。


Change to:

这一步是必须的，因为如果其 Primary 的 Write 记录被 GC 清除掉了，就再也无法知道该事务是否成功，也就难以保证一致性。

lilin90 · 2018-04-18T09:52:29Z

op-guide/history-read.md

-1. 随着版本的不断增多，数据占用的磁盘空间会随之增加。
-2. 大量的历史版本会在一定程度上导致查询变慢，主要影响范围查询（`select count(*) from t`）。
-3. 如果在运行中突然将 `tikv_gc_life_time` 配置调小，可能会导致大量历史数据被删除，造成 I/O 负担。
+这里我们需要重点关注的是 `tikv_gc_life_time` 和 `tikv_gc_safe_point` 这条。 `tikv_gc_life_time` 用于配置历史版本保留时间，可以手动修改； `tikv_gc_safe_point` 记录了当前的 safePoint，用户可以安全地使用大于 safePoint 的时间戳创建 snapshot 读取历史版本。safePoint 在每次 GC 开始运行时自动更新。


Ditto. Delete extra whitespaces.

lilin90

LGTM

zhangjinpeng87

LGTM

MyonKeminta added 2 commits April 18, 2018 15:02

Add GC document

7c8a773

Remove duplicated content from history-read.md

f2d6c18

Fix the code content

df43045

lilin90 reviewed Apr 18, 2018

View reviewed changes

MyonKeminta added 2 commits April 18, 2018 18:12

"Address comments"

8bda5a4

Address comments

2b2bd0a

lilin90 reviewed Apr 18, 2018

View reviewed changes

zhangjinpeng87 approved these changes Apr 20, 2018

View reviewed changes

zhangjinpeng87 merged commit 7134a9d into pingcap:master Apr 20, 2018

CaitinChen mentioned this pull request Apr 20, 2018

docs/op-guide: create GC document pingcap/docs#433

Merged


		TiDB 采用 MVCC 的方式来进行并发控制。当对数据进行更新或者删除时，原有的数据不会被立刻删除，而是会被保留一段时间，并且在这段时间内这些旧数据仍然可以被读取。这使得写入操作和读取操作不必互斥，并使读取历史数据成为可能。

		存在超过一定时间并且不再使用的版本会被清理，否则它们将始终占用硬盘空间，并对性能产生负面影响。我们使用一个垃圾回收 (GC) 机制来清理这些旧数据。


		## 工作方式

		TiDB 会周期性地进行 GC 。每个 TiDB Server 启动后都会在后台运行一个 gc_worker ，每个集群中会有其中一个 gc_worker 被选为 leader ， leader 负责维护 GC 的状态并向所有的 TiKV region leader 发送 GC 命令。


		其中， `tikv_gc_run_interval` ， `tikv_gc_life_time` ， `tikv_gc_concurrency` 这三条记录可以手动配置。其余带有 `tikv_gc` 前缀的记录为当前运行状态的记录， TiDB 会自动更新这些记录，请不要手动修改它们。

		`tikv_gc_run_interval` 是 GC 运行时间间隔。 `tikv_gc_life_time` 是历史版本的保留时间，每次进行 GC 时，会清理超过该时间的历史数据。这两项配置不应低于 10 分钟，默认值均为 10 分钟。可以直接用 SQL 修改其数值来进行配置。比如，如果我们想保留一天以内的历史数据，就可以执行：


		### 1. Resolve Locks

		TiDB 的事务是基于 Google Percolator 模型实现的，事务的提交是一个两阶段提交的过程。第一阶段完成时，所有涉及的 key 会加上一个锁，其中一个锁会被设定为 Primary ，其余的锁（Secondary）则会指向 Primary ；第二阶段会将 Primary 锁所在的 key 加上一个 Write 记录，并去除锁。这里的 Write 记录就是历史上对该 key 进行写入或删除，或者该 key 上发生事务回滚的记录。 Primary 锁被替换为何种 Write 记录标志着该事务提交成功与否。接下来，所有 Secondary 锁也会被依次替换。如果替换这些 Secondary 锁的线程死掉了，锁就残留了下来。在 GC 过程中如果遇到了时间戳在 safe point 之前的这样的锁，就会根据该事务提交与否，将该锁也替换成 Write 记录。


		TiDB 的事务是基于 Google Percolator 模型实现的，事务的提交是一个两阶段提交的过程。第一阶段完成时，所有涉及的 key 会加上一个锁，其中一个锁会被设定为 Primary ，其余的锁（Secondary）则会指向 Primary ；第二阶段会将 Primary 锁所在的 key 加上一个 Write 记录，并去除锁。这里的 Write 记录就是历史上对该 key 进行写入或删除，或者该 key 上发生事务回滚的记录。 Primary 锁被替换为何种 Write 记录标志着该事务提交成功与否。接下来，所有 Secondary 锁也会被依次替换。如果替换这些 Secondary 锁的线程死掉了，锁就残留了下来。在 GC 过程中如果遇到了时间戳在 safe point 之前的这样的锁，就会根据该事务提交与否，将该锁也替换成 Write 记录。

		这一步是必不可少的，因为如果它的 Primary 的 Write 记录被 GC 清除掉了，我们就再也不知道这个事务到底是成功了还是没成功，于是也就无法保证一致性。

Add document of GC #679

Add document of GC #679

Uh oh!

Conversation

MyonKeminta commented Apr 18, 2018

Uh oh!

MyonKeminta commented Apr 18, 2018

Uh oh!

shenli commented Apr 18, 2018

Uh oh!

QueenyJin commented Apr 18, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lilin90 left a comment

Choose a reason for hiding this comment

Uh oh!

zhangjinpeng87 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants