关于 TiDB 37 个知识点

作者： 键盘丐 _原文来源：https://tidb.net/blog/499d9fbe

1.TiDB 数据库的三层架构包括哪些？

答：调度引擎（PD）、存储引擎（TiKV）、计算引擎（TiDB-Server）。

2.TiDB 数据库的内核组件有哪些？

答：内核组件包括 PD、TiKV、TiDB-Server，只有 TiKV 有数据文件，所有节点都有配置文件和日志文件。

3.TiDB 数据库是否必须多节点？

答：如不考虑高可用测试环境，TiDB/TiKV/PD 节点的个数都可以是 1 个，也可以按需后期添加 TiFlash、TiCDC 和 Binlog 组件。

4.TiDB-Server 负责哪些工作？

答：TiDB-Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，TiDB-Server 有三个后台功能，垃圾回收（GC）、执行 DDL、管理统计信息。

5.TiDB-Server 是否可以应用到 OLAP 场景？

答：在 OLAP 场景中进行大表 Join 时，通常会占用较多的内存存储中间数据，不建议将 TiDB-Server 用于替代离线数仓或者大数据产品。

6.TiKV 数据文件如何存储？

答：TiKV 分布式 Key-Value 存储引擎是全局有序的，每一个表会分配 TablelD，TablelD 与每行的 Primary Key 共同构成 Key-Value 中的 Key，通过具体的 Key 定位该行数据。数据按照 Region 进行分片存储，Region 是一个左闭右开区间，边界是 StartKey 到 EndKey，TiKV 会上报分片 Region 的数据分布到 PD 进行管理，Region 分片不需要分片键，不侵入业务，采用动态分片技术，分片可以自动分裂及合并。

7.TiKV 使用什么存储结构？

答：采用了 LSM-tree 作为存储结构，这是一种使用空间来置换写入延迟（非原地更新）的数据结构，它采用的是顺序写入的方式。

8.TiDB 的启动和关闭顺序？

答：启动 PD->TiKV->TiDB-Server->TiFlash；关闭 TiFlash->TiDB-Server->TiKV->PD。

9.TiDB 数据库不支持哪些 MySQL 特性？

答：外键、存储过程、自定义函数等。

10. 两地三中心容灾方案使用什么协议？

答：使用 Raft 协议（多数派一致协议），TiDB 数据库两地三中心支持数据丢失（RPO）为 0，服务恢复（RTO）约为 30 秒，用于节点投票。

11.TiDB 数据库如果实现分布式 SQL 计算？

答：SQL 的部分计算通过存储节点的 Coprossesor 组件下推到到 TiKV 进行条件过滤等计算。

12.TiDB 数据库的扩展性基于什么实现？

答：TiDB 基于 Region 实现灵活的扩展性，Region 是复制、调度的最小单元，它是左闭右开的存储单元，它支持自动分裂分片及合并，通过 PD 的元数据管理，分片查询成本不会因为节点的增多而变大。

13.TiDB 数据库实现跨 IDC 机房场景时 Region 复制基于哪种机制？

答：分片 Region 的复制基于 Multi-Raft 机制，可以支持多活，即单个表可以从多个 IDC 读和写，可以通过标签分组实现机房、机柜等维度的打散。

14.TiDB 数据库采用哪种事物模型？

答：采用 Percolater 事物模型，默认隔离级别为 Snapshot Isolation，由 TiKV 存储引擎实现事务，支持多个节点参与的分布式事务能力。

15.TiDB 数据库的 HTAP 能力包括哪些？

答：HTAP 的 AP 部署包括可实时写入更新的列式存储 TiFlash、Spark 运行于 TiKV 之上、列式存储 TiFlash 支持 MPP 并行计算和计算能力扩展。

16.TiFlash 组件采用哪种数据结构？

答：列式存储引擎 TiFlash 采用 Delta tree 数据结构支持准实时更新。

17.TiFlash 组件是否具备大规模并行计算（MPP）能力？

答：列式存储 TiFlash 的 MPP 能力可以将任务并行地分散到多个服务器和节点上，由优化器进行判断是否使用 MPP，通过 MPP 可以实现一条 Join 语句在多个 TiFlash 节点并行执行。

18.TiFlash 如何接入 TiKV？

