From dfee767a8d538a5a5065557f7f261e190c89421b Mon Sep 17 00:00:00 2001 From: toutdesuite Date: Fri, 12 Jun 2020 14:18:09 +0800 Subject: [PATCH 1/2] cherry pick #3581 to release-4.0 Signed-off-by: sre-bot --- br/backup-and-restore-faq.md | 4 +- br/backup-and-restore-tool.md | 3 +- daily-check.md | 87 +++++++++++++++++++++++++++++++++++ ticdc/manage-ticdc.md | 2 +- ticdc/ticdc-overview.md | 5 +- 5 files changed, 93 insertions(+), 8 deletions(-) create mode 100644 daily-check.md diff --git a/br/backup-and-restore-faq.md b/br/backup-and-restore-faq.md index 49f437561adf..22b454ad8422 100644 --- a/br/backup-and-restore-faq.md +++ b/br/backup-and-restore-faq.md @@ -36,9 +36,9 @@ category: FAQ > **注意：** > -> 在恢复的时候也可能遇到同样的问题。BR 的恢复中，在检验读权限的时机是在第一次读取 SST 文件时，考虑到执行 DDL 的耗时，这个时刻可能会离开始运行 BR 的时间很远。 +> 在恢复的时候也可能遇到同样的问题。 > -> 这样可能会出现等了很长时间之后遇到 Permission denied 错误失败的情况。 +> 使用 BR 进行数据的恢复时，检验读权限的时机是在第一次读取 SST 文件时，考虑到执行 DDL 的耗时，这个时刻可能会离开始运行 BR 的时间很远。这样可能会出现等了很长时间之后遇到 Permission denied 错误失败的情况。 > > 因此，最好在恢复前提前检查权限。 diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index 6a1d798ad8a1..ccd5bcf03c2c 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -125,9 +125,10 @@ TiKV 收到加载 SST 文件的请求后，利用 Raft 机制保证加载 SST > 在使用 `local` storage 的时候，备份数据会分散在各个节点的本地文件系统中。 > > **不建议**在生产环境中备份到本地磁盘，因为在日后恢复的时候，**必须**手动聚集这些数据才能完成恢复工作（见[恢复集群数据](#恢复集群数据)）。 +> > 聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到颇为迷惑的 `SST file not found` 报错。 > -> 更加建议在各个节点挂载 NFS 网盘，或者直接备份到 `S3` 对象存储中。 +> 建议在各个节点挂载 NFS 网盘，或者直接备份到 `S3` 对象存储中。 ### 命令和子命令 diff --git a/daily-check.md b/daily-check.md new file mode 100644 index 000000000000..1956bf156302 --- /dev/null +++ b/daily-check.md @@ -0,0 +1,87 @@ +--- +title: 日常巡检 +summary: 介绍 TiDB 集群需要常关注的性能指标。 +category: reference +aliases: ['/docs-cn/dev/daily-inspection/'] +--- + +# 日常巡检 + +TiDB 作为分布式数据库，对比单机数据库机制更加复杂，其自带的监控项也很丰富。为了更便捷地运维 TiDB，本文介绍了运维 TiDB 集群需要常关注的关键性能指标。 + +## Dashboard 关键指标 + +从 4.0 版本开始，TiDB 提供了一个新的 Dashboard 运维管理工具，集成在 PD 组件上，默认地址为 `http://${pd-ip}:${pd_port}/dashboard`。 + +使用 TiDB Dashboard，简化了对 TiDB 数据库的运维，可在一个界面查看整个分布式数据库集群的运行状况。下面举例说明。 + +### 实例面板 + +![实例面板](/media/instance-status-panel.png) + +以上实例面板的各指标说明如下： + ++ **状态**：用于查看实例状态是否正常，如果在线可忽略此项。 ++ **启动时间**：是关键指标。如果有发现启动时间有变动，那么需要排查组件重启的原因。 ++ **版本**、**部署路径**、**Git 哈希值**：通过查看这三个指标可以避免有部署路径和版本不一致或者错误的情况。 + +### 主机面板 + +![主机面板](/media/host-panel.png) + +通过主机面板可以查看 CPU、内存、磁盘使用率。当任何资源的使用率超过 80% 时，推荐扩容对应组件。 + +### SQL 分析面板 + +![SQL 分析面板](/media/sql-analysis-panel.png) + +通过 SQL 分析面板可以分析对集群影响较大的慢 SQL，然后进行对应的 SQL 优化。 + +### Region 信息面板 + +![Region 信息面板](/media/region-panel.png) + +以上 Region 信息面板说明如下： + ++ `miss-peer-region-count`：缺副本的 Region 数量，不会一直大于 0。 ++ `extra-peer-region-count`：多副本的 Region 数量，调度过程中会产生。 ++ `empty-region-count`：空 Region 的数量，一般是 `TRUNCATE TABLE`/`DROP TABLE` 语句导致。如果数量较多，可以考虑开启跨表 Region merge。 ++ `pending-peer-region-count`：Raft log 落后的 Region 数量。由于调度产生少量的 pending peer 是正常的，但是如果持续很高，可能有问题。 ++ `down-peer-region-count`：Raft leader 上报有不响应 peer 的 Region 数量。 ++ `offline-peer-region-count`：peer 下线过程中的 Region 数量。 + +原则上来说，该监控面板偶尔有数据是符合预期的。但长期有数据，需要排查是否存在问题。 + +### KV Request Duration + +![TiKV 相应时间](/media/kv-duration-panel.png) + +TiKV 当前 .99（百分位）的响应时间。如果发现有明显高的节点，可以排查是否有热点，或者相关节点性能较差。 + +### PD TSO Wait Duration + +![TiDB 从 PD 获取 TSO 的时间](/media/pd-duration-panel.png) + +TiDB 从 PD 获取 TSO 的时间。如果相关响应时间较高，一般常见原因如下： + ++ TiDB 到 PD 的网络延迟较高，可以手动 Ping 一下网络延迟。 ++ TiDB 压力较高，导致获取较慢。 ++ PD 服务器压力较高，导致获取较慢。 + +### Overview 面板 + +![Overview 面板](/media/overview-panel.png) + +以上面板展示常见的负载、内存、网络、IO 监控。发现有瓶颈时，推荐扩容或者优化集群拓扑，优化 SQL、集群参数等。 + +### 异常监控面板 + +![异常监控面板](/media/failed-query-panel.png) + +以上面板展示每个 TiDB 实例上，执行 SQL 语句发生的错误，并按照错误类型进行统计，例如语法错误、主键冲突等。 + +### GC 状态面板 + +![GC 状态面板](/media/garbage-collation-panel.png) + +以上面板展示最后 GC（垃圾清理）的时间，观察 GC 是否正常。如果 GC 发生异常，可能会造成历史数据存留过多，影响访问效率。 diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md index 906bffbf827b..265830716cd7 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -188,7 +188,7 @@ cdc cli changefeed query --pd=http://127.0.0.1:2379 --changefeed-id=28c43ffc-231 以上命令中： -- `resolved-ts` 代表当前 changfeed 中最大的已经成功从 TiKV 发送到 TiCDC 的事务 TS； +- `resolved-ts` 代表当前 changefeed 中最大的已经成功从 TiKV 发送到 TiCDC 的事务 TS； - `checkpoint-ts` 代表当前 changefeed 中最大的已经成功写入下游的事务 TS； - `admin-job-type` 代表一个 changefeed 的状态： - `0`: 状态正常，也是初始状态。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index c3191e3f92cc..4ecf7cf4d751 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -51,15 +51,12 @@ TiCDC 的系统架构如下图所示： ### 暂不支持的场景 -目前 TiCDC（4.0 发布版本）与部分 TiDB 特性存在冲突，在后续的 TiCDC 版本上会逐渐修复。当前版本需要做相应的兼容性处理。暂不支持的场景如下： +目前 TiCDC（4.0 发布版本）暂不支持的场景如下： - 暂不支持单独使用 RawKV 的 TiKV 集群。 - 暂不支持 TiDB 4.0 [新的 Collation 框架](/character-set-and-collation.md#新框架下的-collation-支持)。如果开启该功能，需保证下游集群为 TiDB 并使用与上游相同的 collation，否则会出现 collation 导致的无法定位数据的问题。 - 暂不支持 TiDB 4.0 中[创建 SEQUENCE 的 DDL 操作](/sql-statements/sql-statement-create-sequence.md) 和 [SEQUENCE 函数](/sql-statements/sql-statement-create-sequence.md#sequence-函数)。在上游 TiDB 使用 SEQUENCE 时，TiCDC 将会忽略掉上游执行的 SEQUENCE DDL 操作/函数，但是使用 SEQUENCE 函数的 DML 操作可以正确地同步。 - 暂不支持 [TiKV Hibernate Region](https://github.com/tikv/tikv/blob/master/docs/reference/configuration/raftstore-config.md#hibernate-region)。TiCDC 会使 Region 无法进入静默状态。 - -TiCDC 本身也有部分功能尚未完善，将在后续的 TiCDC 版本逐渐修复： - - TiCDC 集群扩容后，不支持将已有的同步表调度到新的 TiCDC 节点中。 - 暂不支持库表同步黑白名单。 From 88adc4116d32e3cce8681451b95e546953957aa5 Mon Sep 17 00:00:00 2001 From: toutdesuite Date: Fri, 12 Jun 2020 15:34:32 +0800 Subject: [PATCH 2/2] Update daily-check.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- daily-check.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daily-check.md b/daily-check.md index daea15fdcbe0..c77846134eb9 100644 --- a/daily-check.md +++ b/daily-check.md @@ -2,7 +2,7 @@ title: 日常巡检 summary: 介绍 TiDB 集群需要常关注的性能指标。 category: reference -aliases: ['/docs-cn/stable/daily-inspection/','/docs-cn/v4.0/daily-inspection/'] +aliases: ['/docs-cn/stable/daily-inspection/'] --- # 日常巡检