分布式关系型数据库TiDB
企业级分布式关系型数据库TiDB
一、TiDB简介
TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式关系型数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
1、五大核心特征
-
一键水平扩容或者缩容
得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。
-
金融级高可用
数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。
-
实时 HTAP
提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。
-
云原生的分布式数据库
专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。
-
兼容 MySQL 5.7 协议和 MySQL 生态
兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。
2、四大核心应用场景
-
对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景
众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0 。
-
对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景
随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。
-
Real-time HTAP 场景
随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。
-
数据汇聚、二次加工处理的场景
当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。
3、TiDB 具备如下核心特点：
-
1 高度兼容 MySQL 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
-
2 水平弹性扩展 通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
-
3 分布式事务 TiDB 100% 支持标准的 ACID 事务。
-
4 真正金融级高可用 相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
-
5 一站式 HTAP 解决方案 TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAPOLAP、OLTP的介绍和比较无需传统繁琐的 ETL 过程。
-
6 云原生 SQL 数据库 TiDB 是为云而设计的数据库，同 Kubernetes （Kubernetes核心概念 ）深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。 TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。
4、整体架构
TiDB 集群主要分为三个组件：
１TiDB Server
TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或F5）对外提供统一的接入地址。
２PD Server
Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader的迁移等）；三是分配全局唯一且递增的事务 ID。 PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
３TiKV Server
TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
二、What's New in TiDB 4.0
随着 TiDB v4.0 于 2020 年 5 月 28 日正式发布，TiDB v4.0 在稳定性、易用性、性能、安全和功能方面进行了大量的改进。本文概括性地介绍改进的内容，用户可根据实际情况决定升级到 TiDB v4.0。本文仅总结 v4.0 中面向用户且最重要的改进事项，功能及错误修复的完整列表，请参阅 Release Notes。
核心特性
调度功能
-
Cascading Placement Rules（实验特性）是一套副本规则系统，用于指导 PD 针对不同类型的数据生成对应的调度。通过组合不同的调度规则，用户可以精细地控制任何一段连续数据的副本数量、存放位置、主机类型、是否参与 Raft 投票、是否可以担任 Raft leader 等属性。详情参阅：Cascading Placement Rules。
-
弹性调度功能（实验特性），结合 Kubernetes，可根据实时负载状态，动态扩缩节点，能够有效地缓解业务高峰的压力并且节约不必要的成本开销。
-
热点调度支持更多维度。热点调度在决策时，除了根据写入/读取流量作为调度依据外，新引入 key 的维度。可以很大程度改善原有单一维度决策造成的 CPU 资源利用率不均衡的问题。详情参阅：调度。
存储引擎
-
TiFlash 是 TiDB 为完善 Realtime HTAP 形态引入的关键组件，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。详情参阅：TiFlash。
-
4.0 版本中 TiKV 提供新的存储格式，提升宽表场景下编解码数据的效率。
TiDB Dashboard
-
DBA 通过
TiDB Dashboard
UI 可以快速了解集群的集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息、SQL 访问信息、诊断报告信息等，帮助 DBA 通过 SQL 快速了解、分析系统的各项指标，具体信息如下：
-
Cluster Info，提供集群中所有组件，包括： TiDB、TiKV、PD、TiFlash 运行状态及其所在主机的运行状态。
-
Key Visualizer，系统可视化输出 TiDB 集群一段时间内的流量情况，用于 DBA 分析 TiDB 集群的使用模式和排查流量热点。
-
SQL Statements，记录当系统执行的所有 SQL 以及 SQL 相关的统计信息，包括：执行次数、执行时间汇总等，帮助用户快速分析系统的 SQL 执行状况，判断系统中有哪些热点 SQL 语句等。
-
Slow Queries，汇总集群中所有的慢查询语句，帮助用户快速定位慢查询语句。
-
Diagnostic Report，系统会周期性的自动对集群可能存在的问题进行诊断，并将诊断结果和一些集群相关的负载监控信息汇总成一个诊断报告。诊断报告是网页形式，通过浏览器保存后可离线浏览和传阅。
-
Log Search & Download，可视化搜索、查询集群的日志信息，帮忙 DBA 分析系统的问题，提升 DBA 运维的效率。
-
部署运维工具
TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiDB 生态内的所有的包，提供组件管理、Playground、Cluster、TUF、离线部署等功能，将安装、部署、运维 TiDB 工具化，提升 DBA 部署、运维 TiDB 的效率。详情参阅：TiUP，具体的功能如下：
-
组件管理功能，提供一键式组件信息查询、安装、升级、卸载等功能，方便 DBA 管理 TiDB 的所有组件。
-
集群管理功能 (Cluster)：提供一键式 TiDB 集群的部署、运维 TiDB 功能，包括：安装、部署、扩容、缩容、升级、配置变更、启动、停止、重启，查询集群状信息等，支持管理多个 TiDB 集群。
-
本地部署功能 (Playground): 提供快速在本地部署一个 TiDB 集群，快速体验、了解 TiDB 的基本功能，注意：此功能仅用于快速了解 TiDB，不适合上生产。
-
私有镜像管理 (Mirror): 当无法通过公网访问 TiUP 官方镜像时，TiUP 提供构建私有镜像的方案，帮助用户构建私有镜像及提供离线部署部署的功能。
-
性能测试功能 (Benchmark): 提供一键部署性能测试工具的功能，主要提供 TPC-C、TPC-H 两种性能测试的 workload 。
事务
-
悲观事务正式 GA 并作为默认事务模式提供，支持 Read Committed 隔离级别以及
SELECT FOR UPDATE NOWAIT语法。详情参阅：悲观事务模型。 -
支持大事务，最大事务限制由 100 MB 提升到了 10 GB，同时支持乐观事务和悲观事务。详情参阅：事务限制。
SQL 功能
-
在 SQL Plan Management 中引入了 SQL Bind 的自动捕获和演进，提升易用性和执行计划稳定性。详情参阅：绑定执行计划。
-
新增 15 种 SQL Hint 用于控制优化器生成执行计划，和执行引擎执行查询时的行为。详情参阅：SQL Hint。
-
支持
SELECT INTO outfile语句，该语句用来将表数据导出到指定的文本文件中，配合上LOAD DATA，可以方便的在数据库之间导入/导出数据。 -
支持自定义序列对象 Sequence，提供
CACHE/NO_CACHE、CYCLE/NO_CYCLE选项定义序列的不同特性，满足序列生成的各种需求，用户可以通过 Sequence 替代第三方 ID 生成服务。详情参阅：Sequence。 -
新增
Flashback命令，支持恢复被Truncate的表。详情参阅：Flashback。 -
新增查询数据时将 Join、Sort 中间结果写入本地磁盘，防止查询语句占用内存过多导致系统 OOM 的问题，提升系统的稳定性。
-
优化
EXPLAIN和EXPLAIN ANALYZE的输出结果，显示更多的信息，提升排查问题的效率。详情参阅：Explain Analyze，Explain。 -
支持 Index Merge 功能，Index Merge 是一种新的表访问方式，当查询只涉及到单张表时，优化器会自动根据查询条件读取多个索引数据并对结果求并集，提升查询单张表时的性能。详情参阅：Index Merge。
-
支持表达式索引 (Expression Index) 功能，表达式索引也叫函数索引，在创建索引时索引的字段不一定要是一个具体的列，而可以由一个或者多个列计算出来的表达式。对于快速访问那些基于计算结果的表非常有用（实验特性）。详情参阅：表达式索引。
-
支持 AutoRandom Key（实验特性）作为 TiDB 在列属性上的扩展语法，AutoRandom 被设计用于解决自增主键列的写热点问题，为使用自增主键列的用户提供最低成本的 MySQL 迁移方案。详情参阅：AutoRandom Key。
-
新增集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息等系统表等，帮助 DBA 通过 SQL 快速了解、分析系统的各项指标，详情参阅：infromation_shema，具体信息如下：
-
新增集群拓扑、配置、日志、硬件、操作系统等信息表，帮助 DBA 快速了集群配置、状态信息：
-
cluster_info表，用于保存集群的拓扑信息。 -
cluster_log表，用于保存系统的日志信息。 -
cluster_hardware，cluster_systeminfo，用于保存系统中服务器的硬件系统，操作系统信息等。
-
-
新增慢查询、诊断结果、性能监控等系统表，帮助 DBA 快速分析系统的性能瓶颈：
-
cluster_slow_query表，用于记录保存全局的慢查询信息。 -
cluster_processlist表，用于记录保存全局的 processlist。 -
inspection_result表，4.0 版本新增自动性能诊断的功能，帮助 DBA 自动分析系统的性能瓶颈并自动输出相关的性能分析报告，方便 DBA 定位常见的问题和异常项，提升 DBA 运维的效率。 -
metrics_summary和metric_summary_by_label表，用于记录保存系统中的所有监控指标信息，DBA 可以通过 SQL 访问所有的监控指标并可以与历史的监控指标进行对比，方便 DBA 定位、分析异常现象。 -
inspection_summary表，用于记录保存不同的数据链路或者访问链路上各种关键的监控指标，方便 DBA 定位、分析常见数据链路或者访问链路中的异常现象，例如：读数据、写数据链路。
-
-
字符集及排序规则
在 TiDB 4.0 的新集群中，支持大小写和口音不敏感的排序规则 utf8mb4_general_ci 及 utf8_general_ci，详情参阅: 字符集及排序规则。
安全
-
完善客户端与服务端，组件与组件之间的加密通信，确保连接安全性，保护接收与发送的任何数据不会被网络犯罪分子读取和修改。主要支持基于证书的登录认证、在线更新证书、校验 TLS 证书的
CommonName属性等功能。详情参阅：开启加密传输。 -
透明数据加密 (Transparent Data Encryption)，简称 TDE，是 TiDB 推出的一个新特性，用来对整个数据库提供保护。数据库开启 TDE 加密功能后，对于连接到数据库的应用程序来说是完全透明的，它不需要对现有应用程序做任何改变。因为 TDE 的加密特性是基本于文件级别的，系统会在将数据写到磁盘之前加密，在读取到内存之前解密，确保数据的安全性。目前主要支持 AES128-CTR、AES192-CTR、AES256-CTR 三种加密算法，支持通过 AWS KMS 管理密钥等功能。详情参阅静态加密。
备份与恢复
快速备份恢复功能，用来快速的备份与恢复单个 TiDB 集群的数据，确保数据的可靠性，符合企业备份与恢复或者等保的要求。主要支持快速的全量备份与恢复、支持按照数据排序后区间范围备份与恢复数据。详情参阅：快速备份与恢复工具。
服务级别功能
-
TiDB 实例支持以 Region 为单位缓存算子下推到 TiKV 的的返回结果，提升 SQL 语句完全一致、SQL 语句包含一个变化条件且仅限于表主键或分区主键，其他部分一致和 SQL 语句包含多个变化的条件且条件完全匹配一个复合索引列，其他部分一致场景时 SQL 执行的效率（实验特性）。详情参阅：缓存查询结果。
-
支持缓存
Prepare/Execute请求的执行计划，提升 SQL 的执行效率。详情参阅：缓存执行计划。 -
支持将配置参数持久化存储到 PD 中，支持动态修改配置项功能，提升产品易用性。
-
支持自适应线程池功能，精简线程池数量，优化请求处理调度方式，提升产品易用性，提升产品的性能。
-
Follower Read 功能是指在强一致性读的前提下使用 Region 的 follower 副本来承载数据读取的任务，从而提升 TiDB 集群的吞吐能力并降低 leader 负载。Follower Read 包含一系列将 TiKV 读取负载从 Region 的 leader 副本上 offload 到 follower 副本的负载均衡机制。TiKV 的 Follower Read 可以保证数据读取的一致性，可以为用户提供强一致的数据读取能力。详情参阅：Follower Read。
TiCDC
TiCDC 支持通过拉取 TiKV 变更日志实现 TiDB 集群之间数据同步，支持数据的高可靠、服务的高可用能力，确保数据不会丢失。用户可以通过订阅的方式订阅数据的变更信息，系统会自动将数据推送到下游系统，当前仅支持 MySQL 协议的数据库（例如：MySQL、TiDB)及 Kafka 作为 TiCDC 的下游，同时用户也可以通过 TiCDC 提供的开放数据协议自行扩展支持的下游系统（实验特性）。详情参阅：TiCDC。
三、TiDB 基本功能
数据类型
-
数值类型：BIT、BOOL|BOOLEAN、SMALLINT、MEDIUMINT、INT|INTEGER、BIGINT、FLOAT、DOUBLE、DECIMAL。
-
日期和时间类型：DATE、TIME、DATETIME、TIMESTAMP、YEAR。
-
字符串类型：CHAR、VARCHAR、TEXT、TINYTEXT、MEDIUMTEXT、LONGTEXT、BINARY、VARBINARY、BLOB、TINYBLOB、MEDIUMBLOB、LONGBLOB、ENUM、SET。
-
JSON 类型。
运算符
-
算术运算符、位运算符、比较运算符、逻辑运算符、日期和时间运算符等。
字符集及排序规则
-
字符集：UTF8、UTF8MB4、BINARY、ASCII、LATIN1。
-
排序规则：UTF8MB4_GENERAL_CI、UTF8MB4_GENERAL_BIN、UTF8_GENERAL_CI、UTF8_GENERAL_BIN、BINARY。
函数
-
控制流函数、字符串函数、日期和时间函数、位函数、数据类型转换函数、数据加解密函数、压缩和解压函数、信息函数、JSON 函数、聚合函数、窗口函数等。
SQL 语句
-
完全支持标准的 Data Definition Language (DDL) 语句，例如：CREATE、DROP、ALTER、RENAME、TRUNCATE 等。
-
完全支持标准的 Data Manipulation Language (DML) 语句，例如：INSERT、REPLACE、SELECT、Subqueries、UPDATE、LOAD DATA 等。
-
完全支持标准的 Transactional and Locking 语句，例如：START TRANSACTION、COMMIT、ROLLBACK、SET TRANSACTION 等。
-
完全支持标准的 Database Administration 语句，例如：SHOW、SET 等。
-
完全支持标准的 Utility 语句，例如：DESCRIBE、EXPLAIN、USE 等。
-
完全支持 SQL GROUP BY 和 ORDER BY 子语句。
-
完全支持标准 SQL 语法的 LEFT OUTER JOIN 和 RIGHT OUTER JOIN。
-
完全支持标准 SQL 要求的表和列别名。
分区表
-
支持 Range 分区。
-
支持 Hash 分区。
视图
-
支持普通视图。
约束
-
支持非空约束。
-
支持主键约束。
-
支持唯一约束。
安全
-
支持基于 RBAC (role-based access control) 的权限管理。
-
支持密码管理。
-
支持通信、数据加密。
-
支持 IP 白名单。
-
支持审计功能。
工具
-
支持快速备份功能。
-
支持通过工具从 MySQL 迁移数据到 TiDB。
-
支持通过工具部署、运维 TiDB。
四、兼容性
与 MySQL 兼容性对比概览
-
TiDB 100% 兼容 MySQL5.7 协议、MySQL5.7 常用的功能及语法，MySQL5.7 生态中系统的工具（PHPMyAdmin, Navicat, MySQL Workbench、mysqldump、Mydumper/myloader）、客户端等均用于 TiDB。
-
TiDB 是一款分布式数据库， MySQL5.7 中的部分特性由于工程实现难较大，投入产出比较低等多种原因在 TiDB 未能实现或者仅兼容语法但功能并没有实现，因此使用过程中请特别注意。例如：
CREATE TABLE语句中ENGINE，仅兼容语法功能并没有实现，因此 TiDB 中没有ENGINE这类的概念。
注意：
本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于安全特性、悲观事务模型 相关的兼容信息请查看各自具体页面。
不支持的功能特性
-
存储过程与函数
-
触发器
-
事件
-
自定义函数
-
外键约束
-
全文/空间函数与索引
-
非
ascii/latin1/binary/utf8/utf8mb4的字符集 -
SYS schema
-
MySQL 追踪优化器
-
XML 函数
-
X Protocol
-
Savepoints
-
列级权限
-
XA语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开） -
CREATE TABLE tblName AS SELECT stmt语法 -
CREATE TEMPORARY TABLE语法 -
CHECK TABLE语法 -
CHECKSUM TABLE语法
与 MySQL 有差异的特性详细说明
自增 ID
-
TiDB 的自增列仅保证自增且唯一、但不保证自动分配的值的连续性，建议不要将缺省值和自定义值混用，若混用可能会收
Duplicated Error的错误信息。 -
TiDB 在工程实现上会在每一个 tidb-server 实例上缓存一段 ID 的值用于给表的自增列分配值，缓存 ID 的个数由表的
AUTO_ID_CACHE确定，默认值：30000，请特别注意：自增列和_tidb_rowid都会消耗缓存的 ID，如果INSERT语句中所要求的连续的 ID 个数大于AUTO_ID_CACHE的值时系统会自动调整AUTO_ID_CACHE的值以确保该语句能正常执行。 -
TiDB 可通过
tidb_allow_remove_auto_inc系统变量开启或者关闭删除列的AUTO_INCREMENT属性，删除列属性的语法是：alter table modify或alter table change。
注意：
tidb_allow_remove_auto_inc要求版本号 >= v2.1.18 或者 >= v3.0.4。表的
AUTO_ID_CACHE属性要求版本号 >= v3.0.14 或者 >= v3.1.2 或者 >= v4.0.rc-2。若创建表时没有指定主键时， TiDB 会使用
_tidb_rowid来标识行，该数值的分配会和自增列（如果存在的话）共用一个分配器。如果指定了自增列为主键，则 TiDB 会用该列来标识行。因此会有以下的示例情况：
mysql> create table t(id int unique key AUTO_INCREMENT);
Query OK, 0 rows affected (0.05 sec)
mysql> insert into t values(),(),();
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select _tidb_rowid, id from t;
+-------------+------+
| _tidb_rowid | id |
+-------------+------+
| 4 | 1 |
| 5 | 2 |
| 6 | 3 |
+-------------+------+
3 rows in set (0.01 sec)Performance schema
-
TiDB 主要使用 Prometheus 和 Grafana 来存储及查询相关的性能监控指标，故 Performance schema 部分表是空表。
查询计划
-
EXPLAIN/EXPLAIN FOR输出格式、内容、权限设置与 MySQL 有比较大的差别，参见理解 TiDB 执行计划。
内建函数
-
支持常用的 MySQL 内建函数，有部分函数并未支持，参考 SQL 语法文档。
DDL 的限制
-
Add Index
-
同一条 SQL 语句不支持创建多个索引。
-
仅在语法在支持创建不同类型的索引 (HASH/BTREE/RTREE），功能未实现。
-
-
Add Column
-
不支持设置
PRIMARY KEY及UNIQUE KEY，不支持设置AUTO_INCREMENT属性。可能输出的错误信息：unsupported add column '%s' constraint PRIMARY/UNIQUE/AUTO_INCREMENT KEY
-
-
Drop Column
-
不支持删除主键列及索引列，可能输出的错误信息：
Unsupported drop integer primary key/column a with index covered。
-
-
Drop Primary Key
-
仅支持删除建表时启用了
alter-primary-key配置项的表的主键,可能输出的错误信息:Unsupported drop primary key when alter-primary-key is false。
-
-
Order By 忽略所有列排序相关的选项。
-
Change/Modify Column
-
不支持有损变更，比如从
BIGINT变为INTEGER，或者从VARCHAR(255)变为VARCHAR(10)，可能输出的错误信息：length %d is less than origin %d -
不支持修改
DECIMAL类型的精度，可能输出的错误信息：can't change decimal column precision。 -
不支持更改
UNSIGNED属性，可能输出的错误信息：can't change unsigned integer to signed or vice versa。 -
只支持将
CHARACTER SET属性从utf8更改为utf8mb4
-
-
LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE}-
仅在语法上支持，功能未实现，故所有的 DDL 都不会锁表。
-
-
ALGORITHM [=] {DEFAULT|INSTANT|INPLACE|COPY}-
支持
ALGORITHM=INSTANT和ALGORITHM=INPLACE语法，但行为与 MySQL 有所不同，MySQL 中的一些INPLACE操作在 TiDB 中的 是INSTANT操作。 -
仅在语法上支持
ALGORITHM=COPY，功能未实现，会返回警告信息。
-
-
单条
ALTER TABLE语句中无法完成多个操作。例如：不能用一条语句来添加多个列或多个索引。可能输出的错误信息：Unsupported multi schema change。 -
Table Option 仅支持
AUTO_INCREMENT、CHARACTER SET、COLLATE、COMMENT，不支持以下语法:-
WITH/WITHOUT VALIDATION -
SECONDARY_LOAD/SECONDARY_UNLOAD -
CHECK/DROP CHECK -
STATS_AUTO_RECALC/STATS_SAMPLE_PAGES -
SECONDARY_ENGINE -
ENCRYPTION
-
-
Table Partition 分区类型支持 Hash、Range；支持 Add/Drop/Truncate/Coalese；忽略其他分区操作，可能错误信息：
Warning: Unsupported partition type, treat as normal table，不支持以下语法:-
PARTITION BY LIST -
PARTITION BY KEY -
SUBPARTITION -
{CHECK|EXCHANGE|TRUNCATE|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD|REORGANIZE} PARTITION
-
ANALYZE TABLE
-
ANALYZE TABLE语句会完全重构表的统计数据，语句执行过程较长，但在 MySQL/InnoDB 中，它是一个轻量级语句，执行过程较短。
视图
-
不支持
UPDATE、INSERT、DELETE等写入操作。
存储引擎
-
仅在语法上兼容创建表时指定存储引擎，实际上 TiDB 会将元信息统一描述为 InnoDB 存储引擎。TiDB 支持类似 MySQL 的存储引擎抽象，但需要在系统启动时通过
--store配置项来指定存储引擎。
SQL 模式
-
不支持兼容模式，例如：
ORACLE和POSTGRESQL，MySQL 5.7 已弃用兼容模式，MySQL 8.0 已移除兼容模式。 -
ONLY_FULL_GROUP_BY与 MySQL 5.7 相比有细微的语义差别。 -
NO_DIR_IN_CREATE和NO_ENGINE_SUBSTITUTIONMySQL 用于解决兼容问题，并不适用于 TiDB。
默认设置
-
字符集：
-
TiDB 默认：
utf8mb4。 -
MySQL 5.7 默认：
latin1。 -
MySQL 8.0 默认：
utf8mb4。
-
-
排序规则：
-
TiDB 中
utf8mb4字符集默认:utf8mb4_bin。 -
MySQL 5.7 中
utf8mb4字符集默认:utf8mb4_general_ci。 -
MySQL 8.0 中
utf8mb4字符集默认:utf8mb4_0900_ai_ci。
-
-
foreign_key_checks：-
TiDB 默认:
OFF，且仅支持设置该值为OFF。 -
MySQL 5.7 默认：
ON。
-
-
SQL mode：
-
TiDB 默认：
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION -
MySQL 5.7 默认 与 TiDB 相同。
-
MySQL 8.0 默认
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION。
-
-
lower_case_table_names：-
TiDB 默认： 2，且仅支持设置该值为 2。
-
MySQL 默认如下：
-
Linux 系统中该值为 0
-
Windows 系统中该值为 1
-
macOS 系统中该值为 2
-
-
-
explicit_defaults_for_timestamp：-
TiDB 默认：
ON，且仅支持设置该值为ON。 -
MySQL 5.7 默认：
OFF。 -
MySQL 8.0 默认：
ON。
-
日期时间处理的区别
时区
-
TiDB 采用系统当前安装的所有时区规则进行计算（一般为
tzdata包）, 不需要导入时区表数据就能使用所有时区名称，无法通过导入时区表数据的形式修改计算规则。 -
MySQL 默认使用本地时区，依赖于系统内置的当前的时区规则（例如什么时候开始夏令时等）进行计算；且在未导入时区表数据的情况下不能通过时区名称来指定时区。
零月和零日
-
与 MySQL 一样，TiDB 默认启用了
NO_ZERO_DATE和
NO_ZERO_IN_DATE模式，但是 TiDB 与 MySQL 在处理这两个 SQL 模式有以下不同：
-
TiDB 在非严格模式下启用以上两个 SQL 模式，插入零月/零日/零日期不会给出警告，MySQL 则会给出对应的警告。
-
TiDB 在严格模式下，启用了
NO_ZERO_DATE，仍然能够插入零日期；如果启用了NO_ZERO_IN_DATE则无法插入零月/零日日期。MySQL 在严格模式下则都无法插入两种类型的日期。
-
类型系统
-
不支持 FLOAT4/FLOAT8。
-
不支持 FIXED (alias for DECIMAL)。
-
不支持 SERIAL (alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE)。
-
不支持
SQL_TSI_*（包括 SQL_TSI_YEAR、SQL_TSI_MONTH、SQL_TSI_WEEK、SQL_TSI_DAY、SQL_TSI_HOUR、SQL_TSI_MINUTE 和 SQL_TSI_SECOND）。
五、使用限制
本文会将详细描述 TiDB 中常见的使用限制，包括：标识符长度，最大支持的数据库、表、索引、分区表、序列等的个数。
标识符长度限制
| 标识符类型 | 最大长度（字符） |
|---|---|
| Database | 64 |
| Table | 64 |
| Cloumn | 64 |
| Index | 64 |
| View | 64 |
| Sequence | 64 |
Databases、Tables、Views、Connections 总个数限制
| 标识符类型 | 最大个数 |
|---|---|
| Databases | unlimited |
| Tables | unlimited |
| Views | unlimited |
| Connections | unlimited |
单个 Database 的限制
| 类型 | 最大限制 |
|---|---|
| Tables | unlimited |
单个 Table 的限制
| 类型 | 最大限制 |
|---|---|
| Cloumns | 512 |
| Indexs | 64 |
| Rows | unlimited |
| Size | unlimited |
| Partitions | 1024 |
单行的限制
| 类型 | 最大限制 |
|---|---|
| Size | 6MB |
单列的限制
| 类型 | 最大限制 |
|---|---|
| Size | 6MB |
字符串类型限制
| 类型 | 最大限制 |
|---|---|
| CHAR | 256 字符 |
| BINARY | 256 字节 |
| VARBINARY | 65535 字节 |
| VARCHAR | 16383 字符 |
| TEXT | 6MB 字节 |
| BLOB | 6MB 字节 |
SQL Statements 的限制
| 类型 | 最大限制 |
|---|---|
| 单个事务最大语句数 | 在使用乐观事务并开启事务重试的情况下，默认限制 5000，可通过 stmt-count-limit 调整 |
六、快速上手部署测试
TiDB 数据库快速上手指南
警告：
对于生产环境，不要使用本文介绍的方式进行部署，而应使用 TiUP 部署 TiDB 集群
本文介绍如何快速上手体验 TiDB 分布式数据库。有以下 3 种体验方式供用户选择。
-
第一种：使用 TiUP Playground 快速部署本地测试环境
-
第二种：使用 TiUP cluster 在单机上模拟生产环境部署步骤
-
第三种：使用 TiDB-Wasm 一键体验 TiDB 数据库
第一种：使用 TiUP Playground 快速部署本地测试环境
-
适用场景：利用本地 Mac 或者单机 Linux 环境快速部署 TiDB 集群。可以体验 TiDB 集群的基本架构，以及 TiDB、TiKV、PD、监控等基础组件的运行。
-
耗时：1 分钟
作为一个分布式系统，最基础的 TiDB 测试集群通常由 2 个 TiDB 实例、3 个 TiKV 实例和 3 个 PD 实例来构成。通过 TiUP Playground，可以快速搭建出上述的一套基础测试集群。
-
下载并安装 TiUP。
#curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh -
声明全局环境变量。
注意：
TiUP 安装完成会提示对应的 profile 文件的绝对路径，以下 source 操作需要根据实际位置进行操作。
#source .bash_profile -
在当前 session 执行以下命令启动集群。
-
直接运行
tiup playground命令会运行最新版本的 TiDB 集群，其中 TiDB、TiKV 和 PD 实例各 1 个：#tiup playground -
也可以指定 TiDB 版本以及各组件实例个数，命令类似于：
#tiup playground v4.0.0 --db 2 --pd 3 --kv 3 --monitor上述命令会在本地下载并启动一个
v4.0.0版本的集群，--monitor表示同时部署监控组件。 最新版本可以通过执行tiup list tidb来查看。 运行结果将显示集群的访问方式：CLUSTER START SUCCESSFULLY, Enjoy it ^-^ To connect TiDB: mysql --host 127.0.0.1 --port 4000 -u root To connect TiDB: mysql --host 127.0.0.1 --port 4001 -u root To view the dashboard: http://127.0.0.1:2379/dashboard To view the monitor: http://127.0.0.1:9090
-
-
新开启一个 session 以访问 TiDB 数据库。
#mysql --host 127.0.0.1 --port 4000 -u root -
通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。
-
通过 http://127.0.0.1:2379/dashboard 访问 TiDB Dashboard 页面，默认用户名为 root，密码为空。
-
测试完成后清理集群，绿色环保。通过
ctrl-c停掉进程后，执行以下命令：#tiup clean --all
第二种：使用 TiUP cluster 在单机上模拟生产环境部署步骤
-
适用场景：希望用单台 Linux 服务器，体验 TiDB 最小的完整拓扑的集群，并模拟生产的部署步骤。
-
耗时：10 分钟
本节介绍如何参照 TiUP 最小拓扑的一个 YAML 文件部署 TiDB 集群。
准备环境
准备一台部署主机，确保其软件满足需求：
-
推荐安装 CentOS 7.3 及以上版本
-
Linux 操作系统开放外网访问，用于下载 TiDB 及相关软件安装包
最小规模的 TiDB 集群拓扑：
| 实例 | 个数 | IP | 配置 |
|---|---|---|---|
| TiKV | 3 | 192.168.28.134 192.168.28.134 192.168.28.134 | 避免端口和目录冲突 |
| TiDB | 1 | 192.168.28.134 | 默认端口 全局目录配置 |
| PD | 1 | 192.168.28.134 | 默认端口 全局目录配置 |
| TiFlash | 1 | 192.168.28.134 | 默认端口 全局目录配置 |
| Monitor | 1 | 192.168.28.134 | 默认端口 全局目录配置 |
部署主机软件和环境要求：
-
部署需要使用部署主机的 root 用户及密码
-
部署主机关闭防火墙或者开放 TiDB 集群的节点间所需端口
-
保证部署环境纯洁
-
创建对应的文件存储目录（注意：以下演示是在/root目录下执行。如想测试部署请创建对应的文件存储目录）
-
目前 TiUP 仅支持在 x86_64 (AMD64) 架构上部署 TiDB 集群（TiUP 将在 4.0 GA 时支持在 ARM 架构上部署）
-
在 AMD64 架构下，建议使用 CentOS 7.3 及以上版本 Linux 操作系统
-
在 ARM 架构下，建议使用 CentOS 7.6 1810 版本 Linux 操作系统
-
在虚拟机CentO7 中内存给5G cpu给2个
-
实施部署
注意：
你可以使用 Linux 系统的任一普通用户或 root 用户登录主机，以下步骤以 root 用户为例。
-
下载并安装 TiUP：
[root@localhost ~]# curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 4412k 100 4412k 0 0 3622k 0 0:00:01 0:00:01 --:--:-- 3622k WARN: adding root certificate via internet: https://tiup-mirrors.pingcap.com/root.json You can revoke this by remove /root/.tiup/bin/7b8e153f2e2d0928.root.json Set mirror to https://tiup-mirrors.pingcap.com success Detected shell: bash Shell profile: /root/.bash_profile /root/.bash_profile has been modified to to add tiup to PATH open a new terminal or source /root/.bash_profile to use it Installed path: /root/.tiup/bin/tiup =============================================== Have a try: tiup playground =============================================== -
安装 TiUP 的 cluster 组件：
[root@localhost ~]# source .bash_profile #声明全局环境变量 [root@localhost ~]# tiup cluster The component `cluster` is not installed; downloading from repository. download https://tiup-mirrors.pingcap.com/cluster-v1.0.8-linux-amd64.tar.gz 9.62 MiB / 9.62 MiB 100.00% 1.48 MiB p/s Starting component `cluster`: Deploy a TiDB cluster for production Usage: tiup cluster cluster [flags] tiup cluster [command] Available Commands: check Perform preflight checks for the cluster. deploy Deploy a cluster for production start Start a TiDB cluster stop Stop a TiDB cluster restart Restart a TiDB cluster scale-in Scale in a TiDB cluster scale-out Scale out a TiDB cluster destroy upgrade Upgrade a specified TiDB cluster exec Run shell command on host in the tidb cluster display Display information of a TiDB cluster list List all clusters audit Show audit log of cluster operation import Import an exist TiDB cluster from TiDB-Ansible edit-config Edit TiDB cluster config reload Reload a TiDB cluster's config and restart if needed patch Replace the remote package with a specified package and restart the service help Help about any command Flags: -h, --help help for tiup --ssh-timeout int Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5) -v, --version version for tiup --wait-timeout int Timeout in seconds to wait for an operation to complete, ignored for operations that don't fit. (default 120) -y, --yes Skip all confirmations and assumes 'yes' Use "tiup cluster help [command]" for more information about a command. ^CGot signal interrupt (Component: cluster ; PID: 12879) -
如果机器已经安装 TiUP cluster，需要更新软件版本：
[root@localhost ~]# tiup update --self && tiup update cluster download https://tiup-mirrors.pingcap.com/tiup-v1.0.8-linux-amd64.tar.gz 4.31 MiB / 4.31 MiB 100.00% 463.66 KiB p/s Updated successfully! component cluster version v1.0.8 is already installed Updated successfully! -
由于模拟多机部署，需要通过
root用户调大 sshd 服务的连接数限制：-
修改
/etc/ssh/sshd_config将MaxSessions调至 20。 -
重启 sshd 服务：
[root@localhost ~]# service sshd restart
-
-
创建并启动集群
创建对应的用户并修改密码
[root@localhost ~]# useradd tidb [root@localhost ~]# passwd tidb Changing password for user tidb. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@localhost ~]# visudo tidb ALL=(ALL) NOPASSWD: ALL #设置用户tidb免密登录按下面的配置模板，编辑配置文件，命名为
topo.yaml，其中：-
user: "tidb"：表示通过tidb系统用户（部署会自动创建）来做集群的内部管理，默认使用 22 端口通过 ssh 登录目标机器 -
replication.enable-placement-rules：设置这个 PD 参数来确保 TiFlash 正常运行 -
host：设置为本部署主机的 IP
配置模板如下：
[root@localhost ~]# vim topo.yaml # # 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: log.slow-threshold: 300 tikv: readpool.storage.use-unified-pool: false readpool.coprocessor.use-unified-pool: true pd: replication.enable-placement-rules: true tiflash: logger.level: "info" pd_servers: - host: 192.168.28.134 tidb_servers: - host: 192.168.28.134 tikv_servers: - host: 192.168.28.134 port: 20160 status_port: 20180 - host: 192.168.28.134 port: 20161 status_port: 20181 - host: 192.168.28.134 port: 20162 status_port: 20182 tiflash_servers: - host: 192.168.28.134 monitoring_servers: - host: 192.168.28.134 grafana_servers: - host: 192.168.28.134 -
-
执行集群部署命令：
[root@localhost ~]# tiup cluster deploy tidb-test v4.0.0 ./topo.yaml --user tidb -p Starting component `cluster`: deploy tidb-test v4.0.0 ./topo.yaml --user tidb -p Please confirm your topology: TiDB Cluster: tidb-test TiDB Version: v4.0.0 Type Host Ports OS/Arch Directories ---- ---- ----- ------- ----------- pd 192.168.28.134 2379/2380 linux/x86_64 /tidb-deploy/pd-2379,/tidb-data/pd-2379 tikv 192.168.28.134 20160/20180 linux/x86_64 /tidb-deploy/tikv-20160,/tidb-data/tikv-20160 tikv 192.168.28.134 20161/20181 linux/x86_64 /tidb-deploy/tikv-20161,/tidb-data/tikv-20161 tikv 192.168.28.134 20162/20182 linux/x86_64 /tidb-deploy/tikv-20162,/tidb-data/tikv-20162 tidb 192.168.28.134 4000/10080 linux/x86_64 /tidb-deploy/tidb-4000 tiflash 192.168.28.134 9000/8123/3930/20170/20292/8234 linux/x86_64 /tidb-deploy/tiflash-9000,/tidb-data/tiflash-9000 prometheus 192.168.28.134 9090 linux/x86_64 /tidb-deploy/prometheus-9090,/tidb-data/prometheus-9090 grafana 192.168.28.134 3000 linux/x86_64 /tidb-deploy/grafana-3000 Attention: 1. If the topology is not what you expected, check your yaml file. 2. Please confirm there is no port/directory conflicts in same host. [root@localhost ~]#tiup cluster deploy./topo.yaml --user tidb -p -
参数
-
参数
tiup list tidb命令来查看当前支持部署的 TiDB 版本
按照引导，输入”y”及 root 密码，来完成部署：
Do you want to continue? [y/N]: y Input SSH password: + Generate SSH keys ... Done + Download TiDB components - Download pd:v4.0.0 (linux/amd64) ... Done - Download tikv:v4.0.0 (linux/amd64) ... Done - Download tidb:v4.0.0 (linux/amd64) ... Done - Download tiflash:v4.0.0 (linux/amd64) ... Done - Download prometheus:v4.0.0 (linux/amd64) ... Done - Download grafana:v4.0.0 (linux/amd64) ... Done - Download node_exporter:v0.17.0 (linux/amd64) ... Done - Download blackbox_exporter:v0.12.0 (linux/amd64) ... Done + Initialize target host environments - Prepare 192.168.28.134:22 ... Done + Copy files - Copy pd -> 192.168.28.134 ... Done - Copy tikv -> 192.168.28.134 ... Done - Copy tikv -> 192.168.28.134 ... Done - Copy tikv -> 192.168.28.134 ... Done - Copy tidb -> 192.168.28.134 ... Done - Copy tiflash -> 192.168.28.134 ... Done - Copy prometheus -> 192.168.28.134 ... Done - Copy grafana -> 192.168.28.134 ... Done - Copy node_exporter -> 192.168.28.134 ... Done - Copy blackbox_exporter -> 192.168.28.134 ... Done + Check status Deployed cluster `tidb-test` successfully, you can start the cluster via `tiup cluster start tidb-test` -
-
启动集群：
[root@localhost ~]# tiup cluster start[root@localhost ~]# tiup cluster start tidb-test <---集群的名称 Starting component `cluster`: start tidb-test Starting cluster tidb-test... + [ Serial ] - SSHKeySet: privateKey=/root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa, publicKey=/root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa.pub + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [Parallel] - UserSSH: user=tidb, host=192.168.28.134 + [ Serial ] - ClusterOperate: operation=StartOperation, options={Roles:[] Nodes:[] Force:false SSHTimeout:5 OptTimeout:120 APITimeout:300 IgnoreConfigCheck:false RetainDataRoles:[] RetainDataNodes:[]} Starting component pd Starting instance pd 192.168.28.134:2379 Start pd 192.168.28.134:2379 success Starting component node_exporter Starting instance 192.168.28.134 Start 192.168.28.134 success Starting component blackbox_exporter Starting instance 192.168.28.134 Start 192.168.28.134 success Starting component tikv Starting instance tikv 192.168.28.134:20162 Starting instance tikv 192.168.28.134:20160 Starting instance tikv 192.168.28.134:20161 Start tikv 192.168.28.134:20162 success Start tikv 192.168.28.134:20161 success Start tikv 192.168.28.134:20160 success Starting component tidb Starting instance tidb 192.168.28.134:4000 Start tidb 192.168.28.134:4000 success Starting component tiflash Starting instance tiflash 192.168.28.134:9000 Start tiflash 192.168.28.134:9000 success Starting component prometheus Starting instance prometheus 192.168.28.134:9090 Start prometheus 192.168.28.134:9090 success Starting component grafana Starting instance grafana 192.168.28.134:3000 Start grafana 192.168.28.134:3000 success Checking service state of pd 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:53:45 EDT; 26s ago Checking service state of tikv 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:53:46 EDT; 26s ago 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:53:46 EDT; 26s ago 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:53:46 EDT; 26s ago Checking service state of tidb 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:53:50 EDT; 22s ago Checking service state of tiflash 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:54:02 EDT; 10s ago Checking service state of prometheus 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:54:04 EDT; 8s ago Checking service state of grafana 192.168.28.134 Active: active (running) since Sat 2020-07-18 05:54:07 EDT; 5s ago + [ Serial ] - UpdateTopology: cluster=tidb-test Started cluster `tidb-test` successfully -
访问集群：
-
访问 TiDB 数据库，密码为空：
[root@localhost ~]# mysql -h192.168.28.134 -u root -P 4000 Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 9 Server version: 5.7.25-TiDB-v4.0.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> show databases; +--------------------+ | Database | +--------------------+ | INFORMATION_SCHEMA | | METRICS_SCHEMA | | PERFORMANCE_SCHEMA | | mysql | | test | +--------------------+ 5 rows in set (0.00 sec) MySQL [(none)]> Ctrl-C -- exit! Aborted [root@localhost ~]# mysql -h 192.168.28.134 -P 4000 -u root #大P -
访问 TiDB 的 Grafana 监控：
通过 http://{grafana-ip}:3000 访问集群 Grafana 监控页面，默认用户名和密码均为 admin。
-
访问 TiDB 的 Dashboard：
通过 http://{pd-ip}:2379/dashboard 访问集群 TiDB Dashboard 监控页面，默认用户名为 root，密码为空。
-
执行以下命令确认当前已经部署的集群列表：
-
[root@localhost ~]# tiup cluster list Starting component `cluster`: list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- tidb-test tidb v4.0.0 /root/.tiup/storage/cluster/clusters/tidb-test /root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsaxxxxxxxxxx [root@localhost ~]# tiup cluster listStarting component `cluster`: listName User Version Path PrivateKey---- ---- ------- ---- ----------tidb-test tidb v4.0.0 /root/.tiup/storage/cluster/clusters/tidb-test /root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa#tiup cluster listshell
-
执行以下命令查看集群的拓扑结构和状态：
[root@localhost ~]# tiup cluster display tidb-test Starting component `cluster`: display tidb-test TiDB Cluster: tidb-test TiDB Version: v4.0.0 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 192.168.28.134:3000 grafana 192.168.28.134 3000 linux/x86_64 Up - /tidb-deploy/grafana-300 0 192.168.28.134:2379 pd 192.168.28.134 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379 192.168.28.134:9090 prometheus 192.168.28.134 9090 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus- 9090 192.168.28.134:4000 tidb 192.168.28.134 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 192.168.28.134:9000 tiflash 192.168.28.134 9000/8123/3930/20170/20292/82 34 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-900 0 192.168.28.134:20160 tikv 192.168.28.134 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 192.168.28.134:20161 tikv 192.168.28.134 20161/20181 linux/x86_64 Up /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 192.168.28.134:20162 tikv 192.168.28.134 20162/20182 linux/x86_64 Up /tidb-data/tikv-20162 /tidb-deploy/tikv-20162
-
第三种：使用 TiDB-Wasm 一键体验 TiDB 数据库
-
适用场景：初步极速体验 TiDB 数据库的语法、兼容性等基本功能
-
耗时：即时体验
TiDB-Wasm 是运行在浏览器中的 TiDB 数据库，打开网页即可使用。TiDB-Wasm 可直接进行 SQL 执行、兼容性验证等基本操作。
直接点击网址试用 TiDB-Wasm：https://tour.pingcap.com，之后会在内存中构建 TiDB 数据库，预计耗时 10 秒左右。
探索更多
-
如果你刚刚部署好一套 TiDB 本地测试集群：
-
学习 TiDB SQL 操作
-
迁移数据到 TiDB
-
了解 TiDB 的核心特性与核心应用场景
-
了解 TiDB 的整体架构
-
了解 TiDB 与 MySQL 的兼容性
-
-
如果你准备好在生产环境部署 TiDB 了：
-
在线部署：使用 TiUP 部署 TiDB 集群
-
离线部署：使用 TiUP 离线部署 TiDB 集群
-
使用 TiDB Operator 在云上部署 TiDB
-
注意：
TiDB、TiUP 及 TiDB Dashboard 默认会收集使用情况信息，并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为，请参见遥测。
七、集群部署
1、TiDB 软件和硬件环境建议配置
TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境、ARM 架构的服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络。作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境。
Linux 操作系统版本要求
| Linux 操作系统平台 | 版本 |
|---|---|
| Red Hat Enterprise Linux | 7.3 及以上 |
| CentOS | 7.3 及以上 |
| Oracle Enterprise Linux | 7.3 及以上 |
| Ubuntu LTS | 16.04 及以上 |
注意：
TiDB 只支持 Red Hat 兼容内核 (RHCK) 的 Oracle Enterprise Linux，不支持 Oracle Enterprise Linux 提供的 Unbreakable Enterprise Kernel。
TiDB 在 CentOS 7.3 的环境下进行过大量的测试，同时社区也有很多该操作系统部署的最佳实践，因此，建议使用 CentOS 7.3 以上的 Linux 操作系统来部署 TiDB。
以上 Linux 操作系统可运行在物理服务器以及 VMware、KVM、XEN 主流虚拟化环境上。
软件配置要求
中控机软件配置
| 软件 | 版本 |
|---|---|
| sshpass | 1.06 及以上 |
| TiUP | 0.6.2 及以上 |
注意：
中控机需要部署 TiUP 软件来完成 TiDB 集群运维管理。
目标主机建议配置软件
| 软件 | 版本 |
|---|---|
| sshpass | 1.06 及以上 |
| numa | 2.0.12 及以上 |
服务器建议配置
TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台或者 ARM 架构的硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置（不包含操作系统 OS 本身的占用）有以下要求和建议：
开发及测试环境
| 组件 | CPU | 内存 | 本地存储 | 网络 | 实例数量(最低要求) |
|---|---|---|---|---|---|
| TiDB | 8 核+ | 16 GB+ | 无特殊要求 | 千兆网卡 | 1（可与 PD 同机器） |
| PD | 4 核+ | 8 GB+ | SAS, 200 GB+ | 千兆网卡 | 1（可与 TiDB 同机器） |
| TiKV | 8 核+ | 32 GB+ | SSD, 200 GB+ | 千兆网卡 | 3 |
| TiFlash | 32 核+ | 64 GB+ | SSD, 200 GB+ | 千兆网卡 | 1 |
| TiCDC | 8 核+ | 16 GB+ | SAS, 200 GB+ | 千兆网卡 | 1 |
注意：
验证测试环境中的 TiDB 和 PD 可以部署在同一台服务器上。
如进行性能相关的测试，避免采用低性能存储和网络硬件配置，防止对测试结果的正确性产生干扰。
TiKV 的 SSD 盘推荐使用 NVME 接口以保证读写更快。
如果仅验证功能，建议使用 TiDB 数据库快速上手指南进行单机功能测试。
TiDB 对于磁盘的使用以存放日志为主，因此在测试环境中对于磁盘类型和容量并无特殊要求。
生产环境
| 组件 | CPU | 内存 | 硬盘类型 | 网络 | 实例数量(最低要求) |
|---|---|---|---|---|---|
| TiDB | 16 核+ | 32 GB+ | SAS | 万兆网卡（2 块最佳） | 2 |
| PD | 4核+ | 8 GB+ | SSD | 万兆网卡（2块最佳） | 3 |
| TiKV | 16 核+ | 32 GB+ | SSD | 万兆网卡（2 块最佳） | 3 |
| TiFlash | 48 核+ | 128 GB+ | 1 or more SSDs | 万兆网卡（2 块最佳） | 2 |
| TiCDC | 16 核+ | 64 GB+ | SSD | 万兆网卡（2 块最佳） | 2 |
| 监控 | 8 核+ | 16 GB+ | SAS | 千兆网卡 | 1 |
注意：
生产环境中的 TiDB 和 PD 可以部署和运行在同服务器上，如对性能和可靠性有更高的要求，应尽可能分开部署。
生产环境强烈推荐使用更高的配置。
TiKV 硬盘大小配置建议 PCI-E SSD 不超过 2 TB，普通 SSD 不超过 1.5 TB。
TiFlash 支持多盘部署。
TiFlash 数据目录的第一块磁盘推荐用高性能 SSD 来缓冲 TiKV 同步数据的实时写入，该盘性能应不低于 TiKV 所使用的磁盘，比如 PCI-E SSD。并且该磁盘容量建议不小于总容量的 10%，否则它可能成为这个节点的能承载的数据量的瓶颈。而其他磁盘可以根据需求部署多块普通 SSD，当然更好的 PCI-E SSD 硬盘会带来更好的性能。
TiFlash 推荐与 TiKV 部署在不同节点，如果条件所限必须将 TiFlash 与 TiKV 部署在相同节点，则需要适当增加 CPU 核数和内存，且尽量将 TiFlash 与 TiKV 部署在不同的磁盘，以免互相干扰。
TiFlash 硬盘总容量大致为：
整个 TiKV 集群的需同步数据容量 / TiKV 副本数 * TiFlash 副本数。例如整体 TiKV 的规划容量为 1 TB、TiKV 副本数为 3、TiFlash 副本数为 2，则 TiFlash 的推荐总容量为1024 GB / 3 * 2。用户可以选择同步部分表数据而非全部，具体容量可以根据需要同步的表的数据量具体分析。TiCDC 硬盘配置建议 200 GB+ PCIE-SSD。
网络要求
TiDB 作为开源分布式 NewSQL 数据库，其正常运行需要网络环境提供如下的网络端口配置要求，管理员可根据实际环境中 TiDB 组件部署的方案，在网络侧和主机侧开放相关端口：
| 组件 | 默认端口 | 说明 |
|---|---|---|
| TiDB | 4000 | 应用及 DBA 工具访问通信端口 |
| TiDB | 10080 | TiDB 状态信息上报通信端口 |
| TiKV | 20160 | TiKV 通信端口 |
| PD | 2379 | 提供 TiDB 和 PD 通信端口 |
| PD | 2380 | PD 集群节点间通信端口 |
| TiFlash | 9000 | TiFlash TCP 服务端口 |
| TiFlash | 8123 | TiFlash HTTP 服务端口 |
| TiFlash | 3930 | TiFlash RAFT 服务和 Coprocessor 服务端口 |
| TiFlash | 20170 | TiFlash Proxy 服务端口 |
| TiFlash | 20292 | Prometheus 拉取 TiFlash Proxy metrics 端口 |
| TiFlash | 8234 | Prometheus 拉取 TiFlash metrics 端口 |
| Pump | 8250 | Pump 通信端口 |
| Drainer | 8249 | Drainer 通信端口 |
| CDC | 8300 | CDC 通信接口 |
| Prometheus | 9090 | Prometheus 服务通信端口 |
| Node_exporter | 9100 | TiDB 集群每个节点的系统信息上报通信端口 |
| Blackbox_exporter | 9115 | Blackbox_exporter 通信端口，用于 TiDB 集群端口监控 |
| Grafana | 3000 | Web 监控服务对外服务和客户端(浏览器)访问端口 |
| Alertmanager | 9093 | 告警 web 服务端口 |
| Alertmanager | 9094 | 告警通信端口 |
客户端 Web 浏览器要求
TiDB 提供了基于 Grafana 的技术平台，对数据库集群的各项指标进行可视化展现。采用支持 Javascript 的微软 IE、Google Chrome、Mozilla Firefox 的较新版本即可访问监控入口。
2、TiDB 环境与系统配置检查
本文介绍部署 TiDB 前的环境检查操作，以下各项操作按优先级排序。
在 TiKV 部署目标机器上添加数据盘 EXT4 文件系统挂载参数
生产环境部署，建议使用 EXT4 类型文件系统的 NVME 类型的 SSD 磁盘存储 TiKV 数据文件。这个配置方案为最佳实施方案，其可靠性、安全性、稳定性已经在大量线上场景中得到证实。
使用 root 用户登录目标机器，将部署目标机器数据盘格式化成 ext4 文件系统，挂载时添加 nodelalloc 和 noatime 挂载参数。nodelalloc 是必选参数，否则 TiUP 安装时检测无法通过；noatime 是可选建议参数。
注意：
如果你的数据盘已经格式化成 ext4 并挂载了磁盘，可先执行
umount /dev/nvme0n1p1命令卸载，从编辑/etc/fstab文件步骤开始执行，添加挂载参数重新挂载即可。
以 /dev/nvme0n1 数据盘为例，具体操作步骤如下：
-
查看数据盘。
fdisk -lDisk /dev/nvme0n1: 1000 GB -
创建分区。
parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1注意：
使用
lsblk命令查看分区的设备号：对于 nvme 磁盘，生成的分区设备号一般为nvme0n1p1；对于普通磁盘（例如/dev/sdb），生成的的分区设备号一般为sdb1。 -
格式化文件系统。
mkfs.ext4 /dev/nvme0n1p1 -
查看数据盘分区 UUID。
本例中
nvme0n1p1的 UUID 为c51eb23b-195c-4061-92a9-3fad812cc12f。lsblk -fNAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ext4 237b634b-a565-477b-8371-6dff0c41f5ab /boot ├─sda2 swap f414c5c0-f823-4bb1-8fdf-e531173a72ed └─sda3 ext4 547909c1-398d-4696-94c6-03e43e317b60 / sr0 nvme0n1 └─nvme0n1p1 ext4 c51eb23b-195c-4061-92a9-3fad812cc12f -
编辑
/etc/fstab文件，添加nodelalloc挂载参数。vi /etc/fstabUUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2 -
挂载数据盘。
mkdir /data1 && \ mount -a -
执行以下命令，如果文件系统为 ext4，并且挂载参数中包含
nodelalloc，则表示已生效。mount -t ext4/dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered)
检测及关闭系统 swap
本段介绍 swap 关闭方法。TiDB 运行需要有足够的内存，并且不建议使用 swap 作为内存不足的缓冲，这会降低性能。因此建议永久关闭系统 swap，并且不要使用 swapoff -a 方式关闭，否则重启机器后该操作会失效。
建议执行以下命令关闭系统 swap：
Copy
echo "vm.swappiness = 0">> /etc/sysctl.conf
swapoff -a && swapon -a
sysctl -p检测及关闭目标部署机器的防火墙
本段介绍如何关闭目标主机防火墙配置，因为在 TiDB 集群中，需要将节点间的访问端口打通才可以保证读写请求、数据心跳等信息的正常的传输。在普遍线上场景中，数据库到业务服务和数据库节点的网络联通都是在安全域内完成数据交互。如果没有特殊安全的要求，建议将目标节点的防火墙进行关闭。否则建议按照端口使用规则，将端口信息配置到防火墙服务的白名单中。
-
检查防火墙状态（以 CentOS Linux release 7.7.1908 (Core) 为例）
sudo firewall-cmd --state sudo systemctl status firewalld.service -
关闭防火墙服务
sudo systemctl stop firewalld.service -
关闭防火墙自动启动服务
sudo systemctl disable firewalld.service -
检查防火墙状态
sudo systemctl status firewalld.service
检测及安装 NTP 服务
TiDB 是一套分布式数据库系统，需要节点间保证时间的同步，从而确保 ACID 模型的事务线性一致性。目前解决授时的普遍方案是采用 NTP 服务，可以通过互联网中的 pool.ntp.org 授时服务来保证节点的时间同步，也可以使用离线环境自己搭建的 NTP 服务来解决授时。
采用如下步骤检查是否安装 NTP 服务以及与 NTP 服务器正常同步：
-
执行以下命令，如果输出
running表示 NTP 服务正在运行：sudo systemctl status ntpd.servicentpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled) Active: active (running) since 一 2017-12-18 13:13:19 CST; 3s ago -
执行
ntpstat命令检测是否与 NTP 服务器同步：注意：
Ubuntu 系统需安装
ntpstat软件包。ntpstat-
如果输出
synchronised to NTP server，表示正在与 NTP 服务器正常同步：synchronised to NTP server (85.199.214.101) at stratum 2 time correct to within 91 ms polling server every 1024 s -
以下情况表示 NTP 服务未正常同步：
unsynchronised -
以下情况表示 NTP 服务未正常运行：
Unable to talk to NTP daemon. Is it running?
-
如果要使 NTP 服务尽快开始同步，执行以下命令。可以将 pool.ntp.org 替换为你的 NTP 服务器：
Copy
sudo systemctl stop ntpd.service && \
sudo ntpdate pool.ntp.org && \
sudo systemctl start ntpd.service如果要在 CentOS 7 系统上手动安装 NTP 服务，可执行以下命令：
Copy
sudo yum install ntp ntpdate && \
sudo systemctl start ntpd.service && \
sudo systemctl enable ntpd.service手动配置 SSH 互信及 sudo 免密码
对于有需求，通过手动配置中控机至目标节点互信的场景，可参考本段。通常推荐使用 TiUP 部署工具会自动配置 SSH 互信及免密登陆，可忽略本段内容。
-
以
root用户依次登录到部署目标机器创建tidb用户并设置登录密码。useradd tidb && \ passwd tidb -
执行以下命令，将
tidb ALL=(ALL) NOPASSWD: ALL添加到文件末尾，即配置好 sudo 免密码。visudotidb ALL=(ALL) NOPASSWD: ALL -
以
tidb用户登录到中控机，执行以下命令。将10.0.1.1替换成你的部署目标机器 IP，按提示输入部署目标机器tidb用户密码，执行成功后即创建好 SSH 互信，其他机器同理。ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.1.1 -
以
tidb用户登录中控机，通过ssh的方式登录目标机器 IP。如果不需要输入密码并登录成功，即表示 SSH 互信配置成功。ssh 10.0.1.1[[email protected] ~]$ -
以
tidb用户登录到部署目标机器后，执行以下命令，不需要输入密码并切换到root用户，表示tidb用户 sudo 免密码配置成功。sudo -su root[[email protected] tidb]#
安装 numactl 工具
本段主要介绍如果安装 NUMA 工具。在线上环境中，因为硬件机器配置往往高于需求，为了更合理规划资源，会考虑单机多实例部署 TiDB 或者 TiKV。NUMA 绑核工具的使用，主要为了防止 CPU 资源的争抢，引发性能衰退。
注意：
NUMA 绑核是用来隔离 CPU 资源的一种方法，适合高配置物理机环境部署多实例使用。
通过
tiup cluster deploy完成部署操作，就可以通过exec命令来进行集群级别管理工作。
-
登录到目标节点进行安装（以 CentOS Linux release 7.7.1908 (Core) 为例）
sudo yum -y install numactl -
通过 TiUP 的 cluster 执行完 exec 命令来完成批量安装
tiup cluster exec --helpRun shell command on host in the tidb cluster Usage: cluster exec[flags] Flags: --command string the command run on cluster host (default "ls") -h, --help help for exec --sudo use root permissions (default false) 将 tidb-test 集群所有目标主机通过 sudo 权限执行安装命令
tiup cluster exec tidb-test --sudo --command "yum -y install numactl"
3、配置拓扑结构
1、最小拓扑架构
本文档介绍 TiDB 集群最小部署的拓扑架构。
拓扑信息
| 实例 | 个数 | 物理机配置 | IP | 配置 |
|---|---|---|---|---|
| TiDB | 3 | 16 VCore 32GB * 1 | 10.0.1.1 10.0.1.2 10.0.1.3 | 默认端口 全局目录配置 |
| PD | 3 | 4 VCore 8GB * 1 | 10.0.1.4 10.0.1.5 10.0.1.6 | 默认端口 全局目录配置 |
| TiKV | 3 | 16 VCore 32GB 2TB (nvme ssd) * 1 | 10.0.1.7 10.0.1.8 10.0.1.9 | 默认端口 全局目录配置 |
| Monitoring & Grafana | 1 | 4 VCore 8GB * 1 500GB (ssd) | 10.0.1.11 | 默认端口 全局目录配置 |
拓扑模版
简单最小配置模板
# # 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"
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
tikv_servers:
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
monitoring_servers:
- host: 10.0.1.10
grafana_servers:
- host: 10.0.1.10
alertmanager_servers:
- host: 10.0.1.10详细最小配置模板
# # 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
# deploy_dir: "/tidb-deploy/monitored-9100"
# data_dir: "/tidb-data/monitored-9100"
# log_dir: "/tidb-deploy/monitored-9100/log"
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
# # You can overwrite this configuration via the instance-level `config` field.
server_configs:
tidb:
log.slow-threshold: 300
binlog.enable: false
binlog.ignore-error: false
tikv:
# server.grpc-concurrency: 4
# raftstore.apply-pool-size: 2
# raftstore.store-pool-size: 2
# rocksdb.max-sub-compactions: 1
# storage.block-cache.capacity: "16GB"
# readpool.unified.max-thread-count: 12
readpool.storage.use-unified-pool: false
readpool.coprocessor.use-unified-pool: true
pd:
schedule.leader-schedule-limit: 4
schedule.region-schedule-limit: 2048
schedule.replica-schedule-limit: 64
pd_servers:
- host: 10.0.1.4
# ssh_port: 22
# name: "pd-1"
# client_port: 2379
# peer_port: 2380
# deploy_dir: "/tidb-deploy/pd-2379"
# data_dir: "/tidb-data/pd-2379"
# log_dir: "/tidb-deploy/pd-2379/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.pd` values.
# config:
# schedule.max-merge-region-size: 20
# schedule.max-merge-region-keys: 200000
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
# ssh_port: 22
# port: 4000
# status_port: 10080
# deploy_dir: "/tidb-deploy/tidb-4000"
# log_dir: "/tidb-deploy/tidb-4000/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.tidb` values.
# config:
# log.slow-query-file: tidb-slow-overwrited.log
- host: 10.0.1.2
- host: 10.0.1.3
tikv_servers:
- host: 10.0.1.7
# ssh_port: 22
# port: 20160
# status_port: 20180
# deploy_dir: "/tidb-deploy/tikv-20160"
# data_dir: "/tidb-data/tikv-20160"
# log_dir: "/tidb-deploy/tikv-20160/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.tikv` values.
# config:
# server.grpc-concurrency: 4
# server.labels: { zone: "zone1", dc: "dc1", host: "host1" }
- host: 10.0.1.8
- host: 10.0.1.9
monitoring_servers:
- host: 10.0.1.10
# ssh_port: 22
# port: 9090
# deploy_dir: "/tidb-deploy/prometheus-8249"
# data_dir: "/tidb-data/prometheus-8249"
# log_dir: "/tidb-deploy/prometheus-8249/log"
grafana_servers:
- host: 10.0.1.10
# port: 3000
# deploy_dir: /tidb-deploy/grafana-3000
alertmanager_servers:
- host: 10.0.1.10
# ssh_port: 22
# web_port: 9093
# cluster_port: 9094
# deploy_dir: "/tidb-deploy/alertmanager-9093"
# data_dir: "/tidb-data/alertmanager-9093"
# log_dir: "/tidb-deploy/alertmanager-9093/log"2、TiFlash 部署拓扑
本文介绍在部署最小拓扑集群的基础上，部署 TiFlash 的拓扑结构。TiFlash 是列式的存储引擎，已经成为集群拓扑的标配。适合 Real-Time HTAP 业务。
拓扑信息
| 实例 | 个数 | 物理机配置 | IP | 配置 |
|---|---|---|---|---|
| TiDB | 3 | 16 VCore 32GB * 1 | 10.0.1.1 10.0.1.2 10.0.1.3 | 默认端口 全局目录配置 |
| PD | 3 | 4 VCore 8GB * 1 | 10.0.1.4 10.0.1.5 10.0.1.6 | 默认端口 全局目录配置 |
| TiKV | 3 | 16 VCore 32GB 2TB (nvme ssd) * 1 | 10.0.1.1 10.0.1.2 10.0.1.3 | 默认端口 全局目录配置 |
| TiFlash | 1 | 32 VCore 64 GB 2TB (nvme ssd) * 1 | 10.0.1.10 | 默认端口 全局目录配置 |
| Monitoring & Grafana | 1 | 4 VCore 8GB * 1 500GB (ssd) | 10.0.1.10 | 默认端口 全局目录配置 |
拓扑模版
-
简单 TiFlash 配置模版
# # 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" server_configs: pd: replication.enable-placement-rules: true pd_servers: - host: 10.0.1.4 - host: 10.0.1.5 - host: 10.0.1.6 tidb_servers: - host: 10.0.1.7 - host: 10.0.1.8 - host: 10.0.1.9 tikv_servers: - host: 10.0.1.1 - host: 10.0.1.2 - host: 10.0.1.3 tiflash_servers: - host: 10.0.1.11 data_dir: /tidb-data/tiflash-9000 deploy_dir: /tidb-deploy/tiflash-9000 monitoring_servers: - host: 10.0.1.10 grafana_servers: - host: 10.0.1.10 alertmanager_servers: - host: 10.0.1.10 -
详细 TiFlash 配置模版
# # 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 # deploy_dir: "/tidb-deploy/monitored-9100" # data_dir: "/tidb-data/monitored-9100" # log_dir: "/tidb-deploy/monitored-9100/log" # # Server configs are used to specify the runtime configuration of TiDB components. # # All configuration items can be found in TiDB docs: # # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/ # # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/ # # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/ # # All configuration items use points to represent the hierarchy, e.g: # # readpool.storage.use-unified-pool # # # # You can overwrite this configuration via the instance-level `config` field. server_configs: tidb: log.slow-threshold: 300 tikv: # server.grpc-concurrency: 4 # raftstore.apply-pool-size: 2 # raftstore.store-pool-size: 2 # rocksdb.max-sub-compactions: 1 # storage.block-cache.capacity: "16GB" # readpool.unified.max-thread-count: 12 readpool.storage.use-unified-pool: false readpool.coprocessor.use-unified-pool: true pd: schedule.leader-schedule-limit: 4 schedule.region-schedule-limit: 2048 schedule.replica-schedule-limit: 64 replication.enable-placement-rules: true tiflash: # Maximum memory usage for processing a single query. Zero means unlimited. profiles.default.max_memory_usage: 10000000000 # Maximum memory usage for processing all concurrently running queries on the server. Zero means unlimited. profiles.default.max_memory_usage_for_all_queries: 0 pd_servers: - host: 10.0.1.4 # ssh_port: 22 # name: "pd-1" # client_port: 2379 # peer_port: 2380 # deploy_dir: "/tidb-deploy/pd-2379" # data_dir: "/tidb-data/pd-2379" # log_dir: "/tidb-deploy/pd-2379/log" # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.pd` values. # config: # schedule.max-merge-region-size: 20 # schedule.max-merge-region-keys: 200000 - host: 10.0.1.5 - host: 10.0.1.6 tidb_servers: - host: 10.0.1.7 # ssh_port: 22 # port: 4000 # status_port: 10080 # deploy_dir: "/tidb-deploy/tidb-4000" # log_dir: "/tidb-deploy/tidb-4000/log" # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.tidb` values. # config: # log.slow-query-file: tidb-slow-overwrited.log - host: 10.0.1.8 - host: 10.0.1.9 tikv_servers: - host: 10.0.1.1 # ssh_port: 22 # port: 20160 # status_port: 20180 # deploy_dir: "/tidb-deploy/tikv-20160" # data_dir: "/tidb-data/tikv-20160" # log_dir: "/tidb-deploy/tikv-20160/log" # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.tikv` values. # config: # server.grpc-concurrency: 4 # server.labels: { zone: "zone1", dc: "dc1", host: "host1" } - host: 10.0.1.2 - host: 10.0.1.3 tiflash_servers: - host: 10.0.1.11 data_dir: /tidb-data/tiflash-9000 deploy_dir: /tidb-deploy/tiflash-9000 # ssh_port: 22 # tcp_port: 9000 # http_port: 8123 # flash_service_port: 3930 # flash_proxy_port: 20170 # flash_proxy_status_port: 20292 # metrics_port: 8234 # deploy_dir: /tidb-deploy/tiflash-9000 # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.tiflash` values. # config: # logger.level: "info" # learner_config: # log-level: "info" # - host: 10.0.1.12 # - host: 10.0.1.13 monitoring_servers: - host: 10.0.1.10 # ssh_port: 22 # port: 9090 # deploy_dir: "/tidb-deploy/prometheus-8249" # data_dir: "/tidb-data/prometheus-8249" # log_dir: "/tidb-deploy/prometheus-8249/log" grafana_servers: - host: 10.0.1.10 # port: 3000 # deploy_dir: /tidb-deploy/grafana-3000 alertmanager_servers: - host: 10.0.1.10 # ssh_port: 22 # web_port: 9093 # cluster_port: 9094 # deploy_dir: "/tidb-deploy/alertmanager-9093" # data_dir: "/tidb-data/alertmanager-9093" # log_dir: "/tidb-deploy/alertmanager-9093/log"
关键参数介绍
-
需要将配置模板中
replication.enable-placement-rules设置为true，以开启 PD 的 Placement Rules 功能。 -
tiflash_servers实例级别配置"-host"目前只支持 IP，不支持域名。 -
TiFlash 具体的参数配置介绍可参考 TiFlash 参数配置。
注意：
无需手动创建配置文件中的
tidb用户，TiUP cluster 组件会在目标主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。如果部署目录配置为相对路径，会部署在用户家目录下。
3、TiCDC 部署拓扑
本文介绍 TiCDC 部署的拓扑，以及如何在最小拓扑的基础上同时部署 TiCDC。TiCDC 是 4.0 版本开始支持的 TiDB 增量数据同步工具，支持多种下游 (TiDB/MySQL/MQ)。相比于 TiDB Binlog，TiCDC 有延迟更低、天然高可用等优点。
拓扑信息
| 实例 | 个数 | 物理机配置 | IP | 配置 |
|---|---|---|---|---|
| TiDB | 3 | 16 VCore 32GB * 1 | 10.0.1.1 10.0.1.2 10.0.1.3 | 默认端口 全局目录配置 |
| PD | 3 | 4 VCore 8GB * 1 | 10.0.1.4 10.0.1.5 10.0.1.6 | 默认端口 全局目录配置 |
| TiKV | 3 | 16 VCore 32GB 2TB (nvme ssd) * 1 | 10.0.1.7 10.0.1.8 10.0.1.9 | 默认端口 全局目录配置 |
| CDC | 3 | 8 VCore 16GB * 1 | 10.0.1.11 10.0.1.12 10.0.1.13 | 默认端口 全局目录配置 |
| Monitoring & Grafana | 1 | 4 VCore 8GB * 1 500GB (ssd) | 10.0.1.11 | 默认端口 全局目录配置 |
拓扑模版
简单 TiCDC 配置模板
# # 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"
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
tikv_servers:
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
cdc_servers:
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
monitoring_servers:
- host: 10.0.1.10
grafana_servers:
- host: 10.0.1.10
alertmanager_servers:
- host: 10.0.1.10详细 TiCDC 配置模板
# # 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
# deploy_dir: "/tidb-deploy/monitored-9100"
# data_dir: "/tidb-data/monitored-9100"
# log_dir: "/tidb-deploy/monitored-9100/log"
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
# # You can overwrite this configuration via the instance-level `config` field.
server_configs:
tidb:
log.slow-threshold: 300
tikv:
# server.grpc-concurrency: 4
# raftstore.apply-pool-size: 2
# raftstore.store-pool-size: 2
# rocksdb.max-sub-compactions: 1
# storage.block-cache.capacity: "16GB"
# readpool.unified.max-thread-count: 12
readpool.storage.use-unified-pool: false
readpool.coprocessor.use-unified-pool: true
pd:
schedule.leader-schedule-limit: 4
schedule.region-schedule-limit: 2048
schedule.replica-schedule-limit: 64
pd_servers:
- host: 10.0.1.4
# ssh_port: 22
# name: "pd-1"
# client_port: 2379
# peer_port: 2380
# deploy_dir: "/tidb-deploy/pd-2379"
# data_dir: "/tidb-data/pd-2379"
# log_dir: "/tidb-deploy/pd-2379/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.pd` values.
# config:
# schedule.max-merge-region-size: 20
# schedule.max-merge-region-keys: 200000
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
# ssh_port: 22
# port: 4000
# status_port: 10080
# deploy_dir: "/tidb-deploy/tidb-4000"
# log_dir: "/tidb-deploy/tidb-4000/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.tidb` values.
# config:
# log.slow-query-file: tidb-slow-overwrited.log
- host: 10.0.1.2
- host: 10.0.1.3
tikv_servers:
- host: 10.0.1.7
# ssh_port: 22
# port: 20160
# status_port: 20180
# deploy_dir: "/tidb-deploy/tikv-20160"
# data_dir: "/tidb-data/tikv-20160"
# log_dir: "/tidb-deploy/tikv-20160/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.tikv` values.
# config:
# server.grpc-concurrency: 4
# server.labels: { zone: "zone1", dc: "dc1", host: "host1" }
- host: 10.0.1.8
- host: 10.0.1.9
cdc_servers:
- host: 10.0.1.1
port: 8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"
- host: 10.0.1.2
port: 8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"
- host: 10.0.1.3
port: 8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"
monitoring_servers:
- host: 10.0.1.10
# ssh_port: 22
# port: 9090
# deploy_dir: "/tidb-deploy/prometheus-8249"
# data_dir: "/tidb-data/prometheus-8249"
# log_dir: "/tidb-deploy/prometheus-8249/log"
grafana_servers:
- host: 10.0.1.10
# port: 3000
# deploy_dir: /tidb-deploy/grafana-3000
alertmanager_servers:
- host: 10.0.1.10
# ssh_port: 22
# web_port: 9093
# cluster_port: 9094
# deploy_dir: "/tidb-deploy/alertmanager-9093"
# data_dir: "/tidb-data/alertmanager-9093"
# log_dir: "/tidb-deploy/alertmanager-9093/log"注意：
无需手动创建配置文件中的
tidb用户，TiUP cluster 组件会在目标主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。如果部署目录配置为相对路径，会部署在用户家目录下。
4、TiDB Binlog 部署拓扑
本文介绍在部署最小拓扑集群的基础上，同时部署 TiDB Binlog。TiDB Binlog 是目前广泛使用的增量同步组件，可提供准实时备份和同步功能。
拓扑信息
| 实例 | 个数 | 物理机配置 | IP | 配置 |
|---|---|---|---|---|
| TiDB | 3 | 16 VCore 32 GB | 10.0.1.1 10.0.1.2 10.0.1.3 | 默认端口配置； 开启 enable_binlog； 开启 ignore-error |
| PD | 3 | 4 VCore 8 GB | 10.0.1.4 10.0.1.5 10.0.1.6 | 默认端口配置 |
| TiKV | 3 | 16 VCore 32 GB | 10.0.1.7 10.0.1.8 10.0.1.9 | 默认端口配置 |
| Pump | 3 | 8 VCore 16GB | 10.0.1.1 10.0.1.7 10.0.1.8 | 默认端口配置； 设置 GC 时间 7 天 |
| Drainer | 1 | 8 VCore 16GB | 10.0.1.12 | 默认端口配置； 设置默认初始化 commitTS -1 为最近的时间戳 配置下游目标 TiDB 10.0.1.12:4000 |
拓扑模版
简单 TiDB Binlog 配置模板
# # 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"
server_configs:
tidb:
binlog.enable: true
binlog.ignore-error: true
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
tikv_servers:
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
pump_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
drainer_servers:
- host: 10.0.1.12
config:
syncer.db-type: "tidb"
syncer.to.host: "10.0.1.12"
syncer.to.user: "root"
syncer.to.password: ""
syncer.to.port: 4000
monitoring_servers:
- host: 10.0.1.10
grafana_servers:
- host: 10.0.1.10
alertmanager_servers:
- host: 10.0.1.10详细 TiDB Binlog 配置模板
# # 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
# deploy_dir: "/tidb-deploy/monitored-9100"
# data_dir: "/tidb-data/monitored-9100"
# log_dir: "/tidb-deploy/monitored-9100/log"
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
# # You can overwrite this configuration via the instance-level `config` field.
server_configs:
tidb:
log.slow-threshold: 300
binlog.enable: true
binlog.ignore-error: true
tikv:
# server.grpc-concurrency: 4
# raftstore.apply-pool-size: 2
# raftstore.store-pool-size: 2
# rocksdb.max-sub-compactions: 1
# storage.block-cache.capacity: "16GB"
# readpool.unified.max-thread-count: 12
readpool.storage.use-unified-pool: false
readpool.coprocessor.use-unified-pool: true
pd:
schedule.leader-schedule-limit: 4
schedule.region-schedule-limit: 2048
schedule.replica-schedule-limit: 64
pd_servers:
- host: 10.0.1.4
# ssh_port: 22
# name: "pd-1"
# client_port: 2379
# peer_port: 2380
# deploy_dir: "/tidb-deploy/pd-2379"
# data_dir: "/tidb-data/pd-2379"
# log_dir: "/tidb-deploy/pd-2379/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.pd` values.
# config:
# schedule.max-merge-region-size: 20
# schedule.max-merge-region-keys: 200000
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
# ssh_port: 22
# port: 4000
# status_port: 10080
# deploy_dir: "/tidb-deploy/tidb-4000"
# log_dir: "/tidb-deploy/tidb-4000/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.tidb` values.
# config:
# log.slow-query-file: tidb-slow-overwrited.log
- host: 10.0.1.2
- host: 10.0.1.3
tikv_servers:
- host: 10.0.1.7
# ssh_port: 22
# port: 20160
# status_port: 20180
# deploy_dir: "/tidb-deploy/tikv-20160"
# data_dir: "/tidb-data/tikv-20160"
# log_dir: "/tidb-deploy/tikv-20160/log"
# numa_node: "0,1"
# # The following configs are used to overwrite the `server_configs.tikv` values.
# config:
# server.grpc-concurrency: 4
# server.labels: { zone: "zone1", dc: "dc1", host: "host1" }
- host: 10.0.1.8
- host: 10.0.1.9
pump_servers:
- host: 10.0.1.1
ssh_port: 22
port: 8250
deploy_dir: "/tidb-deploy/pump-8249"
data_dir: "/tidb-data/pump-8249"
# The following configs are used to overwrite the `server_configs.drainer` values.
config:
gc: 7
- host: 10.0.1.2
ssh_port: 22
port: 8250
deploy_dir: "/tidb-deploy/pump-8249"
data_dir: "/tidb-data/pump-8249"
# The following configs are used to overwrite the `server_configs.drainer` values.
config:
gc: 7
- host: 10.0.1.3
ssh_port: 22
port: 8250
deploy_dir: "/tidb-deploy/pump-8249"
data_dir: "/tidb-data/pump-8249"
# The following configs are used to overwrite the `server_configs.drainer` values.
config:
gc: 7
drainer_servers:
- host: 10.0.1.12
port: 8249
data_dir: "/tidb-data/drainer-8249"
# If drainer doesn't have a checkpoint, use initial commitTS as the initial checkpoint.
# Will get a latest timestamp from pd if commit_ts is set to -1 (the default value).
commit_ts: -1
deploy_dir: "/tidb-deploy/drainer-8249"
# The following configs are used to overwrite the `server_configs.drainer` values.
config:
syncer.db-type: "tidb"
syncer.to.host: "10.0.1.12"
syncer.to.user: "root"
syncer.to.password: ""
syncer.to.port: 4000
monitoring_servers:
- host: 10.0.1.10
# ssh_port: 22
# port: 9090
# deploy_dir: "/tidb-deploy/prometheus-8249"
# data_dir: "/tidb-data/prometheus-8249"
# log_dir: "/tidb-deploy/prometheus-8249/log"
grafana_servers:
- host: 10.0.1.10
# port: 3000
# deploy_dir: /tidb-deploy/grafana-3000
alertmanager_servers:
- host: 10.0.1.10
# ssh_port: 22
# web_port: 9093
# cluster_port: 9094
# deploy_dir: "/tidb-deploy/alertmanager-9093"
# data_dir: "/tidb-data/alertmanager-9093"
# log_dir: "/tidb-deploy/alertmanager-9093/log"关键参数介绍
拓扑配置模版的关键参数如下：
-
binlog.enable: true开启 binlog 服务，默认为 false。
-
binlog.ignore-error: true高可用场景建议开启，如果设置为 true，发生错误时，TiDB 会停止写入 binlog，并且在监控项
tidb_server_critical_error_total上计数加 1；如果设置为 false，一旦写入 binlog 失败，会停止整个 TiDB 的服务。
注意：
编辑配置文件模版时，如无需自定义端口或者目录，仅修改 IP 即可。
无需手动创建配置文件中的
tidb用户，TiUP cluster 组件会在目标主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。如果部署目录配置为相对路径，会部署在用户家目录下。
5、跨数据中心部署拓扑
本文以典型的两地三中心为例，介绍跨数据中心部署的拓扑以及关键参数。
拓扑信息
| 实例 | 个数 | 物理机配置 | BJ IP | SH IP | 配置 |
|---|---|---|---|---|---|
| TiDB | 3 | 16 VCore 32GB * 1 | 10.0.1.1 10.0.1.2 10.0.1.3 10.0.1.4 | 10.0.1.5 | 默认端口 全局目录配置 |
| PD | 3 | 4 VCore 8GB * 1 | 10.0.1.6 10.0.1.7 10.0.1.8 10.0.1.9 | 10.0.1.10 | 默认端口 全局目录配置 |
| TiKV | 3 | 16 VCore 32GB 2TB (nvme ssd) * 1 | 10.0.1.11 10.0.1.12 10.0.1.13 10.0.1.14 | 10.0.1.15 | 默认端口 全局目录配置 |
| Monitoring & Grafana | 1 | 4 VCore 8GB * 1 500GB (ssd) | 10.0.1.16 | 默认端口 全局目录配置 |
拓扑模版
跨机房配置模板
# Tip: PD priority needs to be manually set using the PD-ctl client tool. such as, member Leader_priority PD-name numbers.
# 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:
node_exporter_port: 9100
blackbox_exporter_port: 9115
deploy_dir: "/tidb-deploy/monitored-9100"
server_configs:
tidb:
log.level: debug
log.slow-query-file: tidb-slow.log
tikv:
server.grpc-compression-type: gzip
readpool.storage.use-unified-pool: true
readpool.storage.low-concurrency: 8
pd:
replication.location-labels: ["zone","dc","rack","host"]
replication.max-replicas: 5
label-property:
reject-leader:
- key: "dc"
value: "sha"
pd_servers:
- host: 10.0.1.6
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
- host: 10.0.1.10
tidb_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
- host: 10.0.1.4
- host: 10.0.1.5
tikv_servers:
- host: 10.0.1.11
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: "/tidb-deploy/tikv-20160"
data_dir: "/tidb-data/tikv-20160"
config:
server.labels:
zone: bj
dc: bja
rack: rack1
host: host1
- host: 10.0.1.12
ssh_port: 22
port: 20161
status_port: 20181
deploy_dir: "/tidb-deploy/tikv-20161"
data_dir: "/tidb-data/tikv-20161"
config:
server.labels:
zone: bj
dc: bja
rack: rack1
host: host2
- host: 10.0.1.13
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: "/tidb-deploy/tikv-20160"
data_dir: "/tidb-data/tikv-20160"
config:
server.labels:
zone: bj
dc: bjb
rack: rack1
host: host1
- host: 10.0.1.14
ssh_port: 22
port: 20161
status_port: 20181
deploy_dir: "/tidb-deploy/tikv-20161"
data_dir: "/tidb-data/tikv-20161"
config:
server.labels:
zone: bj
dc: bjb
rack: rack1
host: host2
- host: 10.0.1.15
ssh_port: 22
port: 20160
deploy_dir: "/tidb-deploy/tikv-20160"
data_dir: "/tidb-data/tikv-20160"
config:
server.labels:
zone: sh
dc: sha
rack: rack1
host: host1
readpool.storage.use-unified-pool: true
readpool.storage.low-concurrency: 10
raftstore.raft-min-election-timeout-ticks: 1000
raftstore.raft-max-election-timeout-ticks: 1020
monitoring_servers:
- host: 10.0.1.16
grafana_servers:
- host: 10.0.1.16关键参数配置
本节介绍跨数据中心部署 TiDB 集群的关键参数配置。
TiKV 参数
-
设置 gRPC 的压缩格式，默认为
none。为提高跨机房部署场景的目标节点间 gRPC 包的传输速度，建议设置为 gzip 格式。server.grpc-compression-type: gzip -
label 配置
由于采用跨机房部署 TiKV，为了避免物理机宕机导致 Region Group 默认的 5 副本中丢失 3 副本，使集群不可用的问题，可以通过 label 来实现 PD 智能调度，保证同中心、同机柜、同机器 TiKV 实例不会出现 Region Group 有 3 副本的情况。
-
TiKV 配置
相同物理机配置相同的 host 级别 label 信息：
config: server.labels: zone: bj dc: bja rack: rack1 host: host2 -
防止异地 TiKV 节点发起不必要的 Raft 选举，需要将异地 TiKV 节点发起选举时经过最少的 tick 个数和最多经过的 tick 个数都调大，这两个参数默认设置均为
0。raftstore.raft-min-election-timeout-ticks: 1000 raftstore.raft-max-election-timeout-ticks: 1020
PD 参数
-
PD 元数据信息记录 TiKV 集群的拓扑信息，根据四个维度调度 Raft Group 副本。
replication.location-labels: ["zone","dc","rack","host"] -
调整 Raft Group 的副本数据量为 5 ，保证集群的高可用性。
replication.max-replicas: 5 -
拒绝异地机房 TiKV 的 Raft 副本选举为 Leader。
label-property: reject-leader: - key: "dc" value: "sha"
注意：
无需手动创建配置文件中的
tidb用户，TiUP cluster 组件会在目标主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。如果部署目录配置为相对路径，会部署在用户家目录下。
6、混合部署拓扑
本文介绍 TiDB 集群的 TiKV 和 TiDB 混合部署拓扑以及主要参数。常见的场景为，部署机为多路 CPU 处理器，内存也充足，为提高物理机资源利用率，可单机多实例部署，即 TiDB、TiKV 通过 numa 绑核，隔离 CPU 资源。PD 和 Prometheus 混合部署，但两者的数据目录需要使用独立的文件系统。
拓扑信息
| 实例 | 个数 | 物理机配置 | IP | 配置 |
|---|---|---|---|---|
| TiDB | 6 | 32 VCore 64GB | 10.0.1.1 10.0.1.2 10.0.1.3 | 配置 numa 绑核操作 |
| PD | 3 | 16 VCore 32 GB | 10.0.1.4 10.0.1.5 10.0.1.6 | 配置 location_lables 参数 |
| TiKV | 6 | 32 VCore 64GB | 10.0.1.7 10.0.1.8 10.0.1.9 | 1. 区分实例级别的 port、status_port； 2. 配置全局参数 readpool、storage 以及 raftstore； 3. 配置实例级别 host 维度的 labels； 4. 配置 numa 绑核操作 |
| Monitoring & Grafana | 1 | 4 VCore 8GB * 1 500GB (ssd) | 10.0.1.10 | 默认配置 |
拓扑模版
简单混部配置模板
# # 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"
server_configs:
tikv:
readpool.unified.max-thread-count:
readpool.storage.use-unified-pool: false
readpool.coprocessor.use-unified-pool: true
storage.block-cache.capacity: ""
raftstore.capacity: ""
pd:
replication.location-labels: ["host"]
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
port: 4000
status_port: 10080
numa_node: "0"
- host: 10.0.1.1
port: 4001
status_port: 10081
numa_node: "1"
- host: 10.0.1.2
port: 4000
status_port: 10080
numa_node: "0"
- host: 10.0.1.2
port: 4001
status_port: 10081
numa_node: "1"
- host: 10.0.1.3
port: 4000
status_port: 10080
numa_node: "0"
- host: 10.0.1.3
port: 4001
status_port: 10081
numa_node: "1"
tikv_servers:
- host: 10.0.1.7
port: 20160
status_port: 20180
numa_node: "0"
config:
server.labels: { host: "tikv1" }
- host: 10.0.1.7
port: 20161
status_port: 20181
numa_node: "1"
config:
server.labels: { host: "tikv1" }
- host: 10.0.1.8
port: 20160
status_port: 20180
numa_node: "0"
config:
server.labels: { host: "tikv2" }
- host: 10.0.1.8
port: 20161
status_port: 20181
numa_node: "1"
config:
server.labels: { host: "tikv2" }
- host: 10.0.1.9
port: 20160
status_port: 20180
numa_node: "0"
config:
server.labels: { host: "tikv3" }
- host: 10.0.1.9
port: 20161
status_port: 20181
numa_node: "1"
config:
server.labels: { host: "tikv3" }
monitoring_servers:
- host: 10.0.1.10
grafana_servers:
- host: 10.0.1.10
alertmanager_servers:
- host: 10.0.1.10 详细混部配置模板
# # 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:
node_exporter_port: 9100
blackbox_exporter_port: 9115
deploy_dir: "/tidb-deploy/monitored-9100"
data_dir: "/tidb-data-monitored-9100"
log_dir: "/tidb-deploy/monitored-9100/log"
server_configs:
tidb:
log.slow-threshold: 300
tikv:
readpool.unified.max-thread-count:
readpool.storage.use-unified-pool: false
readpool.coprocessor.use-unified-pool: true
storage.block-cache.capacity: ""
raftstore.capacity: ""
pd:
replication.location-labels: ["host"]
schedule.leader-schedule-limit: 4
schedule.region-schedule-limit: 2048
schedule.replica-schedule-limit: 64
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.1
port: 4000
status_port: 10080
deploy_dir: "/tidb-deploy/tidb-4000"
log_dir: "/tidb-deploy/tidb-4000/log"
numa_node: "0"
- host: 10.0.1.1
port: 4001
status_port: 10081
deploy_dir: "/tidb-deploy/tidb-4001"
log_dir: "/tidb-deploy/tidb-4001/log"
numa_node: "1"
- host: 10.0.1.2
port: 4000
status_port: 10080
deploy_dir: "/tidb-deploy/tidb-4000"
log_dir: "/tidb-deploy/tidb-4000/log"
numa_node: "0"
- host: 10.0.1.2
port: 4001
status_port: 10081
deploy_dir: "/tidb-deploy/tidb-4001"
log_dir: "/tidb-deploy/tidb-4001/log"
numa_node: "1"
- host: 10.0.1.3
port: 4000
status_port: 10080
deploy_dir: "/tidb-deploy/tidb-4000"
log_dir: "/tidb-deploy/tidb-4000/log"
numa_node: "0"
- host: 10.0.1.3
port: 4001
status_port: 10081
deploy_dir: "/tidb-deploy/tidb-4001"
log_dir: "/tidb-deploy/tidb-4001/log"
numa_node: "1"
tikv_servers:
- host: 10.0.1.7
port: 20160
status_port: 20180
deploy_dir: "/tidb-deploy/tikv-20160"
data_dir: "/tidb-data/tikv-20160"
log_dir: "/tidb-deploy/tikv-20160/log"
numa_node: "0"
config:
server.labels: { host: "tikv1" }
- host: 10.0.1.7
port: 20161
status_port: 20181
deploy_dir: "/tidb-deploy/tikv-20161"
data_dir: "/tidb-data/tikv-20161"
log_dir: "/tidb-deploy/tikv-20161/log"
numa_node: "1"
config:
server.labels: { host: "tikv1" }
- host: 10.0.1.8
port: 20160
status_port: 20180
deploy_dir: "/tidb-deploy/tikv-20160"
data_dir: "/tidb-data/tikv-20160"
log_dir: "/tidb-deploy/tikv-20160/log"
numa_node: "0"
config:
server.labels: { host: "tikv2" }
- host: 10.0.1.8
port: 20161
status_port: 20181
deploy_dir: "/tidb-deploy/tikv-20161"
data_dir: "/tidb-data/tikv-20161"
log_dir: "/tidb-deploy/tikv-20161/log"
numa_node: "1"
config:
server.labels: { host: "tikv2" }
- host: 10.0.1.9
port: 20160
status_port: 20180
deploy_dir: "/tidb-deploy/tikv-20160"
data_dir: "/tidb-data/tikv-20160"
log_dir: "/tidb-deploy/tikv-20160/log"
numa_node: "0"
config:
server.labels: { host: "tikv3" }
- host: 10.0.1.9
port: 20161
status_port: 20181
deploy_dir: "/tidb-deploy/tikv-20161"
data_dir: "/tidb-data/tikv-20161"
log_dir: "/tidb-deploy/tikv-20161/log"
numa_node: "1"
config:
server.labels: { host: "tikv3" }
monitoring_servers:
- host: 10.0.1.10
# ssh_port: 22
# port: 9090
# deploy_dir: "/tidb-deploy/prometheus-8249"
# data_dir: "/tidb-data/prometheus-8249"
# log_dir: "/tidb-deploy/prometheus-8249/log"
grafana_servers:
- host: 10.0.1.10
# port: 3000
# deploy_dir: /tidb-deploy/grafana-3000
alertmanager_servers:
- host: 10.0.1.10
# ssh_port: 22
# web_port: 9093
# cluster_port: 9094
# deploy_dir: "/tidb-deploy/alertmanager-9093"
# data_dir: "/tidb-data/alertmanager-9093"
# log_dir: "/tidb-deploy/alertmanager-9093/log"
混合部署的关键参数介绍
本节介绍单机多实例的关键参数，主要用于 TiDB、TiKV 的单机多实例部署场景。你需要按照提供的计算公式，将结果填写至上一步的配置模板中。
-
TiKV 进行配置优化
-
readpool 线程池自适应，配置
readpool.unified.max-thread-count参数可以使readpool.storage和readpool.coprocessor共用统一线程池，同时要分别设置自适应开关。-
开启
readpool.storage和readpool.coprocessor：readpool.storage.use-unified-pool: false readpool.coprocessor.use-unified-pool: true -
计算公式如下：
readpool.unified.max-thread-count = cores * 0.8 / TiKV 数量
-
-
storage CF (all RocksDB column families) 内存自适应，配置
storage.block-cache.capacity参数即可实现 CF 之间自动平衡内存使用。-
storage.block-cache默认开启 CF 自适应，无需修改。storage.block-cache.shared: true -
计算公式如下：
storage.block-cache.capacity = (MEM_TOTAL * 0.5 / TiKV 实例数量)
-
-
如果多个 TiKV 实例部署在同一块物理磁盘上，需要在 tikv 配置中添加 capacity 参数：
raftstore.capacity = 磁盘总容量 / TiKV 实例数量
-
-
label 调度配置
由于采用单机多实例部署 TiKV，为了避免物理机宕机导致 Region Group 默认 3 副本的 2 副本丢失，导致集群不可用的问题，可以通过 label 来实现 PD 智能调度，保证同台机器的多 TiKV 实例不会出现 Region Group 只有 2 副本的情况。
-
TiKV 配置
相同物理机配置相同的 host 级别 label 信息：
config: server.labels: host: tikv1 -
PD 配置
PD 需要配置 labels 类型来识别并调度 Region：
pd: replication.location-labels: ["host"]
-
-
numa_node绑核-
在实例参数模块配置对应的
numa_node参数，并添加对应的物理 CPU 的核数； -
numa 绑核使用前，确认已经安装 numactl 工具，以及物理机对应的物理机 CPU 的信息后，再进行参数配置；
-
numa_node这个配置参数与numactl --membind配置对应。
-
注意：
编辑配置文件模版时，注意修改必要参数、IP、端口及目录。
各个组件的 deploy_dir，默认会使用 global 中的
。例如 tidb 端口指定 4001，则 deploy_dir 默认为 /tidb-deploy/tidb-4001。因此，在多实例场景下指定非默认端口时，无需再次指定目录。/ - 无需手动创建配置文件中的
tidb用户，TiUP cluster 组件会在部署主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。如果部署目录配置为相对路径，会部署在用户家目录下。
4、安装与启动
1、使用 TiUP 部署 TiDB 集群
TiUP 是 TiDB 4.0 版本引入的集群运维工具，TiUP cluster 是 TiUP 提供的使用 Golang 编写的集群管理组件，通过 TiUP cluster 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群；管理 TiDB 集群参数。
目前 TiUP 可以支持部署 TiDB、TiFlash、TiDB Binlog、TiCDC，以及监控系统。本文将介绍不同集群拓扑的具体部署步骤。
第 1 步：软硬件环境需求及前置检查
软硬件环境需求
环境与系统配置检查
第 2 步：在中控机上安装 TiUP 组件
使用普通用户登录中控机，以 tidb 用户为例，后续安装 TiUP 及集群管理操作均通过该用户完成：
-
执行如下命令安装 TiUP 工具：
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh -
按如下步骤设置 TiUP 环境变量：
重新声明全局环境变量：
source .bash_profile确认 TiUP 工具是否安装：
which tiup -
安装 TiUP cluster 组件
tiup cluster -
如果已经安装，则更新 TiUP cluster 组件至最新版本：
tiup update --self && tiup update cluster预期输出
“Update successfully!”字样。 -
验证当前 TiUP cluster 版本信息。执行如下命令查看 TiUP cluster 组件版本：
tiup --binary cluster
第 3 步：编辑初始化配置文件
请根据不同的集群拓扑，编辑 TiUP 所需的集群初始化配置文件。
这里举出常见的 6 种场景，请根据链接中的拓扑说明，以及给出的配置文件模板，新建一个配置文件 topology.yaml。如果有其他组合场景的需求，请根据多个模板自行调整。
-
最小拓扑架构
最基本的集群拓扑，包括 tidb-server、tikv-server、pd-server，适合 OLTP 业务。
-
增加 TiFlash 拓扑架构
包含最小拓扑的基础上，同时部署 TiFlash。TiFlash 是列式的存储引擎，已经逐步成为集群拓扑的标配。适合 Real-Time HTAP 业务。
-
增加 TiCDC 拓扑架构
包含最小拓扑的基础上，同时部署 TiCDC。TiCDC 是 4.0 版本开始支持的 TiDB 增量数据同步工具，支持多种下游 (TiDB/MySQL/MQ)。相比于 TiDB Binlog，TiCDC 有延迟更低、天然高可用等优点。在部署完成后，需要启动 TiCDC，通过
cdc cli创建同步任务。 -
增加 TiDB Binlog 拓扑架构
包含最小拓扑的基础上，同时部署 TiDB Binlog。TiDB Binlog 是目前广泛使用的增量同步组件，可提供准实时备份和同步功能。
-
混合部署拓扑架构
适用于单台机器，混合部署多个实例的情况，也包括单机多实例，需要额外增加目录、端口、资源配比、label 等配置。
-
跨机房部署拓扑架构
以典型的
两地三中心架构为例，介绍跨机房部署架构，以及需要注意的关键设置。
注意：
对于需要全局生效的参数，请在配置文件中
server_configs的对应组件下配置。对于需要某个节点生效的参数，请在具体节点的
config中配置。配置的层次结构使用
.表示。如：log.slow-threshold。更多格式参考 TiUP 配置参数模版。更多参数说明，请参考 TiDB
config.toml.example、TiKVconfig.toml.example、 PDconfig.toml.example和 TiFlash 配置参数。
第 4 步：执行部署命令
注意：
通过 TiUP 进行集群部署可以使用密钥或者交互密码方式来进行安全认证：
如果是密钥方式，可以通过
-i或者--identity_file来指定密钥的路径；如果是密码方式，无需添加其他参数，
Enter即可进入密码交互窗口。
Copy
tiup cluster deploy tidb-test v4.0.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]以上部署命令中：
-
通过 TiUP cluster 部署的集群名称为
tidb-test -
部署版本为
v4.0.0，最新版本可以通过执行tiup list tidb来查看 TiUP 支持的版本 -
初始化配置文件为
topology.yaml -
–user root：通过 root 用户登录到目标主机完成集群部署，该用户需要有 ssh 到目标机器的权限，并且在目标机器有 sudo 权限。也可以用其他有 ssh 和 sudo 权限的用户完成部署。
-
[-i] 及 [-p]：非必选项，如果已经配置免密登陆目标机，则不需填写。否则选择其一即可，[-i] 为可登录到部署机的 root 用户（或 –user 指定的其他用户）的私钥，也可使用 [-p] 交互式输入该用户的密码
预期日志结尾输出会有 Deployed clustertidb-testsuccessfully 关键词，表示部署成功。
第 5 步：查看 TiUP 管理的集群情况
Copy
tiup cluster listTiUP 支持管理多个 TiDB 集群，该命令会输出当前通过 TiUP cluster 管理的所有集群信息，包括集群名称、部署用户、版本、密钥信息等：
Starting /home/tidb/.tiup/components/cluster/v1.0.0/cluster list
Name User Version Path PrivateKey
---- ---- ------- ---- ----------
tidb-test tidb v4.0.0 /home/tidb/.tiup/storage/cluster/clusters/tidb-test /home/tidb/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa第 6 步：检查部署的 TiDB 集群情况
例如，执行如下命令检查 tidb-test 集群情况：
Copy
tiup cluster display tidb-test预期输出包括 tidb-test 集群中实例 ID、角色、主机、监听端口和状态（由于还未启动，所以状态为 Down/inactive）、目录信息。
第 7 步：启动集群
Copy
tiup cluster start tidb-test预期结果输出 Started clustertidb-testsuccessfully 标志启动成功。
第 8 步：验证集群运行状态
-
通过 TiUP 检查集群状态
Copy
tiup cluster display tidb-test预期结果输出，注意 Status 状态信息为 Up 说明集群状态正常
-
执行如下命令登录数据库：
Copy
mysql -u root -h 10.0.1.4 -P 4000此外，也需要验证监控系统、TiDB Dashboard 的运行状态，以及简单命令的执行，验证方式可参考验证集群运行状态。
探索更多
如果你已同时部署了 TiFlash，接下来可参阅以下文档：
-
使用 TiFlash
-
TiFlash 集群运维
-
TiFlash 报警规则与处理方法
-
TiFlash 常见问题
如果你已同时部署了 TiCDC，接下来可参阅以下文档：
-
TiCDC 任务管理
-
TiCDC 常见问题
注意：
TiDB、TiUP 及 TiDB Dashboard 默认会收集使用情况信息，并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为，请参见遥测。
2、使用 TiUP 离线部署 TiDB 集群
本文介绍如何使用 TiUP 离线部署 TiDB 集群，具体的操作步骤如下。
1. 准备 TiUP 离线组件包
方式一：下载官方 TiUP 离线组件包
在 官方下载页面 选择对应版本的离线镜像包。
方式二：使用 tiup mirror clone 命令手动打包离线组件包
-
在线环境中安装 TiUP 包管理器工具
-
执行如下命令安装 TiUP 工具：
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh -
重新声明全局环境变量：
source .bash_profile -
确认 TiUP 工具是否安装：
which tiup
-
-
使用 TiUP 制作离线镜像
-
在一台和外网相通的机器上拉取需要的组件：
tiup mirror clone tidb-community-server-${version}-linux-amd64 ${version} --os=linux --arch=amd64该命令会在当前目录下创建一个名叫
tidb-community-server-${version}-linux-amd64的目录，里面包含 TiUP 管理的组件包。 -
通过 tar 命令将该组件包打包然后发送到隔离环境的中控机：
tar czvf tidb-community-server-${version}-linux-amd64.tar.gz tidb-community-server-${version}-linux-amd64此时，
tidb-community-server-${version}-linux-amd64.tar.gz就是一个独立的离线环境包。
-
2. 部署离线环境 TiUP 组件
将离线包发送到目标集群的中控机后，执行以下命令安装 TiUP 组件：
Copy
tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz &&
sh tidb-community-server-${version}-linux-amd64/local_install.sh
source /home/tidb/.bash_profile3. TiKV 数据盘挂载
注意：
推荐 TiKV 部署目标机器的数据目录使用 EXT4 文件系统格式。相比于 XFS 文件系统格式，EXT4 文件系统格式在 TiDB 集群部署案例较多，生产环境优先选择使用 EXT4 文件系统格式。
使用 root 用户登录目标机器，将部署目标机器数据盘格式化成 ext4 文件系统，挂载时添加 nodelalloc 和 noatime 挂载参数。nodelalloc 是必选参数，否则 TiUP 安装时检测无法通过；noatime 是可选建议参数。
注意：
如果你的数据盘已经格式化成 ext4 并挂载了磁盘，可先执行
umount /dev/nvme0n1p1命令卸载，从编辑/etc/fstab文件步骤开始执行，添加挂载参数重新挂载即可。
以 /dev/nvme0n1 数据盘为例，具体操作步骤如下：
-
查看数据盘。
fdisk -lDisk /dev/nvme0n1: 1000 GB -
创建分区表。
parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1注意：
使用
lsblk命令查看分区的设备号：对于 nvme 磁盘，生成的分区设备号一般为nvme0n1p1；对于普通磁盘（例如/dev/sdb），生成的的分区设备号一般为sdb1。 -
格式化文件系统。
mkfs.ext4 /dev/nvme0n1p1 -
查看数据盘分区 UUID。
本例中
nvme0n1p1的 UUID 为c51eb23b-195c-4061-92a9-3fad812cc12f。lsblk -fNAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ext4 237b634b-a565-477b-8371-6dff0c41f5ab /boot ├─sda2 swap f414c5c0-f823-4bb1-8fdf-e531173a72ed └─sda3 ext4 547909c1-398d-4696-94c6-03e43e317b60 / sr0 nvme0n1 └─nvme0n1p1 ext4 c51eb23b-195c-4061-92a9-3fad812cc12f -
编辑
/etc/fstab文件，添加nodelalloc挂载参数。vi /etc/fstabUUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2 -
挂载数据盘。
mkdir /data1 && \ mount -a -
执行以下命令，如果文件系统为 ext4，并且挂载参数中包含
nodelalloc，则表示已生效。mount -t ext4/dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered)
4. 配置初始化参数文件 topology.yaml
集群初始化配置文件需要手动编写，完整的全配置参数模版可以参考 Github TiUP 项目配置参数模版。需要在中控机上面创建 YAML 格式配置文件，例如 topology.yaml:
Copy
cat topology.yaml
# # 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"
server_configs:
pd:
replication.enable-placement-rules: true
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
tikv_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
tiflash_servers:
- host: 10.0.1.10
data_dir: /data1/tiflash/data,/data2/tiflash/data
cdc_servers:
- host: 10.0.1.6
- host: 10.0.1.7
- host: 10.0.1.8
monitoring_servers:
- host: 10.0.1.4
grafana_servers:
- host: 10.0.1.4
alertmanager_servers:
- host: 10.0.1.45. 部署 TiDB 集群
/path/to/mirror 是执行 local_install.sh 命令时输出的离线镜像包的位置:
Copy
export TIUP_MIRRORS=/path/to/mirror &&
tiup cluster deploy tidb-test v4.0.0 topology.yaml --user tidb [-p] [-i /home/root/.ssh/gcp_rsa] &&
tiup cluster start tidb-test参数说明：
通过 TiUP cluster 部署的集群名称为
tidb-test部署版本为
v4.0.0，其他版本可以执行tiup list tidb获取初始化配置文件为
topology.yaml–user tidb：通过 tidb 用户登录到目标主机完成集群部署，该用户需要有 ssh 到目标机器的权限，并且在目标机器有 sudo 权限。也可以用其他有 ssh 和 sudo 权限的用户完成部署。
[-i] 及 [-p]：非必选项，如果已经配置免密登陆目标机，则不需填写。否则选择其一即可，[-i] 为可登录到部署机 root 用户（或 –user 指定的其他用户）的私钥，也可使用 [-p] 交互式输入该用户的密码
预期日志结尾输出会有 Deployed clustertidb-testsuccessfully 关键词，表示部署成功。
部署完成后，集群相关操作可参考 cluster 命令。
注意：
TiDB 和 TiUP 默认会收集使用情况信息，并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为，请参见遥测。
3、使用 TiDB Ansible 部署 TiDB 集群
Ansible 是一款自动化运维工具，TiDB Ansible 是 PingCAP 基于 Ansible playbook 功能编写的集群部署工具。本文档介绍如何使用 TiDB Ansible 部署一个完整的 TiDB 集群。
本部署工具可以通过配置文件设置集群拓扑，完成以下各项运维工作：
-
初始化操作系统参数
-
部署 TiDB 集群（包括 PD、TiDB、TiKV 等组件和监控组件）
-
启动集群
-
[闭集群
-
变更组件配置
-
集群扩容缩容
-
升级组件版本
-
集群开启 binlog
-
清除集群数据
-
销毁集群
警告：
对于生产环境，推荐使用 TiUP 部署 TiDB 集群。从 TiDB 4.0 版本开始，不再推荐使用 TiDB Ansible 部署 TiDB 集群，但可以使用 TiUP 直接支持之前的 Ansible 集群。
如果只是希望测试 TiDB 或体验 TiDB 特性，可参考 TiDB 快速上手指南或者使用 Docker Compose 在单机上快速部署 TiDB 集群。
准备机器
-
部署目标机器若干
-
建议 4 台及以上，TiKV 至少 3 实例，且与 TiDB、PD 模块不位于同一主机，详见部署建议。
-
目前支持在 x86_64 (AMD64) 和 ARM64 两种架构上部署 TiDB 集群。在 AMD64 架构下，建议使用 CentOS 7.3 及以上版本 Linux 操作系统；在 ARM 架构下，建议使用 CentOS 7.6 1810 版本 Linux 操作系统。
-
机器之间内网互通。
注意：
使用 TiDB Ansible 方式部署时，TiKV 及 PD 节点数据目录所在磁盘请使用 SSD 磁盘，否则无法通过检测。如果仅验证功能，建议使用 Docker Compose 部署方案单机进行测试。
-
-
部署中控机一台
-
中控机可以是部署目标机器中的某一台。
-
推荐安装 CentOS 7.3 及以上版本 Linux 操作系统（默认包含 Python 2.7）。
-
该机器需开放外网访问，用于下载 TiDB 及相关软件安装包。
-
第 1 步：在中控机上安装系统依赖包
以 root 用户登录中控机，然后根据操作系统类型执行相应的安装命令。
-
如果中控机使用的是 CentOS 7 系统，执行以下命令：
yum -y install epel-release git curl sshpass && \ yum -y install python2-pip -
如果中控机使用的是 Ubuntu 系统，执行以下命令：
apt-get -y install git curl sshpass python-pip
第 2 步：在中控机上创建 tidb 用户，并生成 SSH key
以 root 用户登录中控机，执行以下步骤：
-
创建
tidb用户。useradd -m -d /home/tidb tidb -
设置
tidb用户密码。passwd tidb -
配置
tidb用户 sudo 免密码，将tidb ALL=(ALL) NOPASSWD: ALL添加到文件末尾即可。visudotidb ALL=(ALL) NOPASSWD: ALL -
生成 SSH key。
执行
su命令，从root用户切换到tidb用户下。su - tidb创建
tidb用户 SSH key，提示Enter passphrase时直接回车即可。执行成功后，SSH 私钥文件为/home/tidb/.ssh/id_rsa，SSH 公钥文件为/home/tidb/.ssh/id_rsa.pub。ssh-keygen -t rsaGenerating public/private rsa key pair. Enter file in which to save the key (/home/tidb/.ssh/id_rsa): Created directory '/home/tidb/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/tidb/.ssh/id_rsa. Your public key has been saved in /home/tidb/.ssh/id_rsa.pub. The key fingerprint is: SHA256:eIBykszR1KyECA/h0d7PRKz4fhAeli7IrVphhte7/So [email protected] The key's randomart image is: +---[RSA 2048]----+ |=+o+.o. | |o=o+o.oo | | .O.=.= | | . B.B + | |o B * B S | | * + * + | | o + . | | o E+ . | |o ..+o. | +----[SHA256]-----+
第 3 步：在中控机器上下载 TiDB Ansible
以 tidb 用户登录中控机并进入 /home/tidb 目录。使用以下命令从 TiDB Ansible 项目上下载 TiDB Ansible 4.0 相应 TAG 版本，默认的文件夹名称为 tidb-ansible。
Copy
git clone -b $tag https://github.com/pingcap/tidb-ansible.git注意：
$tag替换为选定的 TAG 版本的值，例如v4.0.0-beta.2。部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改
inventory.ini文件中的版本来混用可能会产生一些错误。请务必按文档操作，将
tidb-ansible下载到/home/tidb目录下，权限为tidb用户，不要下载到/root下，否则会遇到权限问题。
第 4 步：在中控机器上安装 TiDB Ansible 及其依赖
以 tidb 用户登录中控机，请务必按以下方式通过 pip 安装 TiDB Ansible 及其相关依赖的指定版本，否则会有兼容问题。目前，TiDB Ansible release-4.0 版本兼容 Ansible 2.5 ~ 2.7.11 (2.5 ≤ Ansible ≤ 2.7.11)。
-
在中控机器上安装 TiDB Ansible 及其依赖。
cd /home/tidb/tidb-ansible && \ sudo pip install -r ./requirements.txtAnsible 及相关依赖的版本信息记录在
tidb-ansible/requirements.txt文件中。 -
查看 Ansible 的版本。
ansible --versionansible 2.7.11
第 5 步：在中控机上配置部署机器 SSH 互信及 sudo 规则
以 tidb 用户登录中控机，然后执行以下步骤：
-
将你的部署目标机器 IP 添加到
hosts.ini文件的[servers]区块下。cd /home/tidb/tidb-ansible && \ vi hosts.ini[servers] 172.16.10.1 172.16.10.2 172.16.10.3 172.16.10.4 172.16.10.5 172.16.10.6 [all:vars] username = tidb ntp_server = pool.ntp.org -
执行以下命令，按提示输入部署目标机器的
root用户密码。ansible-playbook -i hosts.ini create_users.yml -u root -k该步骤将在部署目标机器上创建
tidb用户，并配置 sudo 规则，配置中控机与部署目标机器之间的 SSH 互信。
如果要手工配置 SSH 互信及 sudo 免密码，可参考如何手工配置 ssh 互信及 sudo 免密码。
第 6 步：在部署目标机器上安装 NTP 服务
注意：
如果你的部署目标机器时间、时区设置一致，已开启 NTP 服务且在正常同步时间，此步骤可忽略。可参考如何检测 NTP 服务是否正常。
以 tidb 用户登录中控机，执行以下命令：
Copy
cd /home/tidb/tidb-ansible && \
ansible-playbook -i hosts.ini deploy_ntp.yml -u tidb -b该步骤将在部署目标机器上使用系统自带软件源联网安装并启动 NTP 服务，服务使用安装包默认的 NTP server 列表，见配置文件 /etc/ntp.conf 中 server 参数。如果使用默认的 NTP server，你的机器需要连接外网。
为了让 NTP 尽快开始同步，启动 NTP 服务前，系统会执行 ntpdate 命令，与用户在 hosts.ini 文件中指定的 ntp_server 同步日期与时间。默认的服务器为 pool.ntp.org，也可替换为你的 NTP server。
第 7 步：在部署目标机器上配置 CPUfreq 调节器模式
为了让 CPU 发挥最大性能，请将 CPUfreq 调节器模式设置为 performance 模式。如需了解 CPUfreq 的更多信息，可查看使用 CPUFREQ 调控器文档。
查看系统支持的调节器模式
执行以下 cpupower 命令，可查看系统支持的调节器模式：
Copy
cpupower frequency-info --governors
analyzing CPU 0:
available cpufreq governors: performance powersave注意：
本例中系统支持设置
performance和powersave模式。如果返回Not Available，表示当前系统不支持配置 CPUfreq，跳过该步骤即可。
Copy
cpupower frequency-info --governors
analyzing CPU 0:
available cpufreq governors: Not Available查看系统当前的 CPUfreq 调节器模式
执行以下 cpupower 命令，可查看系统当前的 CPUfreq 调节器模式：
Copy
cpupower frequency-info --policy
analyzing CPU 0:
current policy: frequency should be within 1.20 GHz and 3.20 GHz.
The governor "powersave" may decide which speed to use
within this range.如上述代码所示，本例中的当前配置是 powersave 模式。
修改调节器模式
你可以通过以下两种方法来修改调节器模式。本例中，当前调节器模式为 powersave，以下命令会将模式变更为 performance。
-
使用
cpupower frequency-set --governor命令来修改。cpupower frequency-set --governor performance -
使用以下命令在部署目标机器上批量设置。
ansible -i hosts.ini all -m shell -a "cpupower frequency-set --governor performance" -u tidb -b
第 8 步：在部署目标机器上添加数据盘 ext4 文件系统挂载参数
使用 root 用户登录目标机器，将部署目标机器数据盘格式化成 ext4 文件系统，挂载时添加 nodelalloc 和 noatime 挂载参数。nodelalloc 是必选参数，否则 Ansible 安装时检测无法通过；noatime 是可选建议参数。
注意：
如果你的数据盘已经格式化成 ext4 并挂载了磁盘，可先执行
umount /dev/nvme0n1p1命令卸载，从编辑/etc/fstab文件步骤开始执行，添加挂载参数重新挂载即可。
以 /dev/nvme0n1 数据盘为例，具体操作步骤如下：
-
查看数据盘。
fdisk -lDisk /dev/nvme0n1: 1000 GB -
创建分区表。
parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1注意：
使用
lsblk命令查看分区的设备号：对于 nvme 磁盘，生成的分区设备号一般为nvme0n1p1；对于普通磁盘（例如/dev/sdb），生成的的分区设备号一般为sdb1。 -
格式化文件系统。
mkfs.ext4 /dev/nvme0n1p1 -
查看数据盘分区 UUID。
本例中
nvme0n1p1的 UUID 为c51eb23b-195c-4061-92a9-3fad812cc12f。lsblk -fNAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ext4 237b634b-a565-477b-8371-6dff0c41f5ab /boot ├─sda2 swap f414c5c0-f823-4bb1-8fdf-e531173a72ed └─sda3 ext4 547909c1-398d-4696-94c6-03e43e317b60 / sr0 nvme0n1 └─nvme0n1p1 ext4 c51eb23b-195c-4061-92a9-3fad812cc12f -
编辑
/etc/fstab文件，添加nodelalloc挂载参数。vi /etc/fstabUUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2 -
挂载数据盘。
mkdir /data1 && \ mount -a -
执行以下命令，如果文件系统为 ext4，并且挂载参数中包含
nodelalloc，则表示已生效。mount -t ext4/dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered)
第 9 步：编辑 inventory.ini 文件，分配机器资源
以 tidb 用户登录中控机，编辑 /home/tidb/tidb-ansible/inventory.ini 文件为 TiDB 集群分配机器资源。一个标准的 TiDB 集群需要 6 台机器：2 个 TiDB 实例，3 个 PD 实例，3 个 TiKV 实例。
-
至少需部署 3 个 TiKV 实例。
-
不要将 TiKV 实例与 TiDB 或 PD 实例混合部署在同一台机器上。
-
将第一台 TiDB 机器同时用作监控机。
注意：
请使用内网 IP 来部署集群，如果部署目标机器 SSH 端口非默认的 22 端口，需添加
ansible_port变量，如TiDB1 ansible_host=172.16.10.1 ansible_port=5555。如果是 ARM 架构的机器，需要将
cpu_architecture改为arm64。
你可以根据实际场景从以下两种集群拓扑中选择一种：
-
单机单 TiKV 实例集群拓扑
默认情况下，建议在每个 TiKV 节点上仅部署一个 TiKV 实例，以提高性能。但是，如果你的 TiKV 部署机器的 CPU 和内存配置是部署建议的两倍或以上，并且一个节点拥有两块 SSD 硬盘或者单块 SSD 硬盘的容量大于 2 TB，则可以考虑部署两实例，但不建议部署两个以上实例。
-
单机多 TiKV 实例集群拓扑
单机单 TiKV 实例集群拓扑
| Name | Host IP | Services |
|---|---|---|
| node1 | 172.16.10.1 | PD1, TiDB1 |
| node2 | 172.16.10.2 | PD2, TiDB2 |
| node3 | 172.16.10.3 | PD3 |
| node4 | 172.16.10.4 | TiKV1 |
| node5 | 172.16.10.5 | TiKV2 |
| node6 | 172.16.10.6 | TiKV3 |
[tidb_servers]
172.16.10.1
172.16.10.2
[pd_servers]
172.16.10.1
172.16.10.2
172.16.10.3
[tikv_servers]
172.16.10.4
172.16.10.5
172.16.10.6
[monitoring_servers]
172.16.10.1
[grafana_servers]
172.16.10.1
[monitored_servers]
172.16.10.1
172.16.10.2
172.16.10.3
172.16.10.4
172.16.10.5
172.16.10.6单机多 TiKV 实例集群拓扑
以两实例为例：
| Name | Host IP | Services |
|---|---|---|
| node1 | 172.16.10.1 | PD1, TiDB1 |
| node2 | 172.16.10.2 | PD2, TiDB2 |
| node3 | 172.16.10.3 | PD3 |
| node4 | 172.16.10.4 | TiKV1-1, TiKV1-2 |
| node5 | 172.16.10.5 | TiKV2-1, TiKV2-2 |
| node6 | 172.16.10.6 | TiKV3-1, TiKV3-2 |
[tidb_servers]
172.16.10.1
172.16.10.2
[pd_servers]
172.16.10.1
172.16.10.2
172.16.10.3
# 注意：要使用 TiKV 的 labels，必须同时配置 PD 的 location_labels 参数，否则 labels 设置不生效。
# 多实例场景需要额外配置 status 端口，示例如下：
[tikv_servers]
TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv1"
TiKV1-2 ansible_host=172.16.10.4 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv1"
TiKV2-1 ansible_host=172.16.10.5 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv2"
TiKV2-2 ansible_host=172.16.10.5 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv2"
TiKV3-1 ansible_host=172.16.10.6 deploy_dir=/data1/deploy tikv_port=20171 tikv_status_port=20181 labels="host=tikv3"
TiKV3-2 ansible_host=172.16.10.6 deploy_dir=/data2/deploy tikv_port=20172 tikv_status_port=20182 labels="host=tikv3"
[monitoring_servers]
172.16.10.1
[grafana_servers]
172.16.10.1
[monitored_servers]
172.16.10.1
172.16.10.2
172.16.10.3
172.16.10.4
172.16.10.5
172.16.10.6
# 注意：为使 TiKV 的 labels 设置生效，部署集群时必须设置 PD 的 location_labels 参数。
[pd_servers:vars]
location_labels = ["host"]-
服务配置文件参数调整
-
多实例情况下，需要修改
tidb-ansible/conf/tikv.yml中block-cache-size下面的capacity参数：storage: block-cache: capacity: "1GB"注意：
TiKV 实例数量指每个服务器上 TiKV 的进程数量。
推荐设置：
capacity= MEM_TOTAL * 0.5 / TiKV 实例数量 -
多实例情况下，需要修改
tidb-ansible/conf/tikv.yml中high-concurrency、normal-concurrency和low-concurrency三个参数：readpool: coprocessor: # Notice: if CPU_NUM > 8, default thread pool size for coprocessors # will be set to CPU_NUM * 0.8. # high-concurrency: 8 # normal-concurrency: 8 # low-concurrency: 8注意：
推荐设置：TiKV 实例数量 * 参数值 = CPU 核心数量 * 0.8
-
如果多个 TiKV 实例部署在同一块物理磁盘上，需要修改
conf/tikv.yml中的capacity参数：raftstore: capacity: 0注意：
推荐配置：
capacity= 磁盘总容量 / TiKV 实例数量例如：
capacity: "100GB"
-
第 10 步：调整 inventory.ini 文件中的变量
本小节介绍如何编辑部署目录的变量和 inventory.ini 文件中的其它变量。
调整部署目录
部署目录通过 deploy_dir 变量控制，默认全局变量已设置为 /home/tidb/deploy，对所有服务生效。如数据盘挂载目录为 /data1，可设置为 /data1/deploy，样例如下：
## Global variables
[all:vars]
deploy_dir = /data1/deploy如为某一服务单独设置部署目录，可在配置服务主机列表时配置主机变量，以 TiKV 节点为例，其他服务类推，请务必添加第一列别名，以免服务混布时混淆。
TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy调整其它变量（可选）
注意：
以下控制变量开启请使用首字母大写
True，关闭请使用首字母大写False。
| 变量 | 含义 |
|---|---|
cluster_name |
集群名称，可调整 |
cpu_architecture |
CPU 体系架构，默认为 amd64，可选 arm64 |
tidb_version |
TiDB 版本，TiDB Ansible 各分支默认已配置 |
process_supervision |
进程监管方式，默认为 systemd，可选 supervise |
timezone |
新安装 TiDB 集群第一次启动 bootstrap（初始化）时，将 TiDB 全局默认时区设置为该值。TiDB 使用的时区后续可通过 time_zone 全局变量和 session 变量来修改，参考时区支持。默认为 Asia/Shanghai，可选值参考 timzone 列表。 |
enable_firewalld |
开启防火墙，默认不开启，如需开启，请将部署建议-网络要求 中的端口加入白名单 |
enable_ntpd |
检测部署目标机器 NTP 服务，默认为 True，请勿关闭 |
set_hostname |
根据 IP 修改部署目标机器主机名，默认为 False |
enable_binlog |
是否部署 Pump 并开启 binlog，默认为 False，依赖 Kafka 集群，参见 zookeeper_addrs 变量 |
zookeeper_addrs |
binlog Kafka 集群的 zookeeper 地址 |
deploy_without_tidb |
KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 inventory.ini 文件中 tidb_servers 主机组 IP 设置为空。 |
alertmanager_target |
可选：如果你已单独部署 alertmanager，可配置该变量，格式：alertmanager_host:alertmanager_port |
grafana_admin_user |
Grafana 管理员帐号用户名，默认为 admin |
grafana_admin_password |
Grafana 管理员帐号密码，默认为 admin，用于 Ansible 导入 Dashboard 和创建 API Key，如后期通过 grafana web 修改了密码，请更新此变量 |
collect_log_recent_hours |
采集日志时，采集最近几个小时的日志，默认为 2 小时 |
enable_bandwidth_limit |
在中控机上从部署目标机器拉取诊断数据时，是否限速，默认为 True，与 collect_bandwidth_limit 变量结合使用 |
collect_bandwidth_limit |
在中控机上从部署目标机器拉取诊断数据时限速多少，单位: Kbit/s，默认 10000，即 10Mb/s，如果是单机多 TiKV 实例部署方式，需除以单机实例个数 |
prometheus_storage_retention |
Prometheus 监控数据的保留时间（默认为 30 天）；2.1.7、3.0 以及之后的 tidb-ansible 版本中，group_vars/monitoring_servers.yml 文件里新增的配置 |
第 11 步：部署 TiDB 集群
ansible-playbook 执行 Playbook 时，默认并发为 5。部署目标机器较多时，可添加 -f 参数指定并发数，例如 ansible-playbook deploy.yml -f 10。以下示例使用 tidb 用户作为服务运行用户：
-
在
tidb-ansible/inventory.ini文件中，确认ansible_user = tidb。## Connection # ssh via normal user ansible_user = tidb注意：
不要将
ansible_user设置为root用户，因为tidb-ansible限制了服务以普通用户运行。执行以下命令，如果所有 server 均返回
tidb，表示 SSH 互信配置成功：ansible -i inventory.ini all -m shell -a 'whoami'执行以下命令，如果所有 server 均返回
root，表示tidb用户 sudo 免密码配置成功。ansible -i inventory.ini all -m shell -a 'whoami' -b -
执行
local_prepare.ymlplaybook，联网下载 TiDB binary 至中控机。ansible-playbook local_prepare.yml -
初始化系统环境，修改内核参数。
ansible-playbook bootstrap.yml -
部署 TiDB 集群软件。
ansible-playbook deploy.yml注意：
Grafana Dashboard 上的 Report 按钮可用来生成 PDF 文件，此功能依赖
fontconfig包和英文字体。如需使用该功能，登录 grafana_servers 机器，用以下命令安装：sudo yum install fontconfig open-sans-fonts -
启动 TiDB 集群。
ansible-playbook start.yml
测试集群
TiDB 兼容 MySQL，因此可使用 MySQL 客户端直接连接 TiDB。推荐配置负载均衡以提供统一的 SQL 接口。
-
使用 MySQL 客户端连接 TiDB 集群。TiDB 服务的默认端口为
4000。mysql -u root -h 172.16.10.1 -P 4000 -
通过浏览器访问监控平台。
-
地址：http://172.16.10.1:3000
-
默认帐号与密码：
admin；admin
-
注意：
TiDB 默认会定期收集使用情况信息，并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为，请参见遥测。
常见部署问题
本小节介绍使用 TiDB Ansible 部署 TiDB 集群过程中的常见问题与解决方案。
如何自定义端口
修改 inventory.ini 文件，在相应服务 IP 后添加以下主机变量即可：
| 组件 | 端口变量 | 默认端口 | 说明 |
|---|---|---|---|
| TiDB | tidb_port | 4000 | 应用及 DBA 工具访问通信端口 |
| TiDB | tidb_status_port | 10080 | TiDB 状态信息上报通信端口 |
| TiKV | tikv_port | 20160 | TiKV 通信端口 |
| TiKV | tikv_status_port | 20180 | 上报 TiKV 状态的通信端口 |
| PD | pd_client_port | 2379 | 提供 TiDB 和 PD 通信端口 |
| PD | pd_peer_port | 2380 | PD 集群节点间通信端口 |
| Pump | pump_port | 8250 | Pump 通信端口 |
| Prometheus | prometheus_port | 9090 | Prometheus 服务通信端口 |
| Pushgateway | pushgateway_port | 9091 | TiDB， TiKV， PD 监控聚合和上报端口 |
| Node_exporter | node_exporter_port | 9100 | TiDB 集群每个节点的系统信息上报通信端口 |
| Blackbox_exporter | blackbox_exporter_port | 9115 | Blackbox_exporter 通信端口，用于 TiDB 集群端口监控 |
| Grafana | grafana_port | 3000 | Web 监控服务对外服务和客户端(浏览器)访问端口 |
| Kafka_exporter | kafka_exporter_port | 9308 | Kafka_exporter 通信端口，用于监控 binlog Kafka 集群 |
如何自定义部署目录
修改 inventory.ini 文件，在相应服务 IP 后添加以下主机变量即可：
| 组件 | 目录变量 | 默认目录 | 说明 |
|---|---|---|---|
| 全局 | deploy_dir | /home/tidb/deploy | 部署目录 |
| TiDB | tidb_log_dir | { { deploy_dir }}/log | 日志目录 |
| TiKV | tikv_log_dir | { { deploy_dir }}/log | 日志目录 |
| TiKV | tikv_data_dir | { { deploy_dir }}/data | 数据目录 |
| TiKV | wal_dir | "” | rocksdb write-ahead 日志目录，为空时与 TiKV 数据目录一致 |
| TiKV | raftdb_path | "” | raftdb 目录，为空时为 tikv_data_dir/raft |
| PD | pd_log_dir | { { deploy_dir }}/log | 日志目录 |
| PD | pd_data_dir | { { deploy_dir }}/data.pd | 数据目录 |
| pump | pump_log_dir | { { deploy_dir }}/log | 日志目录 |
| pump | pump_data_dir | { { deploy_dir }}/data.pump | 数据目录 |
| prometheus | prometheus_log_dir | { { deploy_dir }}/log | 日志目录 |
| prometheus | prometheus_data_dir | { { deploy_dir }}/data.metrics | 数据目录 |
| pushgateway | pushgateway_log_dir | { { deploy_dir }}/log | 日志目录 |
| node_exporter | node_exporter_log_dir | { { deploy_dir }}/log | 日志目录 |
| grafana | grafana_log_dir | { { deploy_dir }}/log | 日志目录 |
| grafana | grafana_data_dir | { { deploy_dir }}/data.grafana | 数据目录 |
如何检测 NTP 服务是否正常
-
执行以下命令，如果输出
running表示 NTP 服务正在运行：sudo systemctl status ntpd.servicentpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled) Active: active (running) since 一 2017-12-18 13:13:19 CST; 3s ago -
执行
ntpstat命令，如果输出synchronised to NTP server（正在与 NTP server 同步），表示在正常同步：ntpstatsynchronised to NTP server (85.199.214.101) at stratum 2 time correct to within 91 ms polling server every 1024 s
注意：
Ubuntu 系统需安装
ntpstat软件包。
-
以下情况表示 NTP 服务未正常同步：
ntpstatunsynchronised -
以下情况表示 NTP 服务未正常运行：
ntpstatUnable to talk to NTP daemon. Is it running? -
如果要使 NTP 服务尽快开始同步，执行以下命令。可以将
pool.ntp.org替换为你的 NTP server：sudo systemctl stop ntpd.service && \ sudo ntpdate pool.ntp.org && \ sudo systemctl start ntpd.service -
如果要在 CentOS 7 系统上手动安装 NTP 服务，可执行以下命令：
sudo yum install ntp ntpdate && \ sudo systemctl start ntpd.service && \ sudo systemctl enable ntpd.service
如何调整进程监管方式从 supervise 到 systemd
Copy
process supervision, [systemd, supervise]
process_supervision = systemdTiDB Anisble 在 TiDB v1.0.4 版本之前进程监管方式默认为 supervise。之前安装的集群可保持不变，如需更新为 systemd，需关闭集群，按以下方式变更：
Copy
ansible-playbook stop.yml && \
ansible-playbook deploy.yml -D && \
ansible-playbook start.yml如何手工配置 SSH 互信及 sudo 免密码
-
以
root用户依次登录到部署目标机器创建tidb用户并设置登录密码。useradd tidb && \ passwd tidb -
执行以下命令，将
tidb ALL=(ALL) NOPASSWD: ALL添加到文件末尾，即配置好 sudo 免密码。visudotidb ALL=(ALL) NOPASSWD: ALL -
以
tidb用户登录到中控机，执行以下命令。将172.16.10.61替换成你的部署目标机器 IP，按提示输入部署目标机器tidb用户密码，执行成功后即创建好 SSH 互信，其他机器同理。ssh-copy-id -i ~/.ssh/id_rsa.pub 172.16.10.61 -
以
tidb用户登录中控机，通过ssh的方式登录目标机器 IP。如果不需要输入密码并登录成功，即表示 SSH 互信配置成功。ssh 172.16.10.61[[email protected] ~]$ -
以
tidb用户登录到部署目标机器后，执行以下命令，不需要输入密码并切换到root用户，表示tidb用户 sudo 免密码配置成功。sudo -su root[[email protected] tidb]#
You need to install jmespath prior to running json_query filter 报错
-
请参照在中控机器上安装 TiDB Ansible 及其依赖 在中控机上通过
pip安装 TiDB Ansible 及相关依赖的指定版本，默认会安装jmespath。 -
执行以下命令，验证
jmespath是否安装成功：pip show jmespathName: jmespath Version: 0.9.0 -
在中控机上 Python 交互窗口里执行
import jmespath。-
如果没有报错，表示依赖安装成功。
-
如果有
ImportError: No module named jmespath报错，表示未成功安装 Pythonjmespath模块。
pythonPython 2.7.5 (default, Nov 6 2016, 00:28:07) [GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2 Type "help", "copyright", "credits" or "license" for more information.import jmespath -
启动 Pump/Drainer 报 zk: node does not exist 错误
请检查 inventory.ini 里的 zookeeper_addrs 参数配置与 Kafka 集群内的配置是否相同、是否填写了命名空间。关于命名空间的配置说明如下：
# ZooKeeper connection string (see ZooKeeper docs for details).
# ZooKeeper address of Kafka cluster, example:
# zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181"
# You can also append an optional chroot string to the URLs to specify the root directory for all Kafka znodes. Example:
# zookeeper_addrs = "192.168.0.11:2181,192.168.0.12:2181,192.168.0.13:2181/kafka/123"4、离线 TiDB Ansible 部署方案
准备机器
-
下载机一台
-
该机器需开放外网访问，用于下载 TiDB Ansible、TiDB 及相关软件安装包。
-
推荐安装 CentOS 7.3 及以上版本 Linux 操作系统。
-
-
部署目标机器若干及部署中控机一台
-
系统要求及配置参考准备机器。
-
可以无法访问外网。
-
在中控机上安装系统依赖包
-
在下载机上下载系统依赖离线安装包，然后上传至中控机。该离线包仅支持 CentOS 7 系统，包含
pip及sshpass。 -
在中控机上安装系统依赖包：
tar -xzvf ansible-system-rpms.el7.tar.gz && cd ansible-system-rpms.el7 && chmod u+x install_ansible_system_rpms.sh && ./install_ansible_system_rpms.sh -
安装完成后，可通过
pip -V验证 pip 是否安装成功：pip -Vpip 8.1.2 from /usr/lib/python2.7/site-packages (python 2.7)
注意：
如果你的系统已安装 pip，请确认版本 >= 8.1.2，否则离线安装 TiDB Ansible 及其依赖时，会有兼容问题。
在中控机上创建 tidb 用户，并生成 ssh key
参考在中控机上创建 tidb 用户，并生成 ssh key 即可。
在中控机器上离线安装 TiDB Ansible 及其依赖
以下是 CentOS 7 系统 Ansible 离线安装方式：
建议使用 Ansible 2.4 至 2.7.11 版本，Ansible 及相关依赖版本记录在 tidb-ansible/requirements.txt 文件中。下面步骤以安装 Ansible 2.5 为例。
-
在下载机上下载 Ansible 2.5 离线安装包，然后上传至中控机。
-
离线安装 TiDB Ansible 及相关依赖：
tar -xzvf ansible-2.5.0-pip.tar.gz && cd ansible-2.5.0-pip/ && chmod u+x install_ansible.sh && ./install_ansible.sh -
安装完成后，可通过
ansible --version查看版本：ansible --versionansible 2.5.0
在下载机上下载 TiDB Ansible 及 TiDB 安装包
-
在下载机上安装 TiDB Ansible：
请按以下方式在 CentOS 7 系统的下载机上在线安装 TiDB Ansible。安装完成后，可通过
ansible --version查看版本，请务必确认是 Ansible 2.5.0 版本，否则会有兼容问题。yum install epel-release && yum install ansible curl && ansible --versionansible 2.5.0 -
下载 tidb-ansible：
使用以下命令从 Github TiDB Ansible 项目上下载 TiDB Ansible 相应版本，默认的文件夹名称为
tidb-ansible。git clone https://github.com/pingcap/tidb-ansible.git注意：
部署和升级 TiDB 集群需使用对应的 tidb-ansible 版本，通过改
inventory.ini文件中的版本来混用可能会产生一些错误。 -
执行
local_prepare.ymlplaybook，联网下载 TiDB binary 到下载机：cd tidb-ansible && ansible-playbook local_prepare.yml -
将执行完以上命令之后的
tidb-ansible文件夹拷贝到中控机/home/tidb目录下，文件属主权限需是tidb用户。
在中控机上配置部署机器 SSH 互信及 sudo 规则
参考在中控机上配置部署机器 SSH 互信及 sudo 规则即可。
在部署目标机器上安装 NTP 服务
如果你的部署目标机器时间、时区设置一致，已开启 NTP 服务且在正常同步时间，此步骤可忽略，可参考如何检测 NTP 服务是否正常。
参考在部署目标机器上安装 NTP 服务即可。
在部署目标机器上配置 CPUfreq 调节器模式
参考在部署目标机器上配置 CPUfreq 调节器模式即可。
在部署目标机器上添加数据盘 ext4 文件系统挂载参数
参考在部署目标机器上添加数据盘 ext4 文件系统挂载参数即可。
分配机器资源，编辑 inventory.ini 文件
参考分配机器资源，编辑 inventory.ini 文件即可。
部署任务
-
ansible-playbook local_prepare.yml该 playbook 不需要再执行。 -
参考部署任务即可。
测试集群
参考测试集群即可。
注意：
TiDB 默认会定期收集使用情况信息，并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为，请参见遥测。
5、验证集群运行状态
验证集群运行状态
本文档介绍如何通过 TiDB Dashboard 和 Grafana 检查集群状态，以及登录数据库执行简单 DML、DDL 操作和查询 SQL 语句。
通过 TiDB Dashboard 和 Grafana 检查集群状态
本节介绍如何通过 TiDB Dashboard 和 Grafana 检查集群状态。
查看 TiDB Dashboard 检查 TiDB 集群状态
-
通过
{pd-ip}:{pd-port}/dashboard登录 TiDB Dashboard，登录用户和口令为 TiDB 数据库root用户和口令。如果你修改过数据库的root密码，则以修改后的密码为准，默认密码为空。 -
主页面显示 TiDB 集群中节点信息
查看 Grafana 监控 Overview 页面检查 TiDB 集群状态
-
通过
{Grafana-ip}:3000登录 Grafana 监控，默认用户名及密码为admin/admin。 -
点击 Overview 监控页面检查 TiDB 端口和负载监控信息。
转存失败重新上传取消转存失败重新上传取消转存失败重新上传取消正在上传…重新上传取消正在上传…重新上传取消正在上传…重新上传取消正在上传…重新上传取消
登录数据库执行简单 DML/DDL 操作和查询 SQL 语句
注意：
登录数据库前，你需要安装 MySQL 客户端。
执行如下命令登录数据库：
Copy
mysql -u root -h 10.0.1.4 -P 4000输出下列信息表示登录成功：
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.25-TiDB-v4.0.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.数据库操作
-
检查 TiDB 版本
select tidb_version()\G预期结果输出：
*************************** 1. row *************************** tidb_version(): Release Version: v4.0.0 Edition: Community Git Commit Hash: 689a6b6439ae7835947fcaccf329a3fc303986cb Git Branch: HEAD UTC Build Time: 2020-05-28 11:09:45 GoVersion: go1.13.4 Race Enabled: false TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306 Check Table Before Drop: false 1 row in set (0.00 sec) -
创建 PingCAP database
create database pingcap;Query OK, 0 rows affected (0.10 sec)use pingcap;预期输出
Database changed -
创建
tab_tidb表CREATE TABLE `tab_tidb` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL DEFAULT '', `age` int(11) NOT NULL DEFAULT 0, `version` varchar(20) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `idx_age` (`age`));预期输出
Query OK, 0 rows affected (0.11 sec) -
插入数据
insert into `tab_tidb` values (1,'TiDB',5,'TiDB-v4.0.0');预期输出
Query OK, 1 row affected (0.03 sec) -
查看
tab_tidb结果select * from tab_tidb;预期输出
+----+------+-----+-------------+ | id | name | age | version | +----+------+-----+-------------+ | 1 | TiDB | 5 | TiDB-v4.0.0 | +----+------+-----+-------------+ 1 row in set (0.00 sec) -
查看 TiKV store 状态、
store_id、存储情况以及启动时间select STORE_ID,ADDRESS,STORE_STATE,STORE_STATE_NAME,CAPACITY,AVAILABLE,UPTIME from INFORMATION_SCHEMA.TIKV_STORE_STATUS;预期输出
+----------+--------------------+-------------+------------------+----------+-----------+--------------------+ | STORE_ID | ADDRESS | STORE_STATE | STORE_STATE_NAME | CAPACITY | AVAILABLE | UPTIME | +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ | 1 | 10.0.1.1:20160 | 0 | Up | 49.98GiB | 46.3GiB | 5h21m52.474864026s | | 4 | 10.0.1.2:20160 | 0 | Up | 49.98GiB | 46.32GiB | 5h21m52.522669177s | | 5 | 10.0.1.3:20160 | 0 | Up | 49.98GiB | 45.44GiB | 5h21m52.713660541s | +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ 3 rows in set (0.00 sec) -
退出
exit预期输出
Bye