tidb集群介绍和物理部署
TiDB是NewSQL数据库的技术探路者和引领者，本文简要介绍了TiDB的组件TiDB Server、PD调度和TiKV，并使用TiUP搭建了三节点的TiDB集群环境，部署简单便捷。
TiDB介绍
TiDB是PingCAP公司自主设计、研发的开源分布式关系型数据库，是一款同时支持OLTP和OLAP业务的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时HTAP、云原生的分布式数据库、同时兼容MySQL 5.7协议和MySQL生态等重要特性。
如图是TiDB整体架构图，可以看到TiDB核心功能组件包括：
- 计算层TiDB Server，负责与客户端通信，执行SQL解析和优化
- 存储层TiKV和TiFlash，支持key-value键值对存储和列式存储
- 调度层PDCluster，整个集群的大脑，负责分发调度指令给TiKV
- 分析计算模块TiSPARK，与Spark集群进行联动
- 云原生架构，基于K8S实现容器云平台的自动化部署和运维
- 通过TiDB Binlog实现MySQL数据库的实时同步
TiDB执行流程如图所示：
- 用户的SQL请求会直接或者通过 Load Balancer发送到TiDB Server
- TiDB Server会解析MySQL Protocol Packet，获取请求内容，对SQL进行语法解析和语义分析，制定和优化查询计划，执行查询计划并获取和处理数据
- PD server根据TiKV节点实时上报的数据分布状态，下发数据调度命令给具体的TiKV节点
- 数据全部存储在TiKV集群中， TiKV根据SQL请求返回数据到TiDB Server
- 最后TiDB Server需要将查询结果返回给用户。
TiDB Server
TiDB Server是SQL层，对外暴露MySQL协议的连接endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB层本身是无状态的，TiDB Server本身并不存储数据，只是解析 SQL，将实际的数据读取请求翻译成key-value操作转发给底层的存储节点 TiKV（或 TiFlash），最终查询结果返回给客户端。
SQL层架构如下所示：
用户的SQL请求会直接或者通过 Load Balancer发送到TiDB Server，TiDB Server会解析MySQL Protocol Packet，获取请求内容，对SQL进行语法解析和语义分析，制定和优化查询计划，执行查询计划并获取和处理数据。数据全部存储在TiKV集群中，所以在这个过程中TiDB Server需要和TiKV交互，获取数据。最后 TiDB Server需要将查询结果返回给用户。
PD Server
PD server是整个TiDB集群的元信息管理模块，负责存储每个TiKV节点实时的数据分布情况和集群的整体拓扑结构，提供TiDB Dashboard管控界面，并为分布式事务分配事务 ID。PD不仅存储元信息，同时还会根据TiKV节点实时上报的数据分布状态，下发数据调度命令给具体的TiKV节点，可以说是整个集群的“大脑”。
调度信息的收集
调度依赖于整个集群信息的收集，简单来说，调度需要知道每个TiKV节点的状态以及每个 Region的状态。TiKV集群会以心跳包的形式定期向PD汇报两类消息，TiKV节点信息和Region信息：
- 每个TiKV节点会定期向PD汇报节点的状态信息，包括磁盘容量、承载的Region数量、数据写入/读取速度、发送/接收的Snapshot数量、是否过载等
- 每个Raft group leader会定期向PD汇报Region状态信息，包括Leader的位置、Followers的位置、掉线Replica的数量、数据写入/读取速度等
调度的策略
PD在收集到信息后，会根据一些调度策略来制定具体的调度计划：
- Region中副本的数量，当发现副本数量不满足Raft算法要求时，需要通过ADD或Remove副本来调整副本数量
- Raft Group中多个副本不在同一个位置，一般情况下PD只会保证多个副本不会落在同一个节点上，以避免单个副本失效导致多个副本丢失
- 副本在存储之间均匀分配，使得各节点之间承载的数据更均衡
- Leader数量在存储之间均匀分配，Raft协议要求读写都是在leader上完成，因此PD会尽量保证leader在节点之间分散开
- 访问热点数据在存储间均匀分配，PD会检测出访问热点，并将其在节点之间分散开
- 各个存储的空间使用大致相等，PD在调度时候会考虑节点的存储空间剩余量
- 控制调度速度，避免影响在线服务，调度操作需要耗费CPU、内存、磁盘IO以及网络带宽，PD会对当前正在进行的操作数量进行控制
TiKV存储
TiKV负责存储数据，从外部看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的实际调用。
Key-value键值对
TiDB采用Key-Value模型存储数据，key-value键值对是一个巨大的map，这个map会按照key的二进制顺序有序排列。
存储引擎RocksDB
TiDB没有直接向磁盘上写数据，而是把数据保存在RocksDB中，具体的数据落地由RocksDB负责。RocksDB 是由Facebook开源的一个非常优秀的单机KV存储引擎，可以满足TiKV对单机引擎的各种要求。这里可以简单的认为RocksDB是一个单机的持久化Key-Value Map。
Region
TiKV将整个key-value空间分成很多段，每一段是连续的key，这些段称为region，目前TiKV中默认Region大小是96MB。TiKV会以region为单位，将数据分散在集群的所有节点上，并且保证每个节点上服务的Region数量差不多，并且以Region为单位做Raft的复制和成员管理。这样做有以下好处：
- TiDB中的PD调度系统会将Region数据尽可能的分布在不同的节点上，可以实现存储数据的水平扩展和负载均衡。同时PD也会记录Region在节点中的分布情况，也就是通过任意一个key就可以查到这个key在哪个region上
- TiKV以Region为单位做数据的复制，这样一个Region的数据会保存多个副本，副本之间通过Raft来保证数据的一致性。一个Region的多个副本会保存在不同的节点上，构成一个Raft Group。其中一个副本会作为这个Group的Leader，其他的副本作为Follower。默认情况下，所有的读和写都是通过Leader进行，读操作在Leader上即可完成，而写操作再由Leader复制给Follower。
多版本控制MVCC
TiKV的MVCC是通过在key后面添加版本号实现的，没有MVCC之前，可以把TiKV看做这样的：
Key1 -> Value
Key2 -> Value
……
KeyN -> Value有了MVCC之后，TiKV的Key排列是这样的：
Key1_Version3 -> Value
Key1_Version2 -> Value
Key1_Version1 -> Value
……
Key2_Version4 -> Value
Key2_Version3 -> Value
Key2_Version2 -> Value
Key2_Version1 -> Value
……
KeyN_Version2 -> Value
KeyN_Version1 -> Value
……TiDB集群环境部署
环境准备
1、服务器列表
TiDB集群最小部署环境需要3个节点，这里将TiDB Server、PD Server和TiKV放在一台虚机上共3台主机，另外一个主机部署控制台和监控节点。
TiDB默认端口信息如下：
注：我们机器不够，都部署在一台机器上，生产环境是不允许的。
2、检测及安装NTP
TiDB 是一套分布式数据库系统，需要节点间保证时间的同步，从而确保 ACID 模型的事务线性一致性。目前解决授时的普遍方案是采用 NTP 服务，可以通过互联网中的 pool.ntp.org 授时服务来保证节点的时间同步，也可以使用离线环境自己搭建的 NTP 服务来解决授时。在CentOS 7系统上手动安装 NTP 服务，可执行以下命令：
yum install ntp ntpdate
systemctl start ntpd.service
systemctl enable ntpd.service
systemctl status ntpd.service3、创建用户tidb并设置SUDO免密登录
useradd -d /home/tidb tidb
passwd tidb修改sudo权限
visudo
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
%tidb ALL=(ALL) NOPASSWD: ALLTiUP离线部署TiDB集群
1、下载TiDB安装包
下载地址为 TiDB 社区版 | PingCAP，选择6.4版本
TiDB 社区版 | PingCAP
2、将离线包发送到目标集群的中控机后，执行以下命令安装 TiUP 组件：
参考：https://www.cnblogs.com/xfeiyun/p/16178686.html
3、tidb 通过br备份到s3存储
参考：TiDB BR 备份至 MinIO S3 实战_TiDB 社区干货传送门的博客-CSDN博客
4、日常维护学习
数据库系列之TiDB日常操作维护 - 墨天轮