tidb数据库的安装与部署

一.TiDB 简介

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

五大核心特性

1.一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

2.金融级高可用

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

3.实时 HTAP

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

4.云原生的分布式数据库

专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

5.兼容 MySQL 5.7 协议和 MySQL 生态

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

四大核心应用场景

1.对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。

2.对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

3.Real-time HTAP 场景

随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

4.数据汇聚、二次加工处理的场景

当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

TiDB架构

TiDB Server：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 节点。

存储节点

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 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiDB 版本规则

TiDB 提供两个版本系列：

长期支持版本
开发里程碑版本（自 TiDB v6.0.0 起引入）

长期支持版本：

长期支持版本 (Long-Term Support Releases, LTS) 约每六个月发布一次，会引入新功能、改进、缺陷修复和安全漏洞修复。

示例版本:

6.1.0
5.4.0

在 LTS 生命周期内会按需发布补丁版本 (Patch Release)。补丁版本主要包含 bug 修复、安全漏洞修复，不会包含新的功能。

补丁版本命名方式为X.Y.Z。其中，系列版本号X.Y与对应的 LTS 保持一致，补丁版本号Z从 1 开始依次递增。

示例版本:

6.1.1

开发里程碑版本：

开发里程碑版本 (Development Milestone Releases, DMR) 约每两个月发布一次。如遇 LTS 发版，DMR 发版时间顺延两个月。DMR 会引入新的功能、改进和修复。但 TiDB 不提供基于 DMR 的补丁版本，如有相关 bug 会在后续版本系列中陆续修复。

DMR 命名方式为X.Y.Z，Z默认为 0，并添加后缀-DMR。

示例版本:

6.0.0-DMR

离线安装：

Tidb是一个复杂的分布式集群数据库系统，有很多种安装方式。大部分都要求安装服务器有联网的能力。因为我们公司大多是服务于各种局域网，所以这里我直接介绍离线安装的方式。

下载

选择下载产品，选择社区版，如下图：

最终进入如下页面，我们翻到最下面，选择一个长期支持版本,这里我们选择v6.5.0版本：

然后将两个下载好的包拉到linux中

如下图：

安装

2.1将离线包发送到目标集群的中控机后，执行以下命令安装 TiUP 组件：

tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz———-解压server包
sh tidb-community-server-${version}-linux-amd64/local_install.sh———执行解压后的目录里面的sh文件

如图：

注意1：将version改成自己下载的版本包，如（v6.5.0）。

注意2：可以通过 tiup list tidb命令，查看当前我们系统有哪些版本，如下图：

2.2声明全局环境变量

注意看第一步执行完的内容，页面的日志中会打印相关的source相关信息，直接复制执行即可

source${your_shell_profile}

如图：

2.3安装 TiUP 的 cluster 组件

tiup cluster

执行如上命令，若机器已经安装 TiUP cluster，需要更新软件版本：

tiup update –self
tiup update cluster

2.4修改配置，由于模拟多机部署，需要通过 root 用户调大 sshd 服务的连接数限制：

vi /etc/ssh/sshd_config ———将MaxSessions调至 20,如图：
service sshd restart ———-重启 sshd 服务

2.5创建配置文件，添加到安装文件夹的目录

按下面的配置模板，编辑配置文件，命名为topo.yaml，其中：

user: “tidb”：表示通过tidb系统用户（部署会自动创建）来做集群的内部管理，默认使用 22（因为我们公司服务器端口改为40000，所以我们写40000）端口通过 ssh 登录目标机器
replication.enable-placement-rules：设置这个 PD 参数来确保 TiFlash 正常运行
host：设置为本部署主机的 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: 40000
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:
log.slow-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: 172.20.54.126
tidb_servers:
– host: 172.20.54.126
tikv_servers:
– host: 172.20.54.126
port: 20160
status_port: 20180
config:
server.labels: { host: “logic-host-1” }
– host: 172.20.54.126
port: 20161
status_port: 20181
config:
server.labels: { host: “logic-host-2” }
– host: 172.20.54.126
port: 20162
status_port: 20182
config:
server.labels: { host: “logic-host-3” }
tiflash_servers:
– host: 172.20.54.126
tcp_port: 9001
monitoring_servers:
– host: 172.20.54.126
grafana_servers:
– host: 172.20.54.126

写完后，将这个文件添加到我们的安装目录

2.6 安装集群

