add description to tables and QA

Signed-off-by: YangKeao <yangkeao@chunibyo.icu>
pingcap · Feb 16, 2023 · 0289176 · 0289176
1 parent bd416ce
commit 0289176
Show file tree

Hide file tree

Showing 4 changed files with 69 additions and 2 deletions.
diff --git a/media/ttl/delete-fast.png b/media/ttl/delete-fast.png
diff --git a/media/ttl/insert-fast.png b/media/ttl/insert-fast.png
diff --git a/media/ttl/scan-fast.png b/media/ttl/scan-fast.png
diff --git a/time-to-live.md b/time-to-live.md
@@ -160,9 +160,56 @@ TiDB 会定时采集 TTL 的运行时信息，并在 Grafana 中提供了相关
 
 同时，可以通过以下三个系统表获得 TTL 任务执行的更多信息：
 
-+ `mysql.tidb_ttl_table_status` 表中包含了所有 TTL 表的上一次执行与正在执行的 TTL 任务的信息。
++ `mysql.tidb_ttl_table_status` 表中包含了所有 TTL 表的上一次执行与正在执行的 TTL 任务的信息。以一行为例：
+
+  ```sql
+  MySQL [(none)]> select * from mysql.tidb_ttl_table_status limit 1\G;
+  *************************** 1. row ***************************
+                        table_id: 85
+                parent_table_id: 85
+                table_statistics: NULL
+                    last_job_id: 0b4a6d50-3041-4664-9516-5525ee6d9f90
+            last_job_start_time: 2023-02-15 20:43:46
+            last_job_finish_time: 2023-02-15 20:44:46
+            last_job_ttl_expire: 2023-02-15 19:43:46
+                last_job_summary: {"total_rows":4369519,"success_rows":4369519,"error_rows":0,"total_scan_task":64,"scheduled_scan_task":64,"finished_scan_task":64}
+                  current_job_id: NULL
+            current_job_owner_id: NULL
+          current_job_owner_addr: NULL
+      current_job_owner_hb_time: NULL
+          current_job_start_time: NULL
+          current_job_ttl_expire: NULL
+              current_job_state: NULL
+              current_job_status: NULL
+  current_job_status_update_time: NULL
+  1 row in set (0.040 sec)
+  ```
+
+  其中列 `table_id` 为分区表 ID，而 `parent_table_id` 为表的 ID，与 `infomation_schema.tables` 表中的 ID 对应。
+
+  列 `{last, current}_job_{start_time, finish_time, ttl_expire}` 分别描述了过去和当前 TTL 任务的开始时间、结束时间和过期时间。`last_job_summary` 列描述了上一次 TTL 任务的执行情况，包括总行数、成功行数、失败行数。
+
 + `mysql.tidb_ttl_task` 表中包含了正在执行的 TTL 子任务。单个 TTL 任务会被拆分为多个子任务，该表中记录了正在执行的这些子任务的信息。
-+ `mysql.tidb_ttl_job_history` 表中记录了 TTL 任务的执行历史。TTL 任务的历史记录将被保存 90 天。
++ `mysql.tidb_ttl_job_history` 表中记录了 TTL 任务的执行历史。TTL 任务的历史记录将被保存 90 天。以一行为例：
+  ```sql
+  MySQL [(none)]> select * from mysql.tidb_ttl_job_history limit 1\G;
+  *************************** 1. row ***************************
+            job_id: f221620c-ab84-4a28-9d24-b47ca2b5a301
+          table_id: 85
+    parent_table_id: 85
+      table_schema: test_schema
+        table_name: TestTable
+    partition_name: NULL
+        create_time: 2023-02-15 17:43:46
+        finish_time: 2023-02-15 17:45:46
+        ttl_expire: 2023-02-15 16:43:46
+      summary_text: {"total_rows":9588419,"success_rows":9588419,"error_rows":0,"total_scan_task":63,"scheduled_scan_task":63,"finished_scan_task":63}
+      expired_rows: 9588419
+      deleted_rows: 9588419
+  error_delete_rows: 0
+            status: finished
+  ```
+  其中列 `table_id` 为分区表 ID，而 `parent_table_id` 为表的 ID，与 `infomation_schema.tables` 表中的 ID 对应。`table_schema`、`table_name`、`partition_name` 分别对应表示数据库、表名、分区名。`create_time`、`finish_time`、`ttl_expire` 分别表示 TTL 任务的创建时间、结束时间和过期时间。`expired_rows` 与 `deleted_rows` 表示过期行数与成功删除的行数。
 
 ## 工具兼容性
 