答：TiFlash 以 Raft Learner 方式接入 Multi-Raft 组，Learner 身份只从 TiKV 复制数据，不参与投票，同步到 TiFlash 后会被从行格式拆解为列格式，通过读取标签标识同步进度，实现一致性读取。

19.TiSpark 组件的功能有哪些？

答：TiSpark 将 Spark 计算能力引入 TiDB 生态，Spark 可以识别和读取 TiKV 的数据格式、统计信息等，它支持低并发的重量级查询、报表、重量级  Adhoc 即席查询，但是它不支持高并发。

20.Tiup 开始于 TiDB 哪个版本？有哪些功能？

答：Tiup 是从 4.0 开始引入的集群管理工具，既可以管理内核组件（PD、TiKV、TiDB、TiFlash），也可以管理工具组件（DM、TiCDC 和 TiDB Binlog），实现完整的集群生命周期管理功能可以部署、管理（启停、修改参数）、升级、销毁。

21. 如何使用 tiup 查看群集状态？

答：tiup cluster list 查看环境中的集群列表，tiup cluster display 查看集群中各个节点的运行状态。tiup cluster deploy 部署 TiDB 数据库。

22.TiDB 数据库如何扩容、缩容？

答：使用 tiup cluster scale-out 扩容，使用 tiup cluster scale-in 缩容支持业务在线进行操作，PD、TiKV、TiDB 方法一致，因为 TiFlash 的副本是配置在字典内的，需要先增加和删除所有表的 TiFlash 副本，再进行扩容或者缩容。

23.TiDB 数据库群集配置如何修改？

答：集群配置存储在配置文件中，所有节点都有配置文件，使用 tiup cluster edit-config 进行编辑并下发配置文件给各个节点，修改后需要重启节点生效。

24.TiDB 数据库的系统参数如何修改，是否有作用域？

答：TiDB 数据库的系统参数持久化在 TiKV 存储中，分为全局、会话和 Instance 作用域，set global 将全局作用域的系统参数修改后只会影响新建立的连接，不会影响当前的执行修改命令的连接和其他已有的连接；alter session 只能修改当前会话参数，不会影响其他连接和新连接参数。

25.TiDB 数据库的升级顺序？

答：升级 Tiup–> 修改群集拓扑文件 –> 检查当前群集健康状态 –> 使用 tiup 升级到指定版本 –> 验证并检查当前群集健康状态。

26.TiDB 数据库的监控体系有哪些？

答：TiDB 数据库的监控体系，Prometheus 是监控数据存储，Grafana 用于图形化展示，Alertmanager 用于实现报警机制，都需要额外的服务器进行部署，在现实中它们通常被部署在一起，Prometheus+Grafana 监控页面可以查看 Region 的状态，包括 Regions 的数量和是否有错误的 Region。TiDB Dashboard 是集群的管理平台，它集成在 PD Server 中，无需独立部署，Dashboard 支持所有 SQL 查询的耗时等执行信息、组件及主机运行状态、收集分析各个组件的性能数据、诊断常见集群问题并生成报告、集群读写流量分布及趋势变化，列出所有 SQL 查询的耗时等执行信息，详细了解耗时较长的 SQL 语句的功能 。

27.TiDB 数据库用户和角色的区别？

答：TiDB 数据库支持基于角色的访问控制，角色和用户信息都存储在 mysql.user 表中，角色没有密码，创建角色时如果省略主机名默认为‘%’，用户在登录时，默认启用的角色会被自动启用，角色可以被赋予给角色或者用户。

28.TiDB 数据库认证与授权的区别？

答：用户连接 TiDB 数据库一般是先认证后进行授权，认证失败则无法连接数据库，授权操作失败则操作会报错。

29.TiDB 数据库有哪几种备份方式？

答：TiDB 的备份方式如下表，热备份允许读写数据，温备份只允许读取数据但是无法修改数据，冷备份（操作系统拷贝）不允许读取数据或者修改数据。

30.BR 备份工具的有哪些特点？

答：BR 备份工具属于物理备份，数据由 TiKV 从各个 Region 的 leader 生成 SST 格式的 KV 数据，它是专用的 TiDB 格式，不能用于 MySQL 的还原。TiKV 进行数据还原时，没有固定的节点对应关系，所有的节点都需要访问完整的数据，所以 BR 最好使用 NFS/S3 共享存储存储。BR 工具的适用场景包括快速备份全量数据或者增量备份、备份数据量较大 (TB 级别) 的库、要求校验备份数据。BR 工具 ratelimit 参数可以用来限制单个 TiKV 节点执行备份的最大速率，br restore 命令用于执行恢复任务，恢复时需要所有的 TiKV 节点都能读到全部备份数据。