tiup cluster deploy ./topo.yaml –user root -p

参数表示设置集群名称
参数表示设置集群版本，例如v6.5.0。可以通过tiup list tidb命令来查看当前支持部署的 TiDB 版本
参数-p表示在连接目标机器时使用密码登录

按照引导，输入”y”及 root 密码，来完成部署：

如图：

显示执行成功：

2.7启动集群（坑非常多）

tiup cluster start

如图

注意：这一步会遇到非常多的坑，4000会安装不上的原因有临时文件等，9000端口号冲突要改成9001的方法等等。后续我会在后面介绍。

2.8检查集群状态

安装完成，我们可以查看集群状态。（在一台里面模拟一个集群，下面是列表，如果哪个节点没起来，会显示红色的）如图：

tiupclusterdisplay${name}

登录上面提示的网址： http://172.20.52.135:2379/dashboard账户是root 密码没有

如图：

2.9用mysql工具链接

因为tidb的链接框架和mysql是一样的，我们可以直接用mysql的链接方式直接连tidb。下图我用nactive链接tidb，账户root，密码没有，如图：

遇到的坑（很重要）

3.1日志排查方式（很重要）：

以下是报错截图：

这里他会吧报错记录在一个日志里，但这个是tiup的日志，排查不了具体原因。真正的日志在根目录下 /tidb-deploy/tidb-4000里面，见下图：

3.1启动器群时，4000端口号那台机器启动报错

问题原因：

4000这个没部署成功，解决方式是这样的，删除 /tmp/tidb-4000.sock，具体原因未知，可以参考以下帖子：Failed to set root password of TiDB database to – #19，来自 Min_Chen -TiDB 技术问题 – TiDB 的问答社区

以下是该帖子回答的部分内容截图：

3.2启动器群时，9000端口号那台机器启动报错

以下是9000报错截图如图：

和上面一样，打开/tidb-deploy/tiflash-9000查看日志，得知是端口号，冲突。（9000端口号，我这台机器部署了其他服务，所以我们要更改tiflash这个节点的端口号）。

解决方式，卸载数据图，重新编辑yaml，按照如下文档更改端口号：

tiup/tiup-cluster-topology-reference.md · iceinto/pingcap-docs-cn – Gitee.com

以下是截图

所以我们之后卸载之前的tidb，重新写topo.yaml，如图：

卸载tidb

3.1查看tidb集群名称

tiup cluster list

我这里是 tidbdemo，如下图：

3.2停止

tiup cluster stoptidbdemo

3.3清理数据

tiup cluster clean tidbdemo–all

当然你还可以不使用–all去指定清理哪部分组件数据

3.4卸载

tiup cluster destroy tidbdemo

这里需要打出他提示的一句话，可以通过复制输入，如下图：

tidb数据库的安装与部署

一.TiDB 简介

五大核心特性

1.一键水平扩容或者缩容

2.金融级高可用

3.实时 HTAP

4.云原生的分布式数据库

5.兼容 MySQL 5.7 协议和 MySQL 生态

四大核心应用场景

1.对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

2.对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

3.Real-time HTAP 场景

4.数据汇聚、二次加工处理的场景

TiDB架构

存储节点

TiDB 版本规则

长期支持版本：

开发里程碑版本：

推荐：这里我们使用长期支持版本

离线安装：

3.1查看tidb集群名称

3.2停止

3.3清理数据

3.4卸载

最新关注

热文推荐

一篇看懂递归的套路解题法

免费ChatGPT镜像网站分享

揭秘｜来看看袋鼠云数栈内部的资产血缘方案设计与实现

centos通过VNC连接

Uncaught SyntaxError: Unexpected token ‘export‘

axios的cdn引入链接以及简单案例

tidb数据库的安装与部署

一.TiDB 简介

五大核心特性

1.一键水平扩容或者缩容

2.金融级高可用

3.实时 HTAP

4.云原生的分布式数据库

5.兼容 MySQL 5.7 协议和 MySQL 生态

四大核心应用场景

1.对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

2.对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

3.Real-time HTAP 场景

4.数据汇聚、二次加工处理的场景

TiDB架构

存储节点

TiDB 版本规则

长期支持版本：

开发里程碑版本：

推荐：这里我们使用长期支持版本

离线安装：

3.1查看tidb集群名称

3.2停止

3.3清理数据

3.4卸载

相关文章

最新关注

热文推荐