TIDB的基本使用

1、TIDB基本介绍

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP （Online Transactional Processing）、OLAP （Online Analytical Processing）、HTAP 解决方案。

TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

OLTP（Online Transactional Processing）：强调支持短时间内大量并发的事务操作（增删改查）能力，每个操作涉及的数据量都很小（比如几十到几百字节）。强调事务的强一致性。
OLAP（Online Analytical Processing）：偏向于复杂的只读查询，读取海量数据进行分析计算，查询时间往往较长。

2、TIDB整体架构

与传统的单机数据库相比，TiDB 具有以下优势：

纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

Application via mysql protocol：客户端使用 mysql 协议发出 SQL 请求。
TiDB Server（TIDB cluster）：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。（即每条SQL具体在哪个存储节点执行是由 PD 决定的）
存储节点
- TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 每个节点中的数据都会自动维护多副本（即在不同的region里。默认为三副本，主副本加起来三份，即实际每份数据都会存三份），天然支持高可用和自动故障转移。
- TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。
Region：是Tikv存储数据的基本单位（也是节点间同步数据的最小单位，Region实际上是一个逻辑上的单位），每个Region承载一段特定的数据，并分布在TiKV集群的不同节点上。Region的ID、范围、所在的节点信息等元信息会存储在PD中，TiKV Client通过查询PD获取Region的元信息，从而确定数据所在的节点。

2.1、TIDB行记录映射到KV

每行数据按照一定规则进行编码成 key-value 形式，key 格式：t + tableId + _ + r + rowID

Key: tablePrefix{tableID}_recordPrefixSep{rowID}
Value: [col1,col2,col3,col4]

示例如下：

3、TIDB的五大核心特性

TiDB 具备如下众多特性，其中两大核心特性为：水平扩展与高可用

一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
金融级高可用

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
实时 HTAP

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。
云原生的分布式数据库

TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，配合 TiDB Operator 项目可实现自动化运维，使部署、配置和维护变得十分简单。
兼容 MySQL 5.7 协议和 MySQL ⽣态
大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。对于用户使用的时候，可以透明地从MySQL切换到TiDB 中，只是“新MySQL”的后端是存储“无限的”，不再受制于Local的磁盘容量。在运维使用时也可以将TiDB当做一个从库挂到MySQL主从架构中。

6、TIDB安装

6.1、部署本地测试集群（playground安装，不推荐使用）

软硬件配置要求可参考：https://docs.pingcap.com/zh/tidb/v6.5/hardware-and-software-requirements

下面我们只是使用 playground 安装单机版的一个测试集群用于验证基本功能。（实际上不太建议使用该方式部署，跟实际生产情况差别挺大）

TIDB 目前未支持直接安装在 window 系统上，我们可以安装在虚拟机上。TIDB 安装需要内存比较高，下面我们以 4G 的 CentOS7 操作系统为例。

安装 tidb 可参考官方文档：https://docs.pingcap.com/zh/tidb/stable/quick-start-with-tidb

示例如下：

出现下图则安装完成：

重新开启一个会话访问 TiDB 数据库，直接输入 tiup client 即可访问数据库，也可使用 MySQL 客户端连接 TiDB（前提是Linux上已经安装了mysql，否则可能会报找不到mysql命令）：mysql --host 127.0.0.1 --port 4000 -u root

6.1.1、外部无法连接tidb数据库解决方法（如dbeaver无法连接）

TiUP Playground 默认监听 127.0.0.1，服务仅本地可访问，即只有在安装了 tidb 的服务器上才能访问（假设安装在虚拟机上则只有虚拟机上才能访问）。若需要使服务可被外部访问，可使用 --host 参数指定绑定外部可访问的 IP（这样安装在虚拟机上时外部也能访问到该 tidb 服务）

例如可使用命令：

// host 后面为虚拟机 IP
tiup playground v6.5.4 --db 2 --pd 3 --kv 3 --host 192.168.118.159

可参考：https://asktug.com/t/topic/1003354/2

6.1.2、tiup playground停止后如何保留数据

Playground 集群在命令行退出时，会默认清空所有的集群数据。如果想要启动一个数据不被自动删除的 Playground 集群，需要在启动时指定集群 tag，指定后可以在 ~/.tiup/data 路径下找到该集群的数据。

在集群启动时指定 tag 的方法如下：

// tag 后面为指定存储数据的目录，且为相对路径，该目录存储在 ~/.tiup/data 目录下
tiup playground v6.5.4 --db 2 --pd 3 --kv 3 --host 192.168.118.159 --tag tidbfile

此时在关闭 tiup playground 会话后，该集群数据会被保留，再次启动时只需指定相同的 tag 目录即可。

参考：https://asktug.com/t/topic/1020688

6.2、部署单机集群（推荐）

下面我们用一台虚拟机部署集群，模拟生产环境下的部署步骤。

操作步骤跟官网基本差不多，具体可参考：https://docs.pingcap.com/zh/tidb/v6.5/quick-start-with-tidb#在单机上模拟部署生产环境集群

第1-3步：

修改修改 /etc/ssh/sshd_config：

重启 sshd 服务，查看当前支持部署的 TiDB 版本，这里我选择了部署 v6.5.4 版本。

编辑配置文件，命名为 topo.yaml，配置文件实际只需修改对应部署的服务器的 ip即可，实际内容如下：

# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
 user: "tidb"
 ssh_port: 22
 deploy_dir: "/tidb-deploy"
 data_dir: "/tidb-data"

# # Monitored variables are applied to all the machines.
monitored:
 node_exporter_port: 9100
 blackbox_exporter_port: 9115

server_configs:
 tidb:
   instance.tidb_slow_log_threshold: 300
 tikv:
   readpool.storage.use-unified-pool: false
   readpool.coprocessor.use-unified-pool: true
 pd:
   replication.enable-placement-rules: true
   replication.location-labels: ["host"]
 tiflash:
   logger.level: "info"

pd_servers:
 - host: 192.168.118.160

tidb_servers:
 - host: 192.168.118.160

tikv_servers:
 - host: 192.168.118.160
   port: 20160
   status_port: 20180
   config:
     server.labels: { host: "logic-host-1" }

 - host: 192.168.118.160
   port: 20161
   status_port: 20181
   config:
     server.labels: { host: "logic-host-2" }

 - host: 192.168.118.160
   port: 20162
   status_port: 20182
   config:
     server.labels: { host: "logic-host-3" }

tiflash_servers:
 - host: 192.168.118.160

monitoring_servers:
 - host: 192.168.118.160

grafana_servers:
 - host: 192.168.118.160