31.Dumpling 备份工具有哪些特点使用场景有哪些？

答：Dumpling 工具支持 TiDB 的逻辑备份，它的速度较慢，备份的 SQL 文件（由一系列 SQL 语句组件）既可以用于 TiDB 也可以兼容 MySQL 数据库，需要恢复到 MySQL 的表数据级规模较小（千万或者以下），可以还原数据库备份时的状态。

32.Lightning 工具使用场景？

答：Lightning 是数据导入工具，它支持 CSV 和 SQL 文件，支持选择只导入某个 SCHEMA 或者全部的数据，支持断点续传功能并可将断点存储在其他数据库中。Local-backend 方式仅支持高版本，TiDB-backend 方式支持全部 TiDB 版本，TiDB-backend 后端模式实际是使用 insert 语句进行插入，也仅 TiDB-backend 模式支持同时进行写入。

33.TiDB 数据库有哪些同步工具？

答：TiDB Data Migration（TiDB DM）、TiDB Binlog、TiDB TiCDC。

34.TiDB DM 的使用场景及使用方法说明？

答：DM 是 MySQL 到 TiDB 的复制工具，从 MySQL 数据库全量数据和增量数据到 TiDB 数据库，DM 可以支持单个源库上游的表复制到 TiDB，也支持多个上游源库的表复制合并到 TiDB 单表，支持同步部分库和表的，但不支持选择同步表的部分列，下游表的列可以多于上游表的列；DM 通过 tiup 部署，分为 Master 集群管理组件和 worker 工作组件，和 dmctl 管理工具，源库 (上游) 实例的从库 worker 为 bound 状态，worker 与源库是 1 对 1 的关系，worker 多于源库实例时，未绑定的 worker 状态为 free；DM 集群节点查看命令是 tiup dm display dm-name，DM 复制任务状态的启动命令是 tiup dmctl –master-addr ip:port start-task task.yamlDM 复制任务状态的查看（含出错原因）是 tiup dmctl –master-addr ip:port query-status task-name；DM 的任务配置文件中，task-mode:“all” 表示同步全量数据和增量数据，Block & Allow Table Lists 用于限定 DM 的表清单范围，Table routings 用于支持多个上游源库的表复制合并，Binlog event filter 用于过滤某些操作。

35.TiDB Binlog 的使用场景及使用说明？

答：TiDB Binlog 的适用场景包括源库 (上游) 为 TiDB 数据库，目标库 (下游) 为 MySQL 或者 Kafka 的复制场景，它不支持实时同步复制；TiDB Binlog 是提交时进行写入的，未提交的事务是不会出现在 Binlog 中，Binlog 按照事务提交的时间戳顺序进行排序，Binlog 记录的是每一行数据的变更；TiDB Binlog 分为 Pump 和 Drainer，Pump 组件可以部署多个形成集群，具备高可用和水平扩展能力，一个 Drainer 仅对应一个写入目标，不具备高可用性。

36.TiCDC 的使用场景及使用说明？

答：TiCDC 集群支持多个同步任务，它的 Capture 接收绑定的 changefeed 所包含的表所在的 TiKV 的 KV Change Data 并进行排序 ;TiCDC 复制工具可以支持目标库是 TiDB 或者 Kafka，具备高可用特性，可以实现自动故障转移功能，以 TiKV 作为数据源并且输出 change data；TiCDC 复制工具可以支持多个任务，但是更新同步任务需要修改后再操作（不支持动态调整），创建 changefeed 时，changefeed-id 可以由系统自动分配，默认支持目标端 (下游) 的数据同步的并行同步方式。

37.TiCDC 和 TiDB Binlog 相同点和区别？

答：TiCDC 和 TiDB Binlog 都可以支持下游是 TiDB/MySQL/Kafka，都可以在 TiDB 5.0.0 上使用（Binlog 不兼容 TiDB 5.0 的一些新特性）。TiCDC 集群具有高可用性，TiDB Binlog 的 Drainer 不具备高可用性，TiCDC 数据源都是 TiKV 的 KV Change Data，TiDB Binlog 数据源是 TiDB 的事务写入 KV。