From def936738a27de4ec71f7201b9244d64e273eab8 Mon Sep 17 00:00:00 2001 From: glkappe Date: Fri, 22 May 2020 18:18:20 +0800 Subject: [PATCH 1/5] add new page --- faq/deploy-and-maintain-faq.md | 519 +++++++++++++++++++++++++++++++++ 1 file changed, 519 insertions(+) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index e69de29bb2d1..b35f72a06547 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -0,0 +1,519 @@ +--- +title: 安装部署和集群管理 +category: FAQ +--- + +## 一、安装部署 + +### 1.1 环境准备 + +#### 1.1.1 操作系统版本要求 + +| **Linux 操作系统平台** | **版本** | +| --- | --- | +| Red Hat Enterprise Linux | 7.3 及以上 | +| CentOS | 7.3 及以上 | +| Oracle Enterprise Linux | 7.3 及以上 | + +##### 1.1.1.1 为什么要在 CentOS 7 上部署 TiDB 集群？ + +TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络，作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境，具体可以参考 TiDB 的[官方部署要求](/hardware-and-software-requirements.md)。其中 TiDB 在 CentOS 7.3 的环境下进行大量的测试，同时也有很多这个操作系统的部署最佳实践，因此，我们推荐客户在部署 TiDB 的时候使用 CentOS 7.3+ 以上的Linux 操作系统。 + +#### 1.1.2 硬件要求 + +TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置有以下要求和建议： + +##### 1.1.2.1 开发及测试环境 + +| **组件** | **CPU** | **内存** | **本地存储** | **网络** | **实例数量(最低要求)** | +| --- | --- | --- | --- | --- | --- | +| TiDB | 8核+ | 16 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 PD 同机器） | +| PD | 8核+ | 16 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 TiDB 同机器） | +| TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | +| | | | | 服务器总计 | 4 | + +##### 1.1.2.2 线上环境 + +| **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | +| --- | --- | --- | --- | --- | --- | +| TiDB | 16核+ | 48 GB+ | SAS | 万兆网卡（2块最佳） | 2 | +| PD | 8核+ | 16 GB+ | SSD | 万兆网卡（2块最佳） | 3 | +| TiKV | 16核+ | 48 GB+ | SSD | 万兆网卡（2块最佳） | 3 | +| 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | +| | | | | 服务器总计 | 9 | + +##### 1.1.2.3 2 块网卡的目的是？万兆的目的是？ + +作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定，万兆可以保证数据传输的速度，千兆网卡容易出现瓶颈，我们强烈建议使用万兆网卡。 + +##### 1.1.2.4 SSD 不做 RAID 是否可行？ + +资源可接受的话，我们建议做 RAID 10，如果资源有限，也可以不做 RAID。 + +##### 1.1.2.5 TiDB 集群各个组件的配置推荐？ + +- TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求，如果后期需要开启 Binlog，根据业务量的评估和 GC 时间的要求，也需要本地磁盘大一点，不要求 SSD 磁盘； +- PD 里面存了集群元信息，会有频繁的读写请求，对磁盘 I/O 要求相对比较高，磁盘太差会影响整个集群性能，推荐 SSD 磁盘，空间不用太大。另外集群 Region 数量越多对 CPU、内存的要求越高； +- TiKV 对 CPU、内存、磁盘要求都比较高，一定要用 SSD 磁盘。 + +详情可参考 [TiDB 软硬件环境需求](/hardware-and-software-requirements.md)。 + +### 1.2 安装部署 + +#### 1.2.1 推荐部署方式 + +[使用 TiUP 部署](/production-deployment-using-tiup.md)：如果用于生产环境，推荐使用 TiUP 部署 TiDB 集群。 + +##### 1.2.1.1 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？ + +这种情况一般是因为没有使用 `--config` 参数来指定配置文件（目前只会出现在 binary 部署的场景），TiKV/PD 会按默认值来设置。如果要使用配置文件，请设置 TiKV/PD 的 `--config` 参数。对于 TiKV 组件，修改配置后重启服务即可；对于 PD 组件，只会在第一次启动时读取配置文件，之后可以使用 pd-ctl 的方式来修改配置，详情可参考 [PD 配置参数](/command-line-flags-for-pd-configuration.md)。 + +##### 1.2.1.2 TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？ + +监控机建议单独部署。建议 CPU 8 core，内存 16 GB 以上，硬盘 500 GB 以上。 + +##### 1.2.1.3 有一部分监控信息显示不出来？ + +查看访问监控的机器时间跟集群内机器的时间差，如果比较大，更正时间后即可显示正常。 + +##### 1.2.1.4 supervise/svc/svstat 服务具体起什么作用？ + +- supervise 守护进程 +- svc 启停服务 +- svstat 查看进程状态 + +##### 1.2.1.5 inventory.ini 变量参数解读 + +| **变量** | **含义** | +| --- | --- | +| cluster_name | 集群名称，可调整 | +| tidb_version | TiDB 版本，TiDB Ansible 各分支默认已配置 | +| deployment_method | 部署方式，默认为 binary，可选 docker | +| process_supervision | 进程监管方式，默认为 systemd，可选 supervise | +| timezone | 修改部署目标机器时区，默认为 Asia/Shanghai, 可调整，与set_timezone 变量结合使用 | +| set_timezone | 默认为 True，即修改部署目标机器时区，关闭可修改为 False | +| enable_elk | 目前不支持，请忽略 | +| enable_firewalld | 开启防火墙，默认不开启 | +| enable_ntpd | 检测部署目标机器 NTP 服务，默认为 True，请勿关闭 | +| machine_benchmark | 检测部署目标机器磁盘 IOPS，默认为 True，请勿关闭 | +| set_hostname | 根据 IP 修改部署目标机器主机名，默认为 False | +| enable_binlog | 是否部署 pump 并开启 binlog，默认为 False，依赖 Kafka 集群，参见 zookeeper_addrs 变量 | +| zookeeper_addrs | binlog Kafka 集群的 zookeeper 地址 | +| enable_slow_query_log | TiDB 慢查询日志记录到单独文件({{ deploy_dir }}/log/tidb_slow_query.log)，默认为 False，记录到 tidb 日志 | +| deploy_without_tidb | KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 inventory.ini 文件中 tidb_servers 主机组 IP 设置为空。 | + +#### 1.2.2 TiDB 离线 Ansible 部署方案（4.0 版本后不推荐使用） + +首先这不是我们建议的方式，如果中控机没有外网，也可以通过离线 Ansible 部署方式，详情可参考[离线 TiDB Ansible 部署方案](/offline-deployment-using-ansible.md)。 + +#### 1.2.3 Docker Compose 快速构建集群（单机部署） + +使用 docker-compose 在本地一键拉起一个集群，包括集群监控，还可以根据需求自定义各个组件的软件版本和实例个数，以及自定义配置文件，这种只限于开发环境，详细可参考[官方文档](/deploy-test-cluster-using-docker-compose.md)。 + +#### 1.2.4 如何单独记录 TiDB 中的慢查询日志，如何定位慢查询 SQL？ + +1）TiDB 中，对慢查询的定义在 tidb-ansible 的 `conf/tidb.yml` 配置文件中，`slow-threshold: 300`，这个参数是配置慢查询记录阈值的，单位是 ms。 + +慢查询日志默认记录到 tidb.log 中，如果希望生成单独的慢查询日志文件，修改 inventory.ini 配置文件的参数 `enable_slow_query_log` 为 True。 + +如上配置修改之后，需要执行 `ansible-playbook rolling_update.yml --tags=tidb`，对 tidb-server 实例进行滚动升级，升级完成后，tidb-server 将在 `tidb_slow_query.log` +文件中记录慢查询日志。 + +2）如果出现了慢查询，可以从 Grafana 监控定位到出现慢查询的 tidb-server 以及时间点，然后在对应节点查找日志中记录的 SQL 信息。 + +3）除了日志，还可以通过 `admin show slow` 命令查看，详情可参考 [`admin show slow` 命令](/identify-slow-queries.md#admin-show-slow-命令)。 + +#### 1.2.5 首次部署 TiDB 集群时，没有配置 tikv 的 Label 信息，在后续如何添加配置 Label？ + +TiDB 的 Label 设置是与集群的部署架构相关的，是集群部署中的重要内容，是 PD 进行全局管理和调度的依据。如果集群在初期部署过程中没有设置 Label，需要在后期对部署结构进行调整，就需要手动通过 PD 的管理工具 pd-ctl 来添加 location-labels 信息，例如：`config set location-labels "zone,rack,host"`（根据实际的 label 层级名字配置）。 + +pd-ctl 的使用参考 [PD Control 使用说明](/pd-control.md)。 + +#### 1.2.6 为什么测试磁盘的 dd 命令用 oflag=direct 这个选项？ + +Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这样是为了绕开文件系统的缓存，可以直接测试磁盘的真实的 I/O 读写能力。 + +#### 1.2.7 如何用 fio 命令测试 TiKV 实例的磁盘性能？ + +- 随机读测试： + + {{< copyable "shell-regular" >}} + + ```bash + ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randread -size=10G -filename=fio_randread_test.txt -name='fio randread test' -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_result.json + ``` + +- 顺序写和随机读混合测试： + + {{< copyable "shell-regular" >}} + + ```bash + ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randrw -percentage_random=100,0 -size=10G -filename=fio_randread_write_test.txt -name='fio mixed randread and sequential write test' -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_write_test.json + ``` + +#### 1.2.8 使用 TiDB Ansible 部署 TiDB 集群的时候，遇到 `UNREACHABLE! "msg": "Failed to connect to the host via ssh: "` 报错是什么原因？ + +有两种可能性： + +- ssh 互信的准备工作未做好，建议严格参照我们的[官方文档步骤](/online-deployment-using-ansible.md)配置互信，并使用命令 `ansible -i inventory.ini all -m shell -a 'whoami' -b` 来验证互信配置是否成功。 + +- 如果涉及到单服务器分配了多角色的场景，例如多组件混合部署或单台服务器部署了多个 TiKV 实例，可能是由于 ssh 复用的机制引起这个报错，可以使用 `ansible … -f 1` 的选项来规避这个报错。 + +## 二、集群管理 + +### 2.1 集群日常管理 + +#### 2.1.1 Ansible 常见运维操作有那些？ + +| **任务** | **Playbook** | +| --- | --- | +| 启动集群 | ansible-playbook start.yml | +| 停止集群 | ansible-playbook stop.yml | +| 销毁集群 | ansible-playbook unsafe\_cleanup.yml (若部署目录为挂载点，会报错，可忽略） | +| 清除数据(测试用) | ansible-playbook cleanup\_data.yml | +| 滚动升级 | ansible-playbook rolling\_update.yml | +| 滚动升级 TiKV | ansible-playbook rolling\_update.yml --tags=tikv | +| 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | +| 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | + +#### 2.1.2 TiDB 如何登录？ + +和 MySQL 登录方式一样，可以按照下面例子进行登录。 + +`mysql -h 127.0.0.1 -uroot -P4000` + +#### 2.1.3 TiDB 如何修改数据库系统变量？ + +和 MySQL 一样，TiDB 也分为静态参数和固态参数，静态参数可以直接通过`set global xxx = n`的方式进行修改，不过新参数值只限于该实例生命周期有效。 + +#### 2.1.4 TiDB (TiKV) 有哪些数据目录？ + +默认在 [`--data-dir`](/command-line-flags-for-tikv-configuration.md#--data-dir) 目录下，其中包括 backup、db、raft、snap 四个目录，分别存储备份、数据、raft 数据及镜像数据。 + +#### 2.1.5 TiDB 有哪些系统表？ + +和 MySQL 类似，TiDB 中也有系统表，用于存放数据库运行时所需信息，具体信息参考 [TiDB 系统数据库](/system-tables/system-table-overview.md)文档。 + +#### 2.1.6 TiDB 各节点服务器下是否有日志文件，如何管理？ + +默认情况下各节点服务器会在日志中输出标准错误，如果启动的时候通过 `--log-file` 参数指定了日志文件，那么日志会输出到指定的文件中，并且按天做 rotation。 + +#### 2.1.7 如何规范停止 TiDB？ + +如果是用 TiDB Ansible 部署的，可以使用 `ansible-playbook stop.yml` 命令停止 TiDB 集群。如果不是 TiDB Ansible 部署的，可以直接 kill 掉所有服务。如果使用 kill 命令，TiDB 的组件会做 graceful 的 shutdown。 + +#### 2.1.8 TiDB 里面可以执行 kill 命令吗？ + +- 可以 kill DML 语句，首先使用 `show processlist`，找到对应 session 的 id，然后执行 `kill tidb [session id]`。 +- 可以 kill DDL 语句，首先使用 `admin show ddl jobs`，查找需要 kill 的 DDL job ID，然后执行 `admin cancel ddl jobs 'job_id' [, 'job_id'] ...`。具体可以参考 [admin 操作](/sql-statements/sql-statement-admin.md)。 + +#### 2.1.9 TiDB 是否支持会话超时？ + +TiDB 暂不支持数据库层面的会话超时，目前想要实现超时，在没 LB（Load Balancing）的时候，需要应用侧记录发起的 Session 的 ID，通过应用自定义超时，超时以后需要到发起 Query 的节点上用 `kill tidb [session id]` 来杀掉 SQL。目前建议使用应用程序来实现会话超时，当达到超时时间，应用层就会抛出异常继续执行后续的程序段。 + +#### 2.1.10 TiDB 生产环境的版本管理策略是怎么样的？如何尽可能避免频繁升级？ + +TiDB 版本目前逐步标准化，每次 Release 都包含详细的 Change log，版本功能[变化详情](https://github.com/pingcap/TiDB/releases)，生产环境是否有必要升级取决于业务系统，建议升级之前详细了解前后版本的功能差异。 + +版本号说明参考：Release Version: `v1.0.3-1-ga80e796` + +- `v1.0.3` 表示 GA 标准版 +- `1` 表示该版本 commit 1 次 +- `ga80e796` 代表版本的 `git-hash` + +#### 2.1.11 分不清 TiDB master 版本之间的区别，经常用错 TiDB Ansible 版本? + +TiDB 目前社区非常活跃，在 1.0 GA 版本发布后，还在不断的优化和修改 BUG，因此 TiDB 的版本更新周期比较快，会不定期有新版本发布，请关注我们的[新版本发布官方网站](https://pingcap.com/weekly/)。此外 TiDB 安装推荐[使用 TiUP 进行安装](/production-deployment-using-tiup.md)。此外，在 TiDB 1.0 GA 版本后，对 TiDB 的版本号进行了统一管理，TiDB 的版本可以通过以下两种方式进行查看： + +- 通过 `select tidb_version()` 进行查看 +- 通过执行 `tidb-server -V` 进行查看 + +#### 2.1.12 有没有图形化部署 TiDB 的工具？ + +暂时没有。 + +#### 2.1.13 TiDB 如何进行水平扩展？ + +当您的业务不断增长时，数据库可能会面临三方面瓶颈，第一是存储空间，第二是计算资源，第三是读写容量，这时可以对 TiDB 集群做水平扩展。 + +- 如果是存储资源不够，可以通过添加 TiKV Server 节点来解决，新节点启动后，PD 会自动将其他节点的部分数据迁移过去，无需人工介入。 +- 如果是计算资源不够，可以查看 TiDB Server 和 TiKV Server 节点的 CPU 消耗情况，再考虑添加 TiDB Server 节点或者是 TiKV Server 节点来解决，如添加 TiDB Server 节点，将其添加到前端 Load Balancer 配置之中即可。 +- 如果是容量跟不上，一般可以考虑同时增加 TiDB Server 和 TiKV Server 节点。 + +#### 2.1.14 Percolator 用了分布式锁，crash 的客户端会保持锁，会造成锁没有 release？ + +详细可参考 [Percolator 和 TiDB 事务算法](https://pingcap.com/blog-cn/percolator-and-txn/)。 + +#### 2.1.15 TiDB 为什么选用 gRPC 而不选用 Thrift，是因为 Google 在用吗？ + +不只是因为 Google 在用，有一些比较好的特性我们需要，比如流控、加密还有 Streaming。 + +#### 2.1.16 like(bindo.customers.name, jason%, 92) 这个92代表什么？ + +那个是转义字符，默认是 (ASCII 92)。 + +#### 2.1.17 为什么 `information_schema.tables.data_length` 记录的大小和 TiKV 监控面板上的 store size 不一样？ + +这是因为两者计算的角度不一样。`information_schema.tables.data_length` 是通过统计信息（平均每行的大小）得到的估算值。TiKV 监控面板上的 store size 是单个 TiKV 实例的数据文件（RocksDB 的 SST 文件）的大小总和。由于多版本和 TiKV 会压缩数据，所以两者显示的大小不一样。 + +### 2.2 PD 管理 + +#### 2.2.1 访问 PD 报错：TiKV cluster is not bootstrapped + +PD 的大部分 API 需要在初始化 TiKV 集群以后才能使用，如果在部署新集群的时候只启动了 PD，还没有启动 TiKV，这时候访问 PD 就会报这个错误。遇到这个错误应该先把要部署的 TiKV 启动起来，TiKV 会自动完成初始化工作，然后就可以正常访问 PD。 + +#### 2.2.2 PD 启动报错：etcd cluster ID mismatch + +PD 启动参数中的 `--initial-cluster` 包含了某个不属于该集群的成员。遇到这个错误时请检查各个成员的所属集群，剔除错误的成员后即可正常启动。 + +#### 2.2.3 PD 能容忍的时间同步误差是多少？ + +理论上，时间同步误差越小越好。PD 可容忍任意时长的误差，但是，时间同步误差越大意味着 PD 分配的时间戳与真实的物理时间相差越大，这个差距会影响读历史版本等功能。 + +#### 2.2.4 Client 连接是如何寻找 PD 的？ + +Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD 与 TiKV 对 Client 透明。当 TiDB 连接任意一台 PD 的时候，PD 会告知 TiDB 当前的 leader 是谁，如果此台 PD 不是 leader，TiDB 将会重新连接至 leader PD。 + +#### 2.2.5 PD 参数中 leader-schedule-limit 和 region-schedule-limit 调度有什么区别？ + +- leader-schedule-limit 调度是用来均衡不同 TiKV 的 leader 数，影响处理查询的负载。 +- region-schedule-limit 调度是均衡不同 TiKV 的副本数，影响不同节点的数据量。 + +#### 2.2.6 每个 region 的 replica 数量可配置吗？调整的方法是？ + +可以，目前只能调整全局的 replica 数量。首次启动时 PD 会读配置文件（conf/pd.yml），使用其中的 max-replicas 配置，之后修改需要使用 pd-ctl 配置命令 `config set max-replicas $num`，配置后可通过 `config show all` 来查看已生效的配置。调整的时候，不会影响业务，会在后台添加，注意总 TiKV 实例数总是要大于等于设置的副本数，例如 3 副本需要至少 3 个 TiKV。增加副本数量之前需要预估额外的存储需求。pd-ctl 的详细用法可参考 [PD Control 使用说明](/pd-control.md)。 + +#### 2.2.7 缺少命令行集群管理工具，整个集群的健康度当前是否正常，不好确认？ + +可以通过 pd-ctl 等工具来判断集群大概的状态，详细的集群状态还是需要通过监控来确认。 + +#### 2.2.8 集群下线节点后，怎么删除老集群节点监控信息？ + +下线节点一般指 TiKV 节点通过 pd-ctl 或者监控判断节点是否下线完成。节点下线完成后，手动停止下线节点上相关的服务。从 Prometheus 配置文件中删除对应节点的 node_exporter 信息。从 Ansible inventory.ini 中删除对应节点的信息。 + +#### 2.2.9 使用 PD Control 连接 PD Server 时，为什么只能通过本机 IP 连接，不能通过 127.0.0.1 连接？ + +因为使用 TiDB Ansible 部署的集群，PD 对外服务端口不会绑定到 127.0.0.1，所以 PD Control 不会识别 127.0.0.1。 + +### 2.3 TiDB server 管理 + +#### 2.2.1 TiDB 的 lease 参数应该如何设置？ + +启动 TiDB Server 时，需要通过命令行参数设置 lease 参数（--lease=60），其值会影响 DDL 的速度（只会影响当前执行 DDL 的 session，其他的 session 不会受影响）。在测试阶段，lease 的值可以设为 1s，加快测试进度；在生产环境下，我们推荐这个值设为分钟级（一般可以设为 60），这样可以保证 DDL 操作的安全。 + +#### 2.2.2 DDL 在正常情况下的耗时是多少？ + +一般情况下处理一个 DDL 操作（之前没有其他 DDL 操作在处理）的耗时基本可以分如下为三种： + +- add index 操作，且此操作对应表数据行数比较少，耗时约为 3s。 +- add index 操作，且此操作对应表数据行数比较多，耗时具体由表中数据行数和当时 QPS 情况定（add index 操作优先级比一般 SQL 低）。 +- 其他 DDL 操作耗时约为 1s。 + +此外，如果接收 DDL 请求的 TiDB 和 DDL owner 所处的 TiDB 是一台，那么上面列举的第一和第三种可能的耗时应该在几十到几百毫秒。 + +#### 2.2.3 为什么有的时候执行 DDL 会很慢？ + +可能原因如下： + +- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句会比较慢。原因是当前 TiDB 集群中 DDL 操作是串行执行的。 +- 在正常集群启动后，第一个 DDL 操作的执行时间可能会比较久，一般在 30s 左右，这个原因是刚启动时 TiDB 在竞选处理 DDL 的 leader。 +- 由于停 TiDB 时不能与 PD 正常通信（包括停电情况）或者用 `kill -9` 指令停 TiDB 导致 TiDB 没有及时从 PD 清理注册数据，那么会影响 TiDB 启动后 10min 内的 DDL 语句处理时间。这段时间内运行 DDL 语句时，每个 DDL 状态变化都需要等待 2 * lease（默认 lease = 45s）。 +- 当集群中某个 TiDB 与 PD 之间发生通信问题，即 TiDB 不能从 PD 及时获取或更新版本信息，那么这时候 DDL 操作的每个状态处理需要等待 2 * lease。 + +#### 2.2.4 TiDB 可以使用 S3 作为后端存储吗？ + +不可以，目前 TiDB 只支持分布式存储引擎和 GolevelDB/RocksDB/BoltDB 引擎。 + +#### 2.2.5 Information_schema 能否支持更多真实信息？ + +Information_schema 库里面的表主要是为了兼容 MySQL 而存在，有些第三方软件会查询里面的信息。在目前 TiDB 的实现中，里面大部分只是一些空表。后续随着 TiDB 的升级，会提供更多的参数信息。当前 TiDB 支持的 Information\_schema 请参考 [TiDB 系统数据库说明文档](/system-tables/system-table-information-schema.md)。 + +#### 2.2.6 TiDB Backoff type 主要原因? + +TiDB-server 与 TiKV-server 随时进行通信，在进行大量数据操作过程中，会出现 `Server is busy` 或者 `backoff.maxsleep 20000ms` 的日志提示信息，这是由于 TiKV-server 在处理过程中系统比较忙而出现的提示信息，通常这时候可以通过系统资源监控到 TiKV 主机系统资源使用率比较高的情况出现。如果这种情况出现，可以根据资源使用情况进行相应的扩容操作。 + +#### 2.2.7 TiDB TiClient type 主要原因？ + +TiClient Region Error 该指标描述的是在 TiDB-server 作为客户端通过 KV 接口访问 TiKV-server 进行数据操作过程中，TiDB-server 操作 TiKV-server 中的 Region 数据出现的错误类型与 metric 指标，错误类型包括 not_leader、stale_epoch。出现这些错误的情况是当 TiDB-server 根据自己的缓存信息去操作 Region leader 数据的时候，Region leader 发生了迁移或者 TiKV 当前的 Region 信息与 TiDB 缓存的路由信息不一致而出现的错误提示。一般这种情况下，TiDB-server 都会自动重新从 PD 获取最新的路由数据，重做之前的操作。 + +#### 2.2.8 TiDB 同时支持的最大并发连接数？ + +当前版本 TiDB 没有最大连接数的限制，如果并发过大导致响应时间增加，可以通过增加 TiDB 节点进行扩容。 + +#### 2.2.9 如何查看某张表创建的时间？ + +information_schema 库中的 tables 表里的 create_time 即为表的真实创建时间。 + +#### 2.2.9 TiDB 的日志中 EXPENSIVE_QUERY 是什么意思？ + +TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条数据就认为这条 query 是 expensive query。可以通过修改 tidb-server 配置参数来对这个门限值进行调整，调整后需要重新启动 tidb-server。 + +### 2.4 TiKV 管理 + +#### 2.4.1 TiKV 集群副本建议配置数量是多少，是不是最小高可用配置（3个）最好？ + +如果是测试环境 3 副本足够；在生产环境中，不可让集群副本数低于 3，需根据架构特点、业务系统及恢复能力的需求，适当增加副本数。值得注意的是，副本升高，性能会有下降，但是安全性更高。 + +#### 2.4.2 TiKV 启动报错：cluster ID mismatch + +TiKV 本地存储的 cluster ID 和指定的 PD 的 cluster ID 不一致。在部署新的 PD 集群的时候，PD 会随机生成一个 cluster ID，TiKV 第一次初始化的时候会从 PD 获取 cluster ID 存储在本地，下次启动的时候会检查本地的 cluster ID 与 PD 的 cluster ID 是否一致，如果不一致则会报错并退出。出现这个错误一个常见的原因是，用户原先部署了一个集群，后来把 PD 的数据删除了并且重新部署了新的 PD，但是 TiKV 还是使用旧的数据重启连到新的 PD 上，就会报这个错误。 + +#### 2.4.3 TiKV 启动报错：duplicated store address + +启动参数中的地址已经被其他的 TiKV 注册在 PD 集群中了。造成该错误的常见情况：TiKV `--data-dir` 指定的路径下没有数据文件夹（删除或移动后没有更新 --data-dir），用之前参数重新启动该 TiKV。请尝试用 pd-ctl 的 [store delete](https://github.com/pingcap/pd/tree/55db505e8f35e8ab4e00efd202beb27a8ecc40fb/tools/pd-ctl#store-delete--label--weight-store_id----jqquery-string) 功能，删除之前的 store，然后重新启动 TiKV 即可。 + +#### 2.4.4 TiKV master 和 slave 用的是一样的压缩算法，为什么效果不一样? + +目前来看 master 有些文件的压缩率会高一些，这个取决于底层数据的分布和 RocksDB 的实现，数据大小偶尔有些波动是正常的，底层存储引擎会根据需要调整数据。 + +#### 2.4.5 TiKV block cache 有哪些特性？ + +TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在默认 RocksDB 内部的 default、write、lock 3 个 CF 内。 + +- default CF 存储的是真正的数据，与其对应的参数位于 `[rocksdb.defaultcf]` 项中。 +- write CF 存储的是数据的版本信息（MVCC）、索引、小表相关的数据，相关的参数位于 `[rocksdb.writecf]` 项中。 +- lock CF 存储的是锁信息，系统使用默认参数。 +- Raft RocksDB 实例存储 Raft log。default CF 主要存储的是 Raft log，与其对应的参数位于 `[raftdb.defaultcf]` 项中。 +- 所有 CF 共享一个 Block-cache，用于缓存数据块，加速 RocksDB 的读取速度，Block-cache 的大小通过参数 `block-cache-size` 控制，`block-cache-size` 越大，能够缓存的热点数据越多，对读取操作越有利，同时占用的系统内存也会越多。 +- 每个 CF 有各自的 Write-buffer，大小通过 `write-buffer-size` 控制。 + +#### 2.4.6 TiKV channel full 是什么原因？ + +- Raftstore 线程太忙，或者因 I/O 而卡住。可以看一下 Raftstore 的 CPU 使用情况。 +- TiKV 过忙（CPU、磁盘 I/O 等），请求处理不过来。 + +#### 2.4.7 TiKV 频繁切换 Region leader 是什么原因？ + +- 网络问题导致节点间通信卡了，查看 Report failures 监控。 +- 原主 Leader 的节点卡了，导致没有及时给 Follower 发送消息。 +- Raftstore 线程卡了。 + +#### 2.4.8 如果一个节点挂了会影响服务吗？影响会持续多久？ + +TiDB 使用 Raft 在多个副本之间做数据同步（默认为每个 Region 3 个副本）。当一份备份出现问题时，其他的副本能保证数据的安全。根据 Raft 协议，当某个节点挂掉导致该节点里的 Leader 失效时，在最大 2 * lease time（leasetime 是 10 秒）时间后，通过 Raft 协议会很快将一个另外一个节点里的 Follower 选为新的 Region Leader 来提供服务。 + +#### 2.4.9 TiKV 在分别在那些场景下占用大量 IO、内存、CPU（超过参数配置的多倍）？ + +在大量写入、读取的场景中会占用大量的磁盘 IO、内存、CPU。在执行很复杂的查询，比如会产生很大中间结果集的情况下，会消耗很多的内存和 CPU 资源。 + +#### 2.4.10 TiKV 是否可以使用 SAS/SATA 盘或者进行 SSD/SAS 混合部署？ + +不可以使用，TiDB 在进行 OLTP 场景中，数据访问和操作需要高 IO 磁盘的支持，TiDB 作为强一致的分布式数据库，存在一定的写放大，如副本复制、存储底层 Compaction，因此，TiDB 部署的最佳实践中推荐用户使用 NVMe SSD 磁盘作为数据存储磁盘。另外，TiKV 与 PD 不能混合部署。 + +#### 2.4.11 数据表 Key 的 Range 范围划分是在数据接入之前就已经划分好了吗？ + +不是的，这个和 MySQL 分表规则不一样，需要提前设置好，TiKV 是根据 Region 的大小动态分裂的。 + +#### 2.4.12 Region 是如何进行分裂的？ + +Region 不是前期划分好的，但确实有 Region 分裂机制。当 Region 的大小超过参数 `region-max-size` 或 `region-max-keys` 的值时，就会触发分裂，分裂后的信息会汇报给 PD。 + +#### 2.4.13 TiKV 是否有类似 MySQL 的 `innodb_flush_log_trx_commit` 参数，来保证提交数据不丢失？ + +是的，TiKV 单机的存储引擎目前使用两个 RocksDB 实例，其中一个存储 raft-log，TiKV 有个 sync-log 参数，在 ture 的情况下，每次提交都会强制刷盘到 raft-log，如果发生 crash 后，通过 raft-log 进行 KV 数据的恢复。 + +#### 2.4.14 对 WAL 存储有什么推荐的硬件配置，例如 SSD，RAID 级别，RAID 卡 cache 策略，NUMA 设置，文件系统选择，操作系统的 IO 调度策略等？ + +WAL 属于顺序写，目前我们并没有单独对他进行配置，建议 SSD，RAID 如果允许的话，最好是 RAID 10，RAID 卡 cache、操作系统 I/O 调度目前没有针对性的最佳实践，Linux 7 以上默认配置即可，NUMA 没有特别建议，NUMA 内存分配策略可以尝试使用 `interleave = all`，文件系统建议 ext4。 + +#### 2.4.15 在最严格的 `sync-log = true` 数据可用模式下，写入性能如何？ + +一般来说，开启 `sync-log` 会让性能损耗 30% 左右。关闭 `sync-log` 时的性能表现，请参见 [TiDB Sysbench 性能测试报告](/benchmark/v2.0-performance-benchmarking-with-sysbench.md)。 + +#### 2.4.16 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠，单机存储引擎是否需要最严格模式？ + +通过使用 [Raft 一致性算法](https://raft.github.io/)，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）。但理论上两个节点也可能同时发生故障，所以除非是对性能要求高于数据安全的场景，一般都强烈推荐开启 `sync-log`。 + +另外，还有一种 `sync-log` 的替代方案，即在 Raft group 中用五个副本而非三个。这将允许两个副本同时发生故障，而仍然能保证数据安全性。 + +对于单机存储引擎也同样推荐打开 `sync-log` 模式。否则如果节点宕机可能会丢失最后一次写入数据。 + +#### 2.4.17 使用 Raft 协议，数据写入会有多次网络的 roundtrip，实际写入延迟如何？ + +理论上，和单机数据库相比，数据写入会多四个网络延迟。 + +#### 2.4.18 有没有类似 MySQL 的 InnoDB Memcached plugin，可以直接使用 KV 接口，可以不需要独立的 Cache？ + +TiKV 支持单独进行接口调用，理论上也可以起个实例做为 Cache，但 TiDB 最大的价值是分布式关系型数据库，我们原则上不对 TiKV 单独进行支持。 + +#### 2.4.19 Coprocessor 组件的主要作用？ + +- 减少 TiDB 与 TiKV 之间的数据传输。 +- 计算下推，充分利用 TiKV 的分布式计算资源。 + +#### 2.4.20 IO error: No space left on device While appending to file + +这是磁盘空间不足导致的，需要加节点或者扩大磁盘空间。 + +#### 2.4.21 为什么 TiKV 容易出现 OOM？ + +TiKV 的内存占用主要来自于 RocksDB 的 block-cache，默认为系统总内存的 40%。当 TiKV 容易出现 OOM 时，检查 `block-cache-size` 配置是否过高。还需要注意，当单机部署了多个 TiKV 实例时，需要显式地配置该参数，以防止多个实例占用过多系统内存导致 OOM。 + +#### 2.4.22 TiDB 数据和 RawKV 数据可存储于同一个 TiKV 集群里吗？ + +不可以。TiDB 数据（或使用其他事务 API 生成的数据）依赖于一种特殊的键值格式，和 RawKV API 数据（或其他基于 RawKV 的服务生成的数据）并不兼容。 + +### 2.5 TiDB 测试 + +#### 2.5.1 TiDB Sysbench 基准测试结果如何？ + +很多用户在接触 TiDB 都习惯做一个基准测试或者 TiDB 与 MySQL 的对比测试，官方也做了一个类似测试，汇总很多测试结果后，我们发现虽然测试的数据有一定的偏差，但结论或者方向基本一致，由于 TiDB 与 MySQL 由于架构上的差别非常大，很多方面是很难找到一个基准点，所以官方的建议两点： + +- 大家不要用过多精力纠结这类基准测试上，应该更多关注 TiDB 的场景上的区别。 +- 大家可以直接参考 [TiDB Sysbench 性能测试报告](/benchmark/v2.0-performance-benchmarking-with-sysbench.md)。 + +#### 2.5.2 TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？ + +- 在 10 节点内，TiDB 写入能力（Insert TPS）和节点数量基本成 40% 线性递增，MySQL 由于是单节点写入，所以不具备写入扩展能力。 +- MySQL 读扩容可以通过添加从库进行扩展，但写流量无法扩展，只能通过分库分表，而分库分表有很多问题，具体参考[方案虽好，成本先行：数据库 Sharding+Proxy 实践解析](http://t.cn/RTD18qV)。 +- TiDB 不管是读流量、还是写流量都可以通过添加节点快速方便的进行扩展。 + +#### 2.5.3 我们的 DBA 测试过 MySQL 性能，单台 TiDB 的性能没有 MySQL 性能那么好？ + +TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做的分库分表的场景，或者需要强一致性和完整分布式事务的场景。它的优势是通过尽量下推到存储节点进行并行计算。对于小表（比如千万级以下），不适合 TiDB，因为数据量少，Region 有限，发挥不了并行的优势，最极端的就是计数器表，几行记录高频更新，这几行在 TiDB 里，会变成存储引擎上的几个 KV，然后只落在一个 Region 里，而这个 Region 只落在一个节点上。加上后台强一致性复制的开销，TiDB 引擎到 TiKV 引擎的开销，最后表现出来的就是没有单个 MySQL 好。 + +### 2.6 TiDB 备份恢复 + +#### 2.6.1 TiDB 主要备份方式？ + +目前，推荐的备份方式是使用 [PingCAP fork 的 Mydumper](/mydumper-overview.md)。尽管 TiDB 也支持使用 MySQL 官方工具 `mysqldump` 进行数据备份、恢复，但其性能低于 [`mydumper`](/mydumper-overview.md)/[`loader`](/loader-overview.md)，并且该工具备份、恢复大量数量时，要耗费更多时间。 + +使用 Mydumper 导出来的数据文件尽可能的小, 最好不要超过 64M, 可以设置参数 -F 64； + +loader 的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调整，例如 3 个 TiKV 的场景， 此值可以设为 3 * (1 ～ n)，当 TiKV 负载过高，loader 以及 TiDB 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 TiKV 负载不是太高的时候，可以适当调大该值。 + +## 三、监控 + +### 3.1 Prometheus 监控框架 + +详细参考 [TiDB 监控框架概述](/tidb-monitoring-framework.md)。 + +### 3.2 监控指标解读 + +详细参考 [重要监控指标详解](/grafana-overview-dashboard.md)。 + +#### 3.2.1 目前的监控使用方式及主要监控指标，有没有更好看的监控？ + +TiDB 使用 Prometheus + Grafana 组成 TiDB 数据库系统的监控系统，用户在 Grafana 上通过 dashboard 可以监控到 TiDB 的各类运行指标，包括系统资源的监控指标，包括客户端连接与 SQL 运行的指标，包括内部通信和 Region 调度的指标，通过这些指标，可以让数据库管理员更好的了解到系统的运行状态，运行瓶颈等内容。在监控指标的过程中，我们按照 TiDB 不同的模块，分别列出了各个模块重要的指标项，一般用户只需要关注这些常见的指标项。具体指标请参见[官方文档](/grafana-overview-dashboard.md)。 + +#### 3.2.2 Prometheus 监控数据默认 15 天自动清除一次，可以自己设定成 2 个月或者手动删除吗？ + +可以的，在 Prometheus 启动的机器上，找到启动脚本，然后修改启动参数，然后重启 Prometheus 生效。 + +```config +--storage.tsdb.retention="60d" +``` + +#### 3.2.3 Region Health 监控项 + +TiDB-2.0 版本中，PD metric 监控页面中，对 Region 健康度进行了监控，其中 Region Health 监控项是对所有 Region 副本状况的一些统计。其中 miss 是缺副本，extra 是多副本。同时也增加了按 Label 统计的隔离级别，level-1 表示这些 Region 的副本在第一级 Label 下是物理隔离的，没有配置 location label 时所有 Region 都在 level-0。 + +#### 3.2.4 Statement Count 监控项中的 selectsimplefull 是什么意思？ + +代表全表扫，但是可能是很小的系统表。 + +#### 3.2.5 监控上的 QPS 和 Statement OPS 有什么区别？ + +QPS 会统计执行的所有 SQL 命令，包括 use database、load data、begin、commit、set、show、insert、select 等。 + +Statement OPS 只统计 select、update、insert 等业务相关的，所以 Statement OPS 的统计和业务比较相符。 From d1f1eafb25c4b43c2048773402aded574a65cc44 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 22 May 2020 19:41:25 +0800 Subject: [PATCH 2/5] fix dead link and add metadata --- faq/deploy-and-maintain-faq.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index b35f72a06547..b63af57712ff 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -1,8 +1,11 @@ --- -title: 安装部署和集群管理 +title: 部署运维 FAQ +summary: 介绍 TiDB 集群运维部署的常见问题、原因及解决方法。 category: FAQ --- +# 部署运维 FAQ + ## 一、安装部署 ### 1.1 环境准备 @@ -15,7 +18,7 @@ category: FAQ | CentOS | 7.3 及以上 | | Oracle Enterprise Linux | 7.3 及以上 | -##### 1.1.1.1 为什么要在 CentOS 7 上部署 TiDB 集群？ +##### 1.1.1.1 为什么要在 CentOS 7 上部署 TiDB 集群？ TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络，作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境，具体可以参考 TiDB 的[官方部署要求](/hardware-and-software-requirements.md)。其中 TiDB 在 CentOS 7.3 的环境下进行大量的测试，同时也有很多这个操作系统的部署最佳实践，因此，我们推荐客户在部署 TiDB 的时候使用 CentOS 7.3+ 以上的Linux 操作系统。 @@ -418,7 +421,7 @@ WAL 属于顺序写，目前我们并没有单独对他进行配置，建议 SSD #### 2.4.15 在最严格的 `sync-log = true` 数据可用模式下，写入性能如何？ -一般来说，开启 `sync-log` 会让性能损耗 30% 左右。关闭 `sync-log` 时的性能表现，请参见 [TiDB Sysbench 性能测试报告](/benchmark/v2.0-performance-benchmarking-with-sysbench.md)。 +一般来说，开启 `sync-log` 会让性能损耗 30% 左右。关闭 `sync-log` 时的性能表现，请参见 [TiDB Sysbench 性能测试报告](/benchmark/v3.0-performance-benchmarking-with-sysbench.md)。 #### 2.4.16 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠，单机存储引擎是否需要最严格模式？ @@ -460,7 +463,7 @@ TiKV 的内存占用主要来自于 RocksDB 的 block-cache，默认为系统总 很多用户在接触 TiDB 都习惯做一个基准测试或者 TiDB 与 MySQL 的对比测试，官方也做了一个类似测试，汇总很多测试结果后，我们发现虽然测试的数据有一定的偏差，但结论或者方向基本一致，由于 TiDB 与 MySQL 由于架构上的差别非常大，很多方面是很难找到一个基准点，所以官方的建议两点： - 大家不要用过多精力纠结这类基准测试上，应该更多关注 TiDB 的场景上的区别。 -- 大家可以直接参考 [TiDB Sysbench 性能测试报告](/benchmark/v2.0-performance-benchmarking-with-sysbench.md)。 +- 大家可以直接参考 [TiDB Sysbench 性能测试报告](/benchmark/v3.0-performance-benchmarking-with-sysbench.md)。 #### 2.5.2 TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？ From 1aefa8a14addaf2b103bd6dfbe8de2caca1fafbe Mon Sep 17 00:00:00 2001 From: glkappe Date: Sat, 23 May 2020 21:00:26 +0800 Subject: [PATCH 3/5] =?UTF-8?q?=E6=92=A4=E6=8E=89=E8=AF=A5=20PR=20?= =?UTF-8?q?=E5=8C=85=E5=90=AB=E7=9A=84=E5=BA=8F=E5=8F=B7?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- faq/deploy-and-maintain-faq.md | 202 ++++++++++++++++----------------- 1 file changed, 101 insertions(+), 101 deletions(-) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index b63af57712ff..85554259fa2c 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -6,11 +6,11 @@ category: FAQ # 部署运维 FAQ -## 一、安装部署 +## 安装部署 -### 1.1 环境准备 +### 环境准备 -#### 1.1.1 操作系统版本要求 +#### 操作系统版本要求 | **Linux 操作系统平台** | **版本** | | --- | --- | @@ -18,15 +18,15 @@ category: FAQ | CentOS | 7.3 及以上 | | Oracle Enterprise Linux | 7.3 及以上 | -##### 1.1.1.1 为什么要在 CentOS 7 上部署 TiDB 集群？ +##### 为什么要在 CentOS 7 上部署 TiDB 集群？ TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络，作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境，具体可以参考 TiDB 的[官方部署要求](/hardware-and-software-requirements.md)。其中 TiDB 在 CentOS 7.3 的环境下进行大量的测试，同时也有很多这个操作系统的部署最佳实践，因此，我们推荐客户在部署 TiDB 的时候使用 CentOS 7.3+ 以上的Linux 操作系统。 -#### 1.1.2 硬件要求 +#### 硬件要求 TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置有以下要求和建议： -##### 1.1.2.1 开发及测试环境 +##### 开发及测试环境 | **组件** | **CPU** | **内存** | **本地存储** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- | @@ -35,7 +35,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | | | | | | 服务器总计 | 4 | -##### 1.1.2.2 线上环境 +##### 线上环境 | **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- | @@ -45,15 +45,15 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | | | | | | 服务器总计 | 9 | -##### 1.1.2.3 2 块网卡的目的是？万兆的目的是？ +##### 2 块网卡的目的是？万兆的目的是？ 作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定，万兆可以保证数据传输的速度，千兆网卡容易出现瓶颈，我们强烈建议使用万兆网卡。 -##### 1.1.2.4 SSD 不做 RAID 是否可行？ +##### SSD 不做 RAID 是否可行？ 资源可接受的话，我们建议做 RAID 10，如果资源有限，也可以不做 RAID。 -##### 1.1.2.5 TiDB 集群各个组件的配置推荐？ +##### TiDB 集群各个组件的配置推荐？ - TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求，如果后期需要开启 Binlog，根据业务量的评估和 GC 时间的要求，也需要本地磁盘大一点，不要求 SSD 磁盘； - PD 里面存了集群元信息，会有频繁的读写请求，对磁盘 I/O 要求相对比较高，磁盘太差会影响整个集群性能，推荐 SSD 磁盘，空间不用太大。另外集群 Region 数量越多对 CPU、内存的要求越高； @@ -61,31 +61,31 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 详情可参考 [TiDB 软硬件环境需求](/hardware-and-software-requirements.md)。 -### 1.2 安装部署 +### 安装部署 -#### 1.2.1 推荐部署方式 +#### 推荐部署方式 [使用 TiUP 部署](/production-deployment-using-tiup.md)：如果用于生产环境，推荐使用 TiUP 部署 TiDB 集群。 -##### 1.2.1.1 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？ +##### 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？ 这种情况一般是因为没有使用 `--config` 参数来指定配置文件（目前只会出现在 binary 部署的场景），TiKV/PD 会按默认值来设置。如果要使用配置文件，请设置 TiKV/PD 的 `--config` 参数。对于 TiKV 组件，修改配置后重启服务即可；对于 PD 组件，只会在第一次启动时读取配置文件，之后可以使用 pd-ctl 的方式来修改配置，详情可参考 [PD 配置参数](/command-line-flags-for-pd-configuration.md)。 -##### 1.2.1.2 TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？ +##### TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？ 监控机建议单独部署。建议 CPU 8 core，内存 16 GB 以上，硬盘 500 GB 以上。 -##### 1.2.1.3 有一部分监控信息显示不出来？ +##### 有一部分监控信息显示不出来？ 查看访问监控的机器时间跟集群内机器的时间差，如果比较大，更正时间后即可显示正常。 -##### 1.2.1.4 supervise/svc/svstat 服务具体起什么作用？ +##### supervise/svc/svstat 服务具体起什么作用？ - supervise 守护进程 - svc 启停服务 - svstat 查看进程状态 -##### 1.2.1.5 inventory.ini 变量参数解读 +##### inventory.ini 变量参数解读 | **变量** | **含义** | | --- | --- | @@ -105,15 +105,15 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | enable_slow_query_log | TiDB 慢查询日志记录到单独文件({{ deploy_dir }}/log/tidb_slow_query.log)，默认为 False，记录到 tidb 日志 | | deploy_without_tidb | KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 inventory.ini 文件中 tidb_servers 主机组 IP 设置为空。 | -#### 1.2.2 TiDB 离线 Ansible 部署方案（4.0 版本后不推荐使用） +#### TiDB 离线 Ansible 部署方案（4.0 版本后不推荐使用） 首先这不是我们建议的方式，如果中控机没有外网，也可以通过离线 Ansible 部署方式，详情可参考[离线 TiDB Ansible 部署方案](/offline-deployment-using-ansible.md)。 -#### 1.2.3 Docker Compose 快速构建集群（单机部署） +#### Docker Compose 快速构建集群（单机部署） 使用 docker-compose 在本地一键拉起一个集群，包括集群监控，还可以根据需求自定义各个组件的软件版本和实例个数，以及自定义配置文件，这种只限于开发环境，详细可参考[官方文档](/deploy-test-cluster-using-docker-compose.md)。 -#### 1.2.4 如何单独记录 TiDB 中的慢查询日志，如何定位慢查询 SQL？ +#### 如何单独记录 TiDB 中的慢查询日志，如何定位慢查询 SQL？ 1）TiDB 中，对慢查询的定义在 tidb-ansible 的 `conf/tidb.yml` 配置文件中，`slow-threshold: 300`，这个参数是配置慢查询记录阈值的，单位是 ms。 @@ -126,17 +126,17 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 3）除了日志，还可以通过 `admin show slow` 命令查看，详情可参考 [`admin show slow` 命令](/identify-slow-queries.md#admin-show-slow-命令)。 -#### 1.2.5 首次部署 TiDB 集群时，没有配置 tikv 的 Label 信息，在后续如何添加配置 Label？ +#### 首次部署 TiDB 集群时，没有配置 tikv 的 Label 信息，在后续如何添加配置 Label？ TiDB 的 Label 设置是与集群的部署架构相关的，是集群部署中的重要内容，是 PD 进行全局管理和调度的依据。如果集群在初期部署过程中没有设置 Label，需要在后期对部署结构进行调整，就需要手动通过 PD 的管理工具 pd-ctl 来添加 location-labels 信息，例如：`config set location-labels "zone,rack,host"`（根据实际的 label 层级名字配置）。 pd-ctl 的使用参考 [PD Control 使用说明](/pd-control.md)。 -#### 1.2.6 为什么测试磁盘的 dd 命令用 oflag=direct 这个选项？ +#### 为什么测试磁盘的 dd 命令用 oflag=direct 这个选项？ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这样是为了绕开文件系统的缓存，可以直接测试磁盘的真实的 I/O 读写能力。 -#### 1.2.7 如何用 fio 命令测试 TiKV 实例的磁盘性能？ +#### 如何用 fio 命令测试 TiKV 实例的磁盘性能？ - 随机读测试： @@ -154,7 +154,7 @@ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这 ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randrw -percentage_random=100,0 -size=10G -filename=fio_randread_write_test.txt -name='fio mixed randread and sequential write test' -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_write_test.json ``` -#### 1.2.8 使用 TiDB Ansible 部署 TiDB 集群的时候，遇到 `UNREACHABLE! "msg": "Failed to connect to the host via ssh: "` 报错是什么原因？ +#### 使用 TiDB Ansible 部署 TiDB 集群的时候，遇到 `UNREACHABLE! "msg": "Failed to connect to the host via ssh: "` 报错是什么原因？ 有两种可能性： @@ -162,11 +162,11 @@ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这 - 如果涉及到单服务器分配了多角色的场景，例如多组件混合部署或单台服务器部署了多个 TiKV 实例，可能是由于 ssh 复用的机制引起这个报错，可以使用 `ansible … -f 1` 的选项来规避这个报错。 -## 二、集群管理 +## 集群管理 -### 2.1 集群日常管理 +### 集群日常管理 -#### 2.1.1 Ansible 常见运维操作有那些？ +#### Ansible 常见运维操作有那些？ | **任务** | **Playbook** | | --- | --- | @@ -179,42 +179,42 @@ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这 | 滚动升级除 PD 外模块 | ansible-playbook rolling\_update.yml --skip-tags=pd | | 滚动升级监控组件 | ansible-playbook rolling\_update\_monitor.yml | -#### 2.1.2 TiDB 如何登录？ +#### TiDB 如何登录？ 和 MySQL 登录方式一样，可以按照下面例子进行登录。 `mysql -h 127.0.0.1 -uroot -P4000` -#### 2.1.3 TiDB 如何修改数据库系统变量？ +#### TiDB 如何修改数据库系统变量？ 和 MySQL 一样，TiDB 也分为静态参数和固态参数，静态参数可以直接通过`set global xxx = n`的方式进行修改，不过新参数值只限于该实例生命周期有效。 -#### 2.1.4 TiDB (TiKV) 有哪些数据目录？ +#### TiDB (TiKV) 有哪些数据目录？ 默认在 [`--data-dir`](/command-line-flags-for-tikv-configuration.md#--data-dir) 目录下，其中包括 backup、db、raft、snap 四个目录，分别存储备份、数据、raft 数据及镜像数据。 -#### 2.1.5 TiDB 有哪些系统表？ +#### TiDB 有哪些系统表？ 和 MySQL 类似，TiDB 中也有系统表，用于存放数据库运行时所需信息，具体信息参考 [TiDB 系统数据库](/system-tables/system-table-overview.md)文档。 -#### 2.1.6 TiDB 各节点服务器下是否有日志文件，如何管理？ +#### TiDB 各节点服务器下是否有日志文件，如何管理？ 默认情况下各节点服务器会在日志中输出标准错误，如果启动的时候通过 `--log-file` 参数指定了日志文件，那么日志会输出到指定的文件中，并且按天做 rotation。 -#### 2.1.7 如何规范停止 TiDB？ +#### 如何规范停止 TiDB？ 如果是用 TiDB Ansible 部署的，可以使用 `ansible-playbook stop.yml` 命令停止 TiDB 集群。如果不是 TiDB Ansible 部署的，可以直接 kill 掉所有服务。如果使用 kill 命令，TiDB 的组件会做 graceful 的 shutdown。 -#### 2.1.8 TiDB 里面可以执行 kill 命令吗？ +#### TiDB 里面可以执行 kill 命令吗？ - 可以 kill DML 语句，首先使用 `show processlist`，找到对应 session 的 id，然后执行 `kill tidb [session id]`。 - 可以 kill DDL 语句，首先使用 `admin show ddl jobs`，查找需要 kill 的 DDL job ID，然后执行 `admin cancel ddl jobs 'job_id' [, 'job_id'] ...`。具体可以参考 [admin 操作](/sql-statements/sql-statement-admin.md)。 -#### 2.1.9 TiDB 是否支持会话超时？ +#### TiDB 是否支持会话超时？ TiDB 暂不支持数据库层面的会话超时，目前想要实现超时，在没 LB（Load Balancing）的时候，需要应用侧记录发起的 Session 的 ID，通过应用自定义超时，超时以后需要到发起 Query 的节点上用 `kill tidb [session id]` 来杀掉 SQL。目前建议使用应用程序来实现会话超时，当达到超时时间，应用层就会抛出异常继续执行后续的程序段。 -#### 2.1.10 TiDB 生产环境的版本管理策略是怎么样的？如何尽可能避免频繁升级？ +#### TiDB 生产环境的版本管理策略是怎么样的？如何尽可能避免频繁升级？ TiDB 版本目前逐步标准化，每次 Release 都包含详细的 Change log，版本功能[变化详情](https://github.com/pingcap/TiDB/releases)，生产环境是否有必要升级取决于业务系统，建议升级之前详细了解前后版本的功能差异。 @@ -224,18 +224,18 @@ TiDB 版本目前逐步标准化，每次 Release 都包含详细的 Change log - `1` 表示该版本 commit 1 次 - `ga80e796` 代表版本的 `git-hash` -#### 2.1.11 分不清 TiDB master 版本之间的区别，经常用错 TiDB Ansible 版本? +#### 分不清 TiDB master 版本之间的区别，经常用错 TiDB Ansible 版本? TiDB 目前社区非常活跃，在 1.0 GA 版本发布后，还在不断的优化和修改 BUG，因此 TiDB 的版本更新周期比较快，会不定期有新版本发布，请关注我们的[新版本发布官方网站](https://pingcap.com/weekly/)。此外 TiDB 安装推荐[使用 TiUP 进行安装](/production-deployment-using-tiup.md)。此外，在 TiDB 1.0 GA 版本后，对 TiDB 的版本号进行了统一管理，TiDB 的版本可以通过以下两种方式进行查看： - 通过 `select tidb_version()` 进行查看 - 通过执行 `tidb-server -V` 进行查看 -#### 2.1.12 有没有图形化部署 TiDB 的工具？ +#### 有没有图形化部署 TiDB 的工具？ 暂时没有。 -#### 2.1.13 TiDB 如何进行水平扩展？ +#### TiDB 如何进行水平扩展？ 当您的业务不断增长时，数据库可能会面临三方面瓶颈，第一是存储空间，第二是计算资源，第三是读写容量，这时可以对 TiDB 集群做水平扩展。 @@ -243,68 +243,68 @@ TiDB 目前社区非常活跃，在 1.0 GA 版本发布后，还在不断的优 - 如果是计算资源不够，可以查看 TiDB Server 和 TiKV Server 节点的 CPU 消耗情况，再考虑添加 TiDB Server 节点或者是 TiKV Server 节点来解决，如添加 TiDB Server 节点，将其添加到前端 Load Balancer 配置之中即可。 - 如果是容量跟不上，一般可以考虑同时增加 TiDB Server 和 TiKV Server 节点。 -#### 2.1.14 Percolator 用了分布式锁，crash 的客户端会保持锁，会造成锁没有 release？ +#### Percolator 用了分布式锁，crash 的客户端会保持锁，会造成锁没有 release？ 详细可参考 [Percolator 和 TiDB 事务算法](https://pingcap.com/blog-cn/percolator-and-txn/)。 -#### 2.1.15 TiDB 为什么选用 gRPC 而不选用 Thrift，是因为 Google 在用吗？ +#### TiDB 为什么选用 gRPC 而不选用 Thrift，是因为 Google 在用吗？ 不只是因为 Google 在用，有一些比较好的特性我们需要，比如流控、加密还有 Streaming。 -#### 2.1.16 like(bindo.customers.name, jason%, 92) 这个92代表什么？ +#### like(bindo.customers.name, jason%, 92) 这个92代表什么？ 那个是转义字符，默认是 (ASCII 92)。 -#### 2.1.17 为什么 `information_schema.tables.data_length` 记录的大小和 TiKV 监控面板上的 store size 不一样？ +#### 为什么 `information_schema.tables.data_length` 记录的大小和 TiKV 监控面板上的 store size 不一样？ 这是因为两者计算的角度不一样。`information_schema.tables.data_length` 是通过统计信息（平均每行的大小）得到的估算值。TiKV 监控面板上的 store size 是单个 TiKV 实例的数据文件（RocksDB 的 SST 文件）的大小总和。由于多版本和 TiKV 会压缩数据，所以两者显示的大小不一样。 -### 2.2 PD 管理 +### PD 管理 -#### 2.2.1 访问 PD 报错：TiKV cluster is not bootstrapped +#### 访问 PD 报错：TiKV cluster is not bootstrapped PD 的大部分 API 需要在初始化 TiKV 集群以后才能使用，如果在部署新集群的时候只启动了 PD，还没有启动 TiKV，这时候访问 PD 就会报这个错误。遇到这个错误应该先把要部署的 TiKV 启动起来，TiKV 会自动完成初始化工作，然后就可以正常访问 PD。 -#### 2.2.2 PD 启动报错：etcd cluster ID mismatch +#### PD 启动报错：etcd cluster ID mismatch PD 启动参数中的 `--initial-cluster` 包含了某个不属于该集群的成员。遇到这个错误时请检查各个成员的所属集群，剔除错误的成员后即可正常启动。 -#### 2.2.3 PD 能容忍的时间同步误差是多少？ +#### PD 能容忍的时间同步误差是多少？ 理论上，时间同步误差越小越好。PD 可容忍任意时长的误差，但是，时间同步误差越大意味着 PD 分配的时间戳与真实的物理时间相差越大，这个差距会影响读历史版本等功能。 -#### 2.2.4 Client 连接是如何寻找 PD 的？ +#### Client 连接是如何寻找 PD 的？ Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD 与 TiKV 对 Client 透明。当 TiDB 连接任意一台 PD 的时候，PD 会告知 TiDB 当前的 leader 是谁，如果此台 PD 不是 leader，TiDB 将会重新连接至 leader PD。 -#### 2.2.5 PD 参数中 leader-schedule-limit 和 region-schedule-limit 调度有什么区别？ +#### PD 参数中 leader-schedule-limit 和 region-schedule-limit 调度有什么区别？ - leader-schedule-limit 调度是用来均衡不同 TiKV 的 leader 数，影响处理查询的负载。 - region-schedule-limit 调度是均衡不同 TiKV 的副本数，影响不同节点的数据量。 -#### 2.2.6 每个 region 的 replica 数量可配置吗？调整的方法是？ +#### 每个 region 的 replica 数量可配置吗？调整的方法是？ 可以，目前只能调整全局的 replica 数量。首次启动时 PD 会读配置文件（conf/pd.yml），使用其中的 max-replicas 配置，之后修改需要使用 pd-ctl 配置命令 `config set max-replicas $num`，配置后可通过 `config show all` 来查看已生效的配置。调整的时候，不会影响业务，会在后台添加，注意总 TiKV 实例数总是要大于等于设置的副本数，例如 3 副本需要至少 3 个 TiKV。增加副本数量之前需要预估额外的存储需求。pd-ctl 的详细用法可参考 [PD Control 使用说明](/pd-control.md)。 -#### 2.2.7 缺少命令行集群管理工具，整个集群的健康度当前是否正常，不好确认？ +#### 缺少命令行集群管理工具，整个集群的健康度当前是否正常，不好确认？ 可以通过 pd-ctl 等工具来判断集群大概的状态，详细的集群状态还是需要通过监控来确认。 -#### 2.2.8 集群下线节点后，怎么删除老集群节点监控信息？ +#### 集群下线节点后，怎么删除老集群节点监控信息？ 下线节点一般指 TiKV 节点通过 pd-ctl 或者监控判断节点是否下线完成。节点下线完成后，手动停止下线节点上相关的服务。从 Prometheus 配置文件中删除对应节点的 node_exporter 信息。从 Ansible inventory.ini 中删除对应节点的信息。 -#### 2.2.9 使用 PD Control 连接 PD Server 时，为什么只能通过本机 IP 连接，不能通过 127.0.0.1 连接？ +#### 使用 PD Control 连接 PD Server 时，为什么只能通过本机 IP 连接，不能通过 127.0.0.1 连接？ 因为使用 TiDB Ansible 部署的集群，PD 对外服务端口不会绑定到 127.0.0.1，所以 PD Control 不会识别 127.0.0.1。 -### 2.3 TiDB server 管理 +### TiDB server 管理 -#### 2.2.1 TiDB 的 lease 参数应该如何设置？ +#### TiDB 的 lease 参数应该如何设置？ 启动 TiDB Server 时，需要通过命令行参数设置 lease 参数（--lease=60），其值会影响 DDL 的速度（只会影响当前执行 DDL 的 session，其他的 session 不会受影响）。在测试阶段，lease 的值可以设为 1s，加快测试进度；在生产环境下，我们推荐这个值设为分钟级（一般可以设为 60），这样可以保证 DDL 操作的安全。 -#### 2.2.2 DDL 在正常情况下的耗时是多少？ +#### DDL 在正常情况下的耗时是多少？ 一般情况下处理一个 DDL 操作（之前没有其他 DDL 操作在处理）的耗时基本可以分如下为三种： @@ -314,7 +314,7 @@ Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD 此外，如果接收 DDL 请求的 TiDB 和 DDL owner 所处的 TiDB 是一台，那么上面列举的第一和第三种可能的耗时应该在几十到几百毫秒。 -#### 2.2.3 为什么有的时候执行 DDL 会很慢？ +#### 为什么有的时候执行 DDL 会很慢？ 可能原因如下： @@ -323,53 +323,53 @@ Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD - 由于停 TiDB 时不能与 PD 正常通信（包括停电情况）或者用 `kill -9` 指令停 TiDB 导致 TiDB 没有及时从 PD 清理注册数据，那么会影响 TiDB 启动后 10min 内的 DDL 语句处理时间。这段时间内运行 DDL 语句时，每个 DDL 状态变化都需要等待 2 * lease（默认 lease = 45s）。 - 当集群中某个 TiDB 与 PD 之间发生通信问题，即 TiDB 不能从 PD 及时获取或更新版本信息，那么这时候 DDL 操作的每个状态处理需要等待 2 * lease。 -#### 2.2.4 TiDB 可以使用 S3 作为后端存储吗？ +#### TiDB 可以使用 S3 作为后端存储吗？ 不可以，目前 TiDB 只支持分布式存储引擎和 GolevelDB/RocksDB/BoltDB 引擎。 -#### 2.2.5 Information_schema 能否支持更多真实信息？ +#### Information_schema 能否支持更多真实信息？ Information_schema 库里面的表主要是为了兼容 MySQL 而存在，有些第三方软件会查询里面的信息。在目前 TiDB 的实现中，里面大部分只是一些空表。后续随着 TiDB 的升级，会提供更多的参数信息。当前 TiDB 支持的 Information\_schema 请参考 [TiDB 系统数据库说明文档](/system-tables/system-table-information-schema.md)。 -#### 2.2.6 TiDB Backoff type 主要原因? +#### TiDB Backoff type 主要原因? TiDB-server 与 TiKV-server 随时进行通信，在进行大量数据操作过程中，会出现 `Server is busy` 或者 `backoff.maxsleep 20000ms` 的日志提示信息，这是由于 TiKV-server 在处理过程中系统比较忙而出现的提示信息，通常这时候可以通过系统资源监控到 TiKV 主机系统资源使用率比较高的情况出现。如果这种情况出现，可以根据资源使用情况进行相应的扩容操作。 -#### 2.2.7 TiDB TiClient type 主要原因？ +#### TiDB TiClient type 主要原因？ TiClient Region Error 该指标描述的是在 TiDB-server 作为客户端通过 KV 接口访问 TiKV-server 进行数据操作过程中，TiDB-server 操作 TiKV-server 中的 Region 数据出现的错误类型与 metric 指标，错误类型包括 not_leader、stale_epoch。出现这些错误的情况是当 TiDB-server 根据自己的缓存信息去操作 Region leader 数据的时候，Region leader 发生了迁移或者 TiKV 当前的 Region 信息与 TiDB 缓存的路由信息不一致而出现的错误提示。一般这种情况下，TiDB-server 都会自动重新从 PD 获取最新的路由数据，重做之前的操作。 -#### 2.2.8 TiDB 同时支持的最大并发连接数？ +#### TiDB 同时支持的最大并发连接数？ 当前版本 TiDB 没有最大连接数的限制，如果并发过大导致响应时间增加，可以通过增加 TiDB 节点进行扩容。 -#### 2.2.9 如何查看某张表创建的时间？ +#### 如何查看某张表创建的时间？ information_schema 库中的 tables 表里的 create_time 即为表的真实创建时间。 -#### 2.2.9 TiDB 的日志中 EXPENSIVE_QUERY 是什么意思？ +#### TiDB 的日志中 EXPENSIVE_QUERY 是什么意思？ TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条数据就认为这条 query 是 expensive query。可以通过修改 tidb-server 配置参数来对这个门限值进行调整，调整后需要重新启动 tidb-server。 -### 2.4 TiKV 管理 +### TiKV 管理 -#### 2.4.1 TiKV 集群副本建议配置数量是多少，是不是最小高可用配置（3个）最好？ +#### TiKV 集群副本建议配置数量是多少，是不是最小高可用配置（3个）最好？ 如果是测试环境 3 副本足够；在生产环境中，不可让集群副本数低于 3，需根据架构特点、业务系统及恢复能力的需求，适当增加副本数。值得注意的是，副本升高，性能会有下降，但是安全性更高。 -#### 2.4.2 TiKV 启动报错：cluster ID mismatch +#### TiKV 启动报错：cluster ID mismatch TiKV 本地存储的 cluster ID 和指定的 PD 的 cluster ID 不一致。在部署新的 PD 集群的时候，PD 会随机生成一个 cluster ID，TiKV 第一次初始化的时候会从 PD 获取 cluster ID 存储在本地，下次启动的时候会检查本地的 cluster ID 与 PD 的 cluster ID 是否一致，如果不一致则会报错并退出。出现这个错误一个常见的原因是，用户原先部署了一个集群，后来把 PD 的数据删除了并且重新部署了新的 PD，但是 TiKV 还是使用旧的数据重启连到新的 PD 上，就会报这个错误。 -#### 2.4.3 TiKV 启动报错：duplicated store address +#### TiKV 启动报错：duplicated store address 启动参数中的地址已经被其他的 TiKV 注册在 PD 集群中了。造成该错误的常见情况：TiKV `--data-dir` 指定的路径下没有数据文件夹（删除或移动后没有更新 --data-dir），用之前参数重新启动该 TiKV。请尝试用 pd-ctl 的 [store delete](https://github.com/pingcap/pd/tree/55db505e8f35e8ab4e00efd202beb27a8ecc40fb/tools/pd-ctl#store-delete--label--weight-store_id----jqquery-string) 功能，删除之前的 store，然后重新启动 TiKV 即可。 -#### 2.4.4 TiKV master 和 slave 用的是一样的压缩算法，为什么效果不一样? +#### TiKV master 和 slave 用的是一样的压缩算法，为什么效果不一样? 目前来看 master 有些文件的压缩率会高一些，这个取决于底层数据的分布和 RocksDB 的实现，数据大小偶尔有些波动是正常的，底层存储引擎会根据需要调整数据。 -#### 2.4.5 TiKV block cache 有哪些特性？ +#### TiKV block cache 有哪些特性？ TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在默认 RocksDB 内部的 default、write、lock 3 个 CF 内。 @@ -380,50 +380,50 @@ TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在 - 所有 CF 共享一个 Block-cache，用于缓存数据块，加速 RocksDB 的读取速度，Block-cache 的大小通过参数 `block-cache-size` 控制，`block-cache-size` 越大，能够缓存的热点数据越多，对读取操作越有利，同时占用的系统内存也会越多。 - 每个 CF 有各自的 Write-buffer，大小通过 `write-buffer-size` 控制。 -#### 2.4.6 TiKV channel full 是什么原因？ +#### TiKV channel full 是什么原因？ - Raftstore 线程太忙，或者因 I/O 而卡住。可以看一下 Raftstore 的 CPU 使用情况。 - TiKV 过忙（CPU、磁盘 I/O 等），请求处理不过来。 -#### 2.4.7 TiKV 频繁切换 Region leader 是什么原因？ +#### TiKV 频繁切换 Region leader 是什么原因？ - 网络问题导致节点间通信卡了，查看 Report failures 监控。 - 原主 Leader 的节点卡了，导致没有及时给 Follower 发送消息。 - Raftstore 线程卡了。 -#### 2.4.8 如果一个节点挂了会影响服务吗？影响会持续多久？ +#### 如果一个节点挂了会影响服务吗？影响会持续多久？ TiDB 使用 Raft 在多个副本之间做数据同步（默认为每个 Region 3 个副本）。当一份备份出现问题时，其他的副本能保证数据的安全。根据 Raft 协议，当某个节点挂掉导致该节点里的 Leader 失效时，在最大 2 * lease time（leasetime 是 10 秒）时间后，通过 Raft 协议会很快将一个另外一个节点里的 Follower 选为新的 Region Leader 来提供服务。 -#### 2.4.9 TiKV 在分别在那些场景下占用大量 IO、内存、CPU（超过参数配置的多倍）？ +#### TiKV 在分别在那些场景下占用大量 IO、内存、CPU（超过参数配置的多倍）？ 在大量写入、读取的场景中会占用大量的磁盘 IO、内存、CPU。在执行很复杂的查询，比如会产生很大中间结果集的情况下，会消耗很多的内存和 CPU 资源。 -#### 2.4.10 TiKV 是否可以使用 SAS/SATA 盘或者进行 SSD/SAS 混合部署？ +#### TiKV 是否可以使用 SAS/SATA 盘或者进行 SSD/SAS 混合部署？ 不可以使用，TiDB 在进行 OLTP 场景中，数据访问和操作需要高 IO 磁盘的支持，TiDB 作为强一致的分布式数据库，存在一定的写放大，如副本复制、存储底层 Compaction，因此，TiDB 部署的最佳实践中推荐用户使用 NVMe SSD 磁盘作为数据存储磁盘。另外，TiKV 与 PD 不能混合部署。 -#### 2.4.11 数据表 Key 的 Range 范围划分是在数据接入之前就已经划分好了吗？ +#### 数据表 Key 的 Range 范围划分是在数据接入之前就已经划分好了吗？ 不是的，这个和 MySQL 分表规则不一样，需要提前设置好，TiKV 是根据 Region 的大小动态分裂的。 -#### 2.4.12 Region 是如何进行分裂的？ +#### Region 是如何进行分裂的？ Region 不是前期划分好的，但确实有 Region 分裂机制。当 Region 的大小超过参数 `region-max-size` 或 `region-max-keys` 的值时，就会触发分裂，分裂后的信息会汇报给 PD。 -#### 2.4.13 TiKV 是否有类似 MySQL 的 `innodb_flush_log_trx_commit` 参数，来保证提交数据不丢失？ +#### TiKV 是否有类似 MySQL 的 `innodb_flush_log_trx_commit` 参数，来保证提交数据不丢失？ 是的，TiKV 单机的存储引擎目前使用两个 RocksDB 实例，其中一个存储 raft-log，TiKV 有个 sync-log 参数，在 ture 的情况下，每次提交都会强制刷盘到 raft-log，如果发生 crash 后，通过 raft-log 进行 KV 数据的恢复。 -#### 2.4.14 对 WAL 存储有什么推荐的硬件配置，例如 SSD，RAID 级别，RAID 卡 cache 策略，NUMA 设置，文件系统选择，操作系统的 IO 调度策略等？ +#### 对 WAL 存储有什么推荐的硬件配置，例如 SSD，RAID 级别，RAID 卡 cache 策略，NUMA 设置，文件系统选择，操作系统的 IO 调度策略等？ WAL 属于顺序写，目前我们并没有单独对他进行配置，建议 SSD，RAID 如果允许的话，最好是 RAID 10，RAID 卡 cache、操作系统 I/O 调度目前没有针对性的最佳实践，Linux 7 以上默认配置即可，NUMA 没有特别建议，NUMA 内存分配策略可以尝试使用 `interleave = all`，文件系统建议 ext4。 -#### 2.4.15 在最严格的 `sync-log = true` 数据可用模式下，写入性能如何？ +#### 在最严格的 `sync-log = true` 数据可用模式下，写入性能如何？ 一般来说，开启 `sync-log` 会让性能损耗 30% 左右。关闭 `sync-log` 时的性能表现，请参见 [TiDB Sysbench 性能测试报告](/benchmark/v3.0-performance-benchmarking-with-sysbench.md)。 -#### 2.4.16 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠，单机存储引擎是否需要最严格模式？ +#### 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠，单机存储引擎是否需要最严格模式？ 通过使用 [Raft 一致性算法](https://raft.github.io/)，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）。但理论上两个节点也可能同时发生故障，所以除非是对性能要求高于数据安全的场景，一般都强烈推荐开启 `sync-log`。 @@ -431,53 +431,53 @@ WAL 属于顺序写，目前我们并没有单独对他进行配置，建议 SSD 对于单机存储引擎也同样推荐打开 `sync-log` 模式。否则如果节点宕机可能会丢失最后一次写入数据。 -#### 2.4.17 使用 Raft 协议，数据写入会有多次网络的 roundtrip，实际写入延迟如何？ +#### 使用 Raft 协议，数据写入会有多次网络的 roundtrip，实际写入延迟如何？ 理论上，和单机数据库相比，数据写入会多四个网络延迟。 -#### 2.4.18 有没有类似 MySQL 的 InnoDB Memcached plugin，可以直接使用 KV 接口，可以不需要独立的 Cache？ +#### 有没有类似 MySQL 的 InnoDB Memcached plugin，可以直接使用 KV 接口，可以不需要独立的 Cache？ TiKV 支持单独进行接口调用，理论上也可以起个实例做为 Cache，但 TiDB 最大的价值是分布式关系型数据库，我们原则上不对 TiKV 单独进行支持。 -#### 2.4.19 Coprocessor 组件的主要作用？ +#### Coprocessor 组件的主要作用？ - 减少 TiDB 与 TiKV 之间的数据传输。 - 计算下推，充分利用 TiKV 的分布式计算资源。 -#### 2.4.20 IO error: No space left on device While appending to file +#### IO error: No space left on device While appending to file 这是磁盘空间不足导致的，需要加节点或者扩大磁盘空间。 -#### 2.4.21 为什么 TiKV 容易出现 OOM？ +#### 为什么 TiKV 容易出现 OOM？ TiKV 的内存占用主要来自于 RocksDB 的 block-cache，默认为系统总内存的 40%。当 TiKV 容易出现 OOM 时，检查 `block-cache-size` 配置是否过高。还需要注意，当单机部署了多个 TiKV 实例时，需要显式地配置该参数，以防止多个实例占用过多系统内存导致 OOM。 -#### 2.4.22 TiDB 数据和 RawKV 数据可存储于同一个 TiKV 集群里吗？ +#### TiDB 数据和 RawKV 数据可存储于同一个 TiKV 集群里吗？ 不可以。TiDB 数据（或使用其他事务 API 生成的数据）依赖于一种特殊的键值格式，和 RawKV API 数据（或其他基于 RawKV 的服务生成的数据）并不兼容。 -### 2.5 TiDB 测试 +### TiDB 测试 -#### 2.5.1 TiDB Sysbench 基准测试结果如何？ +#### TiDB Sysbench 基准测试结果如何？ 很多用户在接触 TiDB 都习惯做一个基准测试或者 TiDB 与 MySQL 的对比测试，官方也做了一个类似测试，汇总很多测试结果后，我们发现虽然测试的数据有一定的偏差，但结论或者方向基本一致，由于 TiDB 与 MySQL 由于架构上的差别非常大，很多方面是很难找到一个基准点，所以官方的建议两点： - 大家不要用过多精力纠结这类基准测试上，应该更多关注 TiDB 的场景上的区别。 - 大家可以直接参考 [TiDB Sysbench 性能测试报告](/benchmark/v3.0-performance-benchmarking-with-sysbench.md)。 -#### 2.5.2 TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？ +#### TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？ - 在 10 节点内，TiDB 写入能力（Insert TPS）和节点数量基本成 40% 线性递增，MySQL 由于是单节点写入，所以不具备写入扩展能力。 - MySQL 读扩容可以通过添加从库进行扩展，但写流量无法扩展，只能通过分库分表，而分库分表有很多问题，具体参考[方案虽好，成本先行：数据库 Sharding+Proxy 实践解析](http://t.cn/RTD18qV)。 - TiDB 不管是读流量、还是写流量都可以通过添加节点快速方便的进行扩展。 -#### 2.5.3 我们的 DBA 测试过 MySQL 性能，单台 TiDB 的性能没有 MySQL 性能那么好？ +#### 我们的 DBA 测试过 MySQL 性能，单台 TiDB 的性能没有 MySQL 性能那么好？ TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做的分库分表的场景，或者需要强一致性和完整分布式事务的场景。它的优势是通过尽量下推到存储节点进行并行计算。对于小表（比如千万级以下），不适合 TiDB，因为数据量少，Region 有限，发挥不了并行的优势，最极端的就是计数器表，几行记录高频更新，这几行在 TiDB 里，会变成存储引擎上的几个 KV，然后只落在一个 Region 里，而这个 Region 只落在一个节点上。加上后台强一致性复制的开销，TiDB 引擎到 TiKV 引擎的开销，最后表现出来的就是没有单个 MySQL 好。 -### 2.6 TiDB 备份恢复 +### TiDB 备份恢复 -#### 2.6.1 TiDB 主要备份方式？ +#### TiDB 主要备份方式？ 目前，推荐的备份方式是使用 [PingCAP fork 的 Mydumper](/mydumper-overview.md)。尽管 TiDB 也支持使用 MySQL 官方工具 `mysqldump` 进行数据备份、恢复，但其性能低于 [`mydumper`](/mydumper-overview.md)/[`loader`](/loader-overview.md)，并且该工具备份、恢复大量数量时，要耗费更多时间。 @@ -485,21 +485,21 @@ TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做的分库 loader 的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调整，例如 3 个 TiKV 的场景， 此值可以设为 3 * (1 ～ n)，当 TiKV 负载过高，loader 以及 TiDB 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 TiKV 负载不是太高的时候，可以适当调大该值。 -## 三、监控 +## 监控 -### 3.1 Prometheus 监控框架 +### Prometheus 监控框架 详细参考 [TiDB 监控框架概述](/tidb-monitoring-framework.md)。 -### 3.2 监控指标解读 +### 监控指标解读 详细参考 [重要监控指标详解](/grafana-overview-dashboard.md)。 -#### 3.2.1 目前的监控使用方式及主要监控指标，有没有更好看的监控？ +#### 目前的监控使用方式及主要监控指标，有没有更好看的监控？ TiDB 使用 Prometheus + Grafana 组成 TiDB 数据库系统的监控系统，用户在 Grafana 上通过 dashboard 可以监控到 TiDB 的各类运行指标，包括系统资源的监控指标，包括客户端连接与 SQL 运行的指标，包括内部通信和 Region 调度的指标，通过这些指标，可以让数据库管理员更好的了解到系统的运行状态，运行瓶颈等内容。在监控指标的过程中，我们按照 TiDB 不同的模块，分别列出了各个模块重要的指标项，一般用户只需要关注这些常见的指标项。具体指标请参见[官方文档](/grafana-overview-dashboard.md)。 -#### 3.2.2 Prometheus 监控数据默认 15 天自动清除一次，可以自己设定成 2 个月或者手动删除吗？ +#### Prometheus 监控数据默认 15 天自动清除一次，可以自己设定成 2 个月或者手动删除吗？ 可以的，在 Prometheus 启动的机器上，找到启动脚本，然后修改启动参数，然后重启 Prometheus 生效。 @@ -507,15 +507,15 @@ TiDB 使用 Prometheus + Grafana 组成 TiDB 数据库系统的监控系统， --storage.tsdb.retention="60d" ``` -#### 3.2.3 Region Health 监控项 +#### Region Health 监控项 TiDB-2.0 版本中，PD metric 监控页面中，对 Region 健康度进行了监控，其中 Region Health 监控项是对所有 Region 副本状况的一些统计。其中 miss 是缺副本，extra 是多副本。同时也增加了按 Label 统计的隔离级别，level-1 表示这些 Region 的副本在第一级 Label 下是物理隔离的，没有配置 location label 时所有 Region 都在 level-0。 -#### 3.2.4 Statement Count 监控项中的 selectsimplefull 是什么意思？ +#### Statement Count 监控项中的 selectsimplefull 是什么意思？ 代表全表扫，但是可能是很小的系统表。 -#### 3.2.5 监控上的 QPS 和 Statement OPS 有什么区别？ +#### 监控上的 QPS 和 Statement OPS 有什么区别？ QPS 会统计执行的所有 SQL 命令，包括 use database、load data、begin、commit、set、show、insert、select 等。 From be87c44f89824649d75bc0a9eff409c0d94f5bd4 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Mon, 25 May 2020 19:46:02 +0800 Subject: [PATCH 4/5] refine heading levels --- faq/deploy-and-maintain-faq.md | 87 ++++++++++++++++------------------ 1 file changed, 41 insertions(+), 46 deletions(-) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 85554259fa2c..088ae2e6132d 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -6,27 +6,29 @@ category: FAQ # 部署运维 FAQ -## 安装部署 +本文介绍 TiDB 集群运维部署的常见问题、原因及解决方法。 -### 环境准备 +## 环境准备 FAQ -#### 操作系统版本要求 +操作系统版本要求如下表： -| **Linux 操作系统平台** | **版本** | -| --- | --- | +| Linux 操作系统平台 | 版本 | +| :--- | :--- | | Red Hat Enterprise Linux | 7.3 及以上 | | CentOS | 7.3 及以上 | | Oracle Enterprise Linux | 7.3 及以上 | -##### 为什么要在 CentOS 7 上部署 TiDB 集群？ +### 为什么要在 CentOS 7 上部署 TiDB 集群？ + +TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络，作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境，具体可以参考 TiDB 的[官方部署要求](/hardware-and-software-requirements.md)。 -TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络，作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境，具体可以参考 TiDB 的[官方部署要求](/hardware-and-software-requirements.md)。其中 TiDB 在 CentOS 7.3 的环境下进行大量的测试，同时也有很多这个操作系统的部署最佳实践，因此，我们推荐客户在部署 TiDB 的时候使用 CentOS 7.3+ 以上的Linux 操作系统。 +其中 TiDB 在 CentOS 7.3 的环境下进行大量的测试，同时也有很多这个操作系统的部署最佳实践，因此，我们推荐客户在部署 TiDB 的时候使用 CentOS 7.3+ 以上的Linux 操作系统。 -#### 硬件要求 +## 硬件要求 FAQ -TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置有以下要求和建议： +TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发、测试、及生产环境的服务器硬件配置有以下要求和建议： -##### 开发及测试环境 +**开发及测试环境** | **组件** | **CPU** | **内存** | **本地存储** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- | @@ -35,7 +37,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | | | | | | 服务器总计 | 4 | -##### 线上环境 +**线上环境** | **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- | @@ -45,47 +47,45 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | 监控 | 8核+ | 16 GB+ | SAS | 千兆网卡 | 1 | | | | | | 服务器总计 | 9 | -##### 2 块网卡的目的是？万兆的目的是？ +### 两块网卡的目的是？万兆的目的是？ -作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定，万兆可以保证数据传输的速度，千兆网卡容易出现瓶颈，我们强烈建议使用万兆网卡。 +作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。两块网卡可以做 bond，保证数据传输的稳定，万兆可以保证数据传输的速度，千兆网卡容易出现瓶颈，我们强烈建议使用万兆网卡。 -##### SSD 不做 RAID 是否可行？ +### SSD 不做 RAID 是否可行？ 资源可接受的话，我们建议做 RAID 10，如果资源有限，也可以不做 RAID。 -##### TiDB 集群各个组件的配置推荐？ +### TiDB 集群各个组件的配置推荐？ -- TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求，如果后期需要开启 Binlog，根据业务量的评估和 GC 时间的要求，也需要本地磁盘大一点，不要求 SSD 磁盘； +- TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求，如果后期需要开启 TiDB Binlog，根据业务量的评估和 GC 时间的要求，也需要本地磁盘大一点，不要求 SSD 磁盘； - PD 里面存了集群元信息，会有频繁的读写请求，对磁盘 I/O 要求相对比较高，磁盘太差会影响整个集群性能，推荐 SSD 磁盘，空间不用太大。另外集群 Region 数量越多对 CPU、内存的要求越高； - TiKV 对 CPU、内存、磁盘要求都比较高，一定要用 SSD 磁盘。 详情可参考 [TiDB 软硬件环境需求](/hardware-and-software-requirements.md)。 -### 安装部署 - -#### 推荐部署方式 +## 安装部署 FAQ -[使用 TiUP 部署](/production-deployment-using-tiup.md)：如果用于生产环境，推荐使用 TiUP 部署 TiDB 集群。 +如果用于生产环境，推荐使用 TiUP [使用 TiUP 部署](/production-deployment-using-tiup.md) TiDB 集群。 -##### 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？ +### 为什么修改了 TiKV/PD 的 toml 配置文件，却没有生效？ 这种情况一般是因为没有使用 `--config` 参数来指定配置文件（目前只会出现在 binary 部署的场景），TiKV/PD 会按默认值来设置。如果要使用配置文件，请设置 TiKV/PD 的 `--config` 参数。对于 TiKV 组件，修改配置后重启服务即可；对于 PD 组件，只会在第一次启动时读取配置文件，之后可以使用 pd-ctl 的方式来修改配置，详情可参考 [PD 配置参数](/command-line-flags-for-pd-configuration.md)。 -##### TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？ +### TiDB 监控框架 Prometheus + Grafana 监控机器建议单独还是多台部署？ 监控机建议单独部署。建议 CPU 8 core，内存 16 GB 以上，硬盘 500 GB 以上。 -##### 有一部分监控信息显示不出来？ +### 有一部分监控信息显示不出来？ 查看访问监控的机器时间跟集群内机器的时间差，如果比较大，更正时间后即可显示正常。 -##### supervise/svc/svstat 服务具体起什么作用？ +### supervise/svc/svstat 服务具体起什么作用？ - supervise 守护进程 - svc 启停服务 - svstat 查看进程状态 -##### inventory.ini 变量参数解读 +### inventory.ini 变量参数解读 | **变量** | **含义** | | --- | --- | @@ -105,15 +105,15 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | enable_slow_query_log | TiDB 慢查询日志记录到单独文件({{ deploy_dir }}/log/tidb_slow_query.log)，默认为 False，记录到 tidb 日志 | | deploy_without_tidb | KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 inventory.ini 文件中 tidb_servers 主机组 IP 设置为空。 | -#### TiDB 离线 Ansible 部署方案（4.0 版本后不推荐使用） +### TiDB 离线 Ansible 部署方案（4.0 版本后不推荐使用） 首先这不是我们建议的方式，如果中控机没有外网，也可以通过离线 Ansible 部署方式，详情可参考[离线 TiDB Ansible 部署方案](/offline-deployment-using-ansible.md)。 -#### Docker Compose 快速构建集群（单机部署） +### Docker Compose 快速构建集群（单机部署） 使用 docker-compose 在本地一键拉起一个集群，包括集群监控，还可以根据需求自定义各个组件的软件版本和实例个数，以及自定义配置文件，这种只限于开发环境，详细可参考[官方文档](/deploy-test-cluster-using-docker-compose.md)。 -#### 如何单独记录 TiDB 中的慢查询日志，如何定位慢查询 SQL？ +### 如何单独记录 TiDB 中的慢查询日志，如何定位慢查询 SQL？ 1）TiDB 中，对慢查询的定义在 tidb-ansible 的 `conf/tidb.yml` 配置文件中，`slow-threshold: 300`，这个参数是配置慢查询记录阈值的，单位是 ms。 @@ -126,17 +126,17 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 3）除了日志，还可以通过 `admin show slow` 命令查看，详情可参考 [`admin show slow` 命令](/identify-slow-queries.md#admin-show-slow-命令)。 -#### 首次部署 TiDB 集群时，没有配置 tikv 的 Label 信息，在后续如何添加配置 Label？ +### 首次部署 TiDB 集群时，没有配置 tikv 的 Label 信息，在后续如何添加配置 Label？ TiDB 的 Label 设置是与集群的部署架构相关的，是集群部署中的重要内容，是 PD 进行全局管理和调度的依据。如果集群在初期部署过程中没有设置 Label，需要在后期对部署结构进行调整，就需要手动通过 PD 的管理工具 pd-ctl 来添加 location-labels 信息，例如：`config set location-labels "zone,rack,host"`（根据实际的 label 层级名字配置）。 pd-ctl 的使用参考 [PD Control 使用说明](/pd-control.md)。 -#### 为什么测试磁盘的 dd 命令用 oflag=direct 这个选项？ +### 为什么测试磁盘的 dd 命令用 `oflag=direct` 这个选项？ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这样是为了绕开文件系统的缓存，可以直接测试磁盘的真实的 I/O 读写能力。 -#### 如何用 fio 命令测试 TiKV 实例的磁盘性能？ +### 如何用 fio 命令测试 TiKV 实例的磁盘性能？ - 随机读测试： @@ -154,7 +154,7 @@ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这 ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randrw -percentage_random=100,0 -size=10G -filename=fio_randread_write_test.txt -name='fio mixed randread and sequential write test' -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_write_test.json ``` -#### 使用 TiDB Ansible 部署 TiDB 集群的时候，遇到 `UNREACHABLE! "msg": "Failed to connect to the host via ssh: "` 报错是什么原因？ +### 使用 TiDB Ansible 部署 TiDB 集群的时候，遇到 `UNREACHABLE! "msg": "Failed to connect to the host via ssh: "` 报错是什么原因？ 有两种可能性： @@ -162,7 +162,7 @@ Direct 模式就是把写入请求直接封装成 I/O 指令发到磁盘，这 - 如果涉及到单服务器分配了多角色的场景，例如多组件混合部署或单台服务器部署了多个 TiKV 实例，可能是由于 ssh 复用的机制引起这个报错，可以使用 `ansible … -f 1` 的选项来规避这个报错。 -## 集群管理 +## 集群管理 FAQ ### 集群日常管理 @@ -485,21 +485,16 @@ TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做的分库 loader 的 -t 参数可以根据 TiKV 的实例个数以及负载进行评估调整，例如 3 个 TiKV 的场景， 此值可以设为 3 * (1 ～ n)，当 TiKV 负载过高，loader 以及 TiDB 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 TiKV 负载不是太高的时候，可以适当调大该值。 -## 监控 - -### Prometheus 监控框架 - -详细参考 [TiDB 监控框架概述](/tidb-monitoring-framework.md)。 - -### 监控指标解读 +## 监控 FAQ -详细参考 [重要监控指标详解](/grafana-overview-dashboard.md)。 ++ Prometheus 监控框架详情可见 [TiDB 监控框架概述](/tidb-monitoring-framework.md)。 ++ 监控指标解读详细参考 [重要监控指标详解](/grafana-overview-dashboard.md)。 -#### 目前的监控使用方式及主要监控指标，有没有更好看的监控？ +### 目前的监控使用方式及主要监控指标，有没有更好看的监控？ TiDB 使用 Prometheus + Grafana 组成 TiDB 数据库系统的监控系统，用户在 Grafana 上通过 dashboard 可以监控到 TiDB 的各类运行指标，包括系统资源的监控指标，包括客户端连接与 SQL 运行的指标，包括内部通信和 Region 调度的指标，通过这些指标，可以让数据库管理员更好的了解到系统的运行状态，运行瓶颈等内容。在监控指标的过程中，我们按照 TiDB 不同的模块，分别列出了各个模块重要的指标项，一般用户只需要关注这些常见的指标项。具体指标请参见[官方文档](/grafana-overview-dashboard.md)。 -#### Prometheus 监控数据默认 15 天自动清除一次，可以自己设定成 2 个月或者手动删除吗？ +### Prometheus 监控数据默认 15 天自动清除一次，可以自己设定成 2 个月或者手动删除吗？ 可以的，在 Prometheus 启动的机器上，找到启动脚本，然后修改启动参数，然后重启 Prometheus 生效。 @@ -507,15 +502,15 @@ TiDB 使用 Prometheus + Grafana 组成 TiDB 数据库系统的监控系统， --storage.tsdb.retention="60d" ``` -#### Region Health 监控项 +### Region Health 监控项 TiDB-2.0 版本中，PD metric 监控页面中，对 Region 健康度进行了监控，其中 Region Health 监控项是对所有 Region 副本状况的一些统计。其中 miss 是缺副本，extra 是多副本。同时也增加了按 Label 统计的隔离级别，level-1 表示这些 Region 的副本在第一级 Label 下是物理隔离的，没有配置 location label 时所有 Region 都在 level-0。 -#### Statement Count 监控项中的 selectsimplefull 是什么意思？ +### Statement Count 监控项中的 selectsimplefull 是什么意思？ 代表全表扫，但是可能是很小的系统表。 -#### 监控上的 QPS 和 Statement OPS 有什么区别？ +### 监控上的 QPS 和 Statement OPS 有什么区别？ QPS 会统计执行的所有 SQL 命令，包括 use database、load data、begin、commit、set、show、insert、select 等。 From d6fe0274a12b430b266cd09b2e8654a15de0867b Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 26 May 2020 10:29:05 +0800 Subject: [PATCH 5/5] Apply suggestions from code review Co-authored-by: Zhang Jian --- faq/deploy-and-maintain-faq.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 088ae2e6132d..97306be77835 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -28,7 +28,7 @@ TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运 TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台。对于开发、测试、及生产环境的服务器硬件配置有以下要求和建议： -**开发及测试环境** +### 开发及测试环境 | **组件** | **CPU** | **内存** | **本地存储** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- | @@ -37,7 +37,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器 | TiKV | 8核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 | | | | | | 服务器总计 | 4 | -**线上环境** +### 线上环境 | **组件** | **CPU** | **内存** | **硬盘类型** | **网络** | **实例数量(最低要求)** | | --- | --- | --- | --- | --- | --- |