@@ -176,3 +223,23 @@ TiDB 会定时采集 TTL 的运行时信息，并在 Grafana 中提供了相关
 * 具有 TTL 属性的表不支持作为外键约束的主表被其他表引用。
 * 不保证所有过期数据立即被删除，过期数据被删除的时间取决于后台清理任务的调度周期和调度窗口。
 * 目前单个表的清理任务同时只能在同一个 TiDB Server 节点运行，这在某些场景下（比如表特别大的情况）可能会产生性能瓶颈。此问题会在后续版本中优化。
+
+## 常见问题
+
+- 如何判断删除的速度是否够快，能够保持数据总量相对稳定？
+
+   在 Grafana `TiDB` 面板中，监控项 `TTL Insert Rows Per Hour` 记录了前一小时总共插入数据的数量。相应的 `TTL Delete Rows Per Hour` 记录了前一小时 TTL 任务总共删除的数据总量。如果 `TTL Insert Rows Per Hour` 长期高于 `TTL Delete Rows Per Hour`， 说明插入的速度高于删除的速度，数据总量将会上升。例如：
+   ![insert fast example](/media/ttl/insert-fast.png)
+   值得注意的是，由于 TTL 并不能保证数据立即被删除，且当前插入的数据将会在将来的 TTL 任务中才会被删除，哪怕短时间内 TTL 删除的速度低于插入的速度，也不能说明 TTL 的效率一定过慢。需要结合具体情况分析。
+
+- 如何判断 TTL 任务的瓶颈在扫描还是删除？
+
+   观察面板中 `TTL Scan Worker Time By Phase` 与 `TTL Delete Worker Time By Phase` 监控项。如果 scan worker 长期处于 `dispatch` 状态，且 delete worker 很少处于 `idle` 状态，那么说明 scan worker 在等待 delete worker 完成删除工作，如果此时集群资源仍然较为宽松，可以考虑提高 `tidb_ttl_delete_worker_count` 来提高删除的 worker 数量。例如：
+   ![scan fast example](/media/ttl/scan-fast.png)
+   与之相对，如果 scan worker 很少处于 `dispatch` 的状态，且 delete worker 长期处于 `idle` 阶段，那么说明 delete worker 闲置，且 scan worker 较为忙碌。例如：
+   ![delete fast example](/media/ttl/delete-fast.png)
+   TTL 任务中扫描与删除的占比与机器配置、数据分布都有关系，所以每一时刻的数据只能代表正在执行的 TTL Job 的情况。用户可以通过查询表 `mysql.tidb_ttl_job_history` 来判断某一时刻运行的 TTL Job 对应哪一张表。
+
+- 如何合理配置 `tidb_ttl_scan_worker_count` 和 `tidb_ttl_delete_worker_count`？
+
+   首先，可以参考问题 "如何判断 TTL 任务的瓶颈在扫描还是删除？" 来考虑提升 `tidb_ttl_scan_worker_count` 还是 `tidb_ttl_delete_worker_count`。由于过高的 TTL worker 数量将会造成较大的压力，所以需要综合观察 TiDB 的 CPU 水平与 TiKV 的磁盘与 CPU 使用量。根据不同场景和需求（需要尽量加速 TTL，或是需要减少 TTL 对其他请求的影响）来调整 `tidb_ttl_scan_worker_count` 与 `tidb_ttl_delete_worker_count`，从而提升 TTL 扫描和删除数据的速度，或降低 TTL 任务对性能的影响。