diff --git a/FAQ.md b/FAQ.md index 6dd0cee34855..60b6678a4186 100755 --- a/FAQ.md +++ b/FAQ.md @@ -713,7 +713,7 @@ sqoop export \ ``` - 也可以选择增大 tidb 的单个事物语句数量限制，不过这个会导致内存上涨。 -### 4.2 增量数据同步 +### 4.2 在线数据同步 #### 4.2.1 Syncer 架构 @@ -745,11 +745,7 @@ sqoop export \ 频繁执行 DDL 对同步速度会有影响。对于 Sycner 来说，DDL 是串行执行的，当同步遇到了 DDL，就会以串行的方式执行，所以这种场景就会导致同步速度下降。 -#### 4.2.2 Wormhole 工具 - -Wormhole 是一项数据同步服务，让用户能够通过 Web 控制台, 轻松操作数据的全量 + 增量同步，支持多种同、异构数据源之间的数据迁移，如 MySQL -> TiDB，MongoDB -> TiDB。具体可联系官方进行试用 [info@pingcap.com](mailto:info@pingcap.com)。 - -#### 4.2.3 使用 Syncer gtid 的方式同步时，同步过程中会不断更新 syncer.meta 文件，如果 Syncer 所在的机器坏了，导致 syncer.meta 文件所在的目录丢失，该如何处理？ +#### 4.2.1.6 使用 Syncer gtid 的方式同步时，同步过程中会不断更新 syncer.meta 文件，如果 Syncer 所在的机器坏了，导致 syncer.meta 文件所在的目录丢失，该如何处理？ 当前 Syncer 版本的没有进行高可用设计，Syncer 目前的配置信息 syncer.meta 直接存储在硬盘上，其存储方式类似于其他 MySQL 生态工具，比如 mydumper。 因此，要解决这个问题当前可以有两个方法： @@ -761,7 +757,7 @@ Wormhole 是一项数据同步服务，让用户能够通过 Web 控制台, 轻 #### 4.3.1 如何快速迁移业务流量？ -我们建议通过 Syncer 或 Wormhole 搭建成多源 MySQL、MongoDB -> TiDB 实时同步环境，读写流量可以按照需求分阶段通过修改网络配置进行流量迁移，建议 DB 上层部署一个稳定的网络 LB（HAproxy、LVS、F5、DNS 等），这样直接修改网络配置就能实现无缝流量迁移。 +我们建议通过 Syncer 工具搭建成多源 MySQL -> TiDB 实时同步环境，读写流量可以按照需求分阶段通过修改网络配置进行流量迁移，建议 DB 上层部署一个稳定的网络 LB（HAproxy、LVS、F5、DNS 等），这样直接修改网络配置就能实现无缝流量迁移。 #### 4.3.2 TiDB 总读写流量有限制吗？ @@ -974,4 +970,4 @@ update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_tim #### 9.2.4 ERROR 9001 (HY000): PD server timeout start timestamp may fall behind safe point -这个报错一般是 TiDB 访问 PD 出了问题，TiDB 后台有个 worker 会不断地从 PD 查询 safepoint，如果超过 100s 查不成功就会报这个错。一般是因为 PD 有故障或者 TiDB 和 PD 之间的网络有问题。TiDB 常见错误码请参考[错误码与故障诊断](sql/error.md)。 +这个报错一般是 TiDB 访问 PD 出了问题，TiDB 后台有个 worker 会不断地从 PD 查询 safepoint，如果超过 100s 查不成功就会报这个错。一般是因为 PD 磁盘操作过忙、反应过慢，或者 TiDB 和 PD 之间的网络有问题。TiDB 常见错误码请参考[错误码与故障诊断](sql/error.md)。 diff --git a/QUICKSTART.md b/QUICKSTART.md index be47bb57ab40..0ee848fb9b58 100644 --- a/QUICKSTART.md +++ b/QUICKSTART.md @@ -5,291 +5,23 @@ category: deployment # TiDB 快速入门指南 -## 关于 TiDB +作为开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，TiDB 可以部署在本地和云平台上，支持公有云、私有云和混合云。 -TiDB 是 PingCAP 公司受 Google [Spanner](http://research.google.com/archive/spanner.html) / [F1](http://research.google.com/pubs/pub41344.html) 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。 +## TiDB 部署方式 -## 关于本指南 +你可以根据实际场景或需求，选择相应的方式来部署 TiDB 集群： -本指南为您介绍如何使用 TiDB-Ansible 快速部署一个 TiDB 集群，并了解 TiDB 的基本操作和管理。 +- [使用 Ansible 部署](op-guide/ansible-deployment.md)：如果用于生产环境，须使用 Ansible 部署 TiDB 集群。 +- [使用 Ansible 离线部署](op-guide/offline-ansible-deployment.md)：如果部署环境无法访问网络，可使用 Ansible 进行离线部署。 +- [使用 Docker Compose 部署](op-guide/docker-compose.md)：如果你只是想测试 TiDB、体验 TiDB 的特性，或者用于开发环境，可以使用 Docker Compose 在本地快速部署 TiDB 集群。该部署方式不适用于生产环境。 +- [使用 Docker 部署](op-guide/docker-deployment.md)：你可以使用 Docker 部署 TiDB 集群，但该部署方式不适用于生产环境。 -## TiDB 集群部署 +## 项目源码 -本节具体介绍如何部署一个 TiDB 集群。一个 TiDB 集群由不同的模块组成，包括：TiDB 服务器、TiKV 服务器、Placement Driver (PD) 服务器。 +TiDB 集群所有组件的源码均可从 GitHub 上直接访问： -架构图如下所示： - -![TiDB Architecture](media/tidb-architecture.png) - -参考 [TiDB Ansible 部署方案](./op-guide/ansible-deployment.md)。 - -## TiDB 基本操作 - -本节具体介绍 TiDB 中基本的增删改查操作。 - -### 创建、查看和删除数据库 - -使用 `CREATE DATABASE` 语句创建数据库。语法如下： - -```sql -CREATE DATABASE db_name [options]; -``` - -例如，要创建一个名为 `samp_db` 的数据库，可使用以下语句： - -```sql -CREATE DATABASE IF NOT EXISTS samp_db; -``` - -使用 `SHOW DATABASES` 语句查看数据库： - -```sql -SHOW DATABASES; -``` - -使用 `DROP DATABASE` 语句删除数据库，例如： - -```sql -DROP DATABASE samp_db; -``` - -### 创建、查看和删除表 - -使用 `CREATE TABLE` 语句创建表。语法如下： - -```sql -CREATE TABLE table_name column_name data_type constraint; -``` - -例如： - -```sql -CREATE TABLE person ( - number INT(11), - name VARCHAR(255), - birthday DATE - ); -``` - -如果表已存在，添加 `IF NOT EXISTS` 可防止发生错误： - -```sql -CREATE TABLE IF NOT EXISTS person ( - number INT(11), - name VARCHAR(255), - birthday DATE -); -``` - -使用 `SHOW CREATE` 语句查看建表语句。例如： - -```sql -SHOW CREATE table person; -``` - -使用 `SHOW FULL COLUMNS` 语句查看表的列。 例如： - -```sql -SHOW FULL COLUMNS FROM person; -``` - -使用 `DROP TABLE` 语句删除表。例如： - -```sql -DROP TABLE person; -``` - -或者 - -```sql -DROP TABLE IF EXISTS person; -``` - -使用 `SHOW TABLES` 语句查看数据库中的所有表。例如： - -```sql -SHOW TABLES FROM samp_db; -``` - -### 创建、查看和删除索引 - -对于值不唯一的列，可使用 `CREATE INDEX` 或 `ALTER TABLE` 语句。例如： - -```sql -CREATE INDEX person_num ON person (number); -``` - -或者 - -```sql -ALTER TABLE person ADD INDEX person_num (number); -``` - -对于值唯一的列，可以创建唯一索引。例如： - -```sql -CREATE UNIQUE INDEX person_num ON person (number); -``` - -或者 - -```sql -ALTER TABLE person ADD UNIQUE person_num on (number); -``` - -使用 `SHOW INDEX` 语句查看表内所有索引： - -```sql -SHOW INDEX from person; -``` - -使用 `ALTER TABLE` 或 `DROP INDEX` 语句来删除索引。与 `CREATE INDEX` 语句类似，`DROP INDEX` 也可以嵌入 `ALTER TABLE` 语句。例如： - -```sql -DROP INDEX person_num ON person; -ALTER TABLE person DROP INDEX person_num; -``` - -### 增删改查数据 - -使用 `INSERT` 语句向表内插入数据。例如： - -```sql -INSERT INTO person VALUES("1","tom","20170912"); -``` - -使用 `SELECT` 语句检索表内数据。例如： - -```sql -SELECT * FROM person; -+--------+------+------------+ -| number | name | birthday | -+--------+------+------------+ -| 1 | tom | 2017-09-12 | -+--------+------+------------+ -``` -使用 `UPDATE` 语句修改表内数据。例如： - -```sql -UPDATE person SET birthday='20171010' WHERE name='tom'; - -SELECT * FROM person; -+--------+------+------------+ -| number | name | birthday | -+--------+------+------------+ -| 1 | tom | 2017-10-10 | -+--------+------+------------+ -``` - -使用 `DELETE` 语句删除表内数据： - -```sql -DELETE FROM person WHERE number=1; -SELECT * FROM person; -Empty set (0.00 sec) -``` - -### 创建、授权和删除用户 - -使用 `CREATE USER` 语句创建一个用户 `tiuser`，密码为 `123456`： - -```sql -CREATE USER 'tiuser'@'localhost' IDENTIFIED BY '123456'; -``` - -授权用户 `tiuser` 可检索数据库 `samp_db` 内的表： - -```sql -GRANT SELECT ON samp_db.* TO 'tiuser'@'localhost'; -``` - -查询用户 `tiuser` 的权限： - -```sql -SHOW GRANTS for tiuser@localhost; -``` - -删除用户 `tiuser`： - -```sql -DROP USER 'tiuser'@'localhost'; -``` - -## TiDB 集群监控 - -打开浏览器，访问以下监控平台： - -地址：`http://172.16.10.3:3000`， -默认帐户和密码为：`admin`@`admin`。 - -### 重要监控指标详解 - -+ PD - - Storage Capacity : TiDB 集群总可用数据库空间大小 - - Current Storage Size : TiDB 集群目前已用数据库空间大小 - - Store Status -- up store : TiKV 正常节点数量 - - Store Status -- down store : TiKV 异常节点数量 - - 如果大于 0，证明有节点不正常 - - Store Status -- offline store : 手动执行下线操作 TiKV 节点数量 - - Store Status -- Tombstone store : 下线成功的 TiKV 节点数量 - - Current storage usage : TiKV 集群存储空间占用率 - - 超过 80% 应考虑添加 TiKV 节点 - - 99% completed_cmds_duration_seconds : 99% pd-server 请求完成时间 - - 小于 5ms - - average completed_cmds_duration_seconds : pd-server 请求平均完成时间 - - 小于 50ms - - leader balance ratio : leader ratio 最大的节点与最小的节点的差 - - 均衡状况下一般小于 5%，节点重启时会比较大 - - region balance ratio : region ratio 最大的节点与最小的节点的差 - - 均衡状况下一般小于 5%，新增/下线节点时会比较大 - -+ TiDB - - handle_requests_duration_seconds : 请求 PD 获取 TSO 响应时间 - - 小于 100ms - - tidb server QPS : 集群的请求量 - - - connection count : 从业务服务器连接到数据库的连接数 - - 和业务相关。但是如果连接数发生跳变，需要查明原因。比如突然掉为 0，可以检查网络是否中断； - 如果突然上涨，需要检查业务。 - - statement count : 单位时间内不同类型语句执行的数目 - - Query Duration 99th percentile : 99% 的 query 时间 - -+ TiKV - - 99% & 99.99% scheduler command duration : 99% & 99.99% 命令执行的时间 - - 99% 小于 50ms；99.99% 小于 100ms - - 95% & 99% storage async_request duration : 95% & 99% Raft 命令执行时间 - - 95% 小于 50ms；99% 小于 100ms - - server report failure message : 发送失败或者收到了错误的 message - - 如果出现了大量的 unreachadble 的消息，表明系统网络出现了问题。如果有 store not match 这样的错误， - 表明收到了不属于这个集群发过来的消息 - - Vote : Raft vote 的频率 - - 通常这个值只会在发生 split 的时候有变动，如果长时间出现了 vote 偏高的情况，证明系统出现了严重的问题， - 有一些节点无法工作了 - - 95% & 99% coprocessor request duration : 95% & 99% coprocessor 执行时间 - - 和业务相关，但通常不会出现持续高位的值 - - Pending task : 累积的任务数量 - - 除了 pd worker，其他任何偏高都属于异常 - - stall : RocksDB Stall 时间 - - 大于 0，表明 RocksDB 忙不过来，需要注意 IO 和 CPU 了 - - channel full : channel 满了，表明线程太忙无法处理 - - 如果大于 0，表明线程已经没法处理了 - - 95% send_message_duration_seconds : 95% 发送消息的时间 - - 小于 50ms - - leader/region : 每个 TiKV 的 leader/region 数量 +- [TiDB](https://github.com/pingcap/tidb) +- [TiKV](https://github.com/tikv/tikv) +- [PD](https://github.com/pingcap/pd) +- [TiSpark](https://github.com/pingcap/tispark) +- [TiDB Operator](https://github.com/pingcap/tidb-operator) \ No newline at end of file diff --git a/README.md b/README.md index b93e3830b4bf..a877e4669d16 100755 --- a/README.md +++ b/README.md @@ -2,10 +2,13 @@ ## 目录 -+ TiDB 简介与整体架构 - - [TiDB 简介](overview.md#tidb-简介) - - [TiDB 整体架构](overview.md#tidb-整体架构) -- [TiDB 快速入门指南](QUICKSTART.md) ++ 关于 TiDB + - [TiDB 简介](overview.md) + - [TiDB 整体架构](architecture.md) + - [TiDB 核心特性](features.md) ++ TiDB 快速入门 + - [快速入门指南](QUICKSTART.md) + - [SQL 基本操作](try-tidb.md) + TiDB 用户文档 + TiDB 数据库管理 - [TiDB 服务](sql/tidb-server.md) @@ -120,6 +123,9 @@ - [常见问题与解答(FAQ)](FAQ.md) - [最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/) + [版本发布历史](releases/rn.md) + - [2.1 RC3](releases/21rc3.md) + - [2.1 RC2](releases/21rc2.md) + - [2.0.7](releases/207.md) - [2.1 RC1](releases/21rc1.md) - [2.0.6](releases/206.md) - [2.0.5](releases/205.md) @@ -150,6 +156,7 @@ - [Mobike](http://t.cn/RT8FbP6) - [饿了么（一）](http://t.cn/RucuK6m) - [饿了么（二）](http://t.cn/RnsqFT6) + - [爱奇艺](http://t.cn/EvErsc1) - [易果生鲜](http://t.cn/RTYVhzH) - [同程旅游](http://t.cn/RmXeNKR) - [去哪儿](http://t.cn/RTKnsL7) diff --git a/ROADMAP.md b/ROADMAP.md index fecfed19544f..4d0acb3b56ac 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -69,10 +69,10 @@ category: Roadmap - [ ] Index Join 和并行 merge join - [ ] Data Federation（桥接其他数据源，最好能和社区同步，这个接进来可以比较好扩展 Usecase，如果再做一个 InputFormat 适配就可以接 Hive 和 Presto 这些 Hadoop 上的数仓） -## SRE&Tools: +## Tools: -- [x] On-Premise 版本集成部署 (K8s based) -- [ ] On-Premise 版本 Dashboard UI -- [ ] 集群备份和恢复工具（结合物理备份） -- [ ] 数据迁移工具（Wormhole 二期） -- [ ] 安全与系统诊断 \ No newline at end of file +- [x] 集群部署工具 +- [X] 高性能数据导入工具 +- [X] 集群备份和恢复工具 (包括全量+增量备份) +- [ ] 数据在线迁移工具 (Syncer 升级版) +- [ ] 集群诊断和分析工具 diff --git a/architecture.md b/architecture.md new file mode 100644 index 000000000000..8ce1f681d075 --- /dev/null +++ b/architecture.md @@ -0,0 +1,28 @@ +--- +title: TiDB 整体架构 +category: introduction +--- + +# TiDB 整体架构 + +要深入了解 TiDB 的水平扩展和高可用特点，首先需要了解 TiDB 的整体架构。TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有用于解决用户复杂 OLAP 需求的 [TiSpark](https://github.com/pingcap/tispark/) 组件。 + +![TiDB Architecture](media/tidb-architecture.png) + +## 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 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。 + +## TiSpark + +TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。 \ No newline at end of file diff --git a/benchmark/sysbench-v3.md b/benchmark/sysbench-v3.md new file mode 100644 index 000000000000..ead8f109d23b --- /dev/null +++ b/benchmark/sysbench-v3.md @@ -0,0 +1,142 @@ +--- +title: TiDB Sysbench 性能对比测试报告 - v2.1 对比 v2.0 +category: benchmark +--- + +# TiDB Sysbench 性能对比测试报告 - v2.1 对比 v2.0 + +## 测试目的 + +对比 TiDB 2.1 版本和 2.0 版本在 OLTP 场景下的性能。 + +## 测试版本、时间、地点 + +TiDB 版本：v2.1.0-rc.2 vs. v2.0.6 + +时间：2018 年 9 月 + +地点：北京 + +## 测试环境 + +IDC 机器： + +| 类别 | 名称 | +| :-: | :-: | +| OS | Linux (CentOS 7.3.1611) | +| CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz | +| RAM | 128GB | +| DISK | Optane 500GB SSD \* 1 | + +Sysbench 版本：1.1.0 + +## 测试方案 + +使用 Sysbench 向集群导入 **16 张表，每张数据 1000 万**。通过 HAProxy 代理，分别以递增并发数向集群发送请求，单次并发测试时间 5 分钟。 + +### TiDB 版本信息 + +### v2.1.0-rc.2 + +| 组件 | GitHash | +| :-: | :-: | +| TiDB | 08e56cd3bae166b2af3c2f52354fbc9818717f62 | +| TiKV | 57e684016dafb17dc8a6837d30224be66cbc7246 | +| PD | 6a7832d2d6e5b2923c79683183e63d030f954563 | + +### v2.0.6 + +| 组件 | GitHash | +| :-: | :-: | +| TiDB | b13bc08462a584a085f377625a7bab0cc0351570 | +| TiKV | 57c83dc4ebc93d38d77dc8f7d66db224760766cc | +| PD | b64716707b7279a4ae822be767085ff17b5f3fea | + +### TiDB 参数配置 + +两版本 TiDB 均使用**默认配置**。 + +### TiKV 参数配置 + +两版本 TiKV 均使用如下配置： + +```txt +[readpool.storage] +normal-concurrency = 8 +[server] +grpc-concurrency = 8 +[raftstore] +sync-log = false +[rocksdb.defaultcf] +block-cache-size = "60GB" +[rocksdb.writecf] +block-cache-size = "20GB" +``` + +### 集群拓扑 + +| 机器 IP | 部署实例 | +| :-: | :-: | +| 172.16.30.31 | 1\*Sysbench 1\*HAProxy | +| 172.16.30.32 | 1\*TiDB 1\*pd 1\*TiKV | +| 172.16.30.33 | 1\*TiDB 1\*TiKV | +| 172.16.30.34 | 1\*TiDB 1\*TiKV | + +## 测试结果 + +### Point Select 测试 + +| 版本 | threads | qps | 95% latency(ms) | +| :-: | :-: | :-: | :-: | +| v2.1 | 64 | 111481.09 | 1.16 | +| v2.1 | 128 | 145102.62 | 2.52 | +| v2.1 | 256 | 161311.9 | 4.57 | +| v2.1 | 512 | 184991.19 | 7.56 | +| v2.1 | 1024 | 230282.74 | 10.84 | +| v2.0 | 64 | 75285.87 | 1.93 | +| v2.0 | 128 | 92141.79 | 3.68 | +| v2.0 | 256 | 107464.93 | 6.67 | +| v2.0 | 512 | 121350.61 | 11.65 | +| v2.0 | 1024 | 150036.31 | 17.32 | + +![point select](../media/sysbench_v3_point_select.png) + +v2.1 比 v2.0 在 Point Select 查询性能上，**提升了 50%**。 + +### Update Non-Index 测试 + +| 版本 | threads | qps | 95% latency(ms) | +| :-: | :-: | :-: | :-: | +| v2.1 | 64 | 18946.09 | 5.77 | +| v2.1 | 128 | 22022.82 | 12.08 | +| v2.1 | 256 | 24679.68 | 25.74 | +| v2.1 | 512 | 25107.1 | 51.94 | +| v2.1 | 1024 | 27144.92 | 106.75 | +| v2.0 | 64 | 16316.85 | 6.91 | +| v2.0 | 128 | 20944.6 | 11.45 | +| v2.0 | 256 | 24017.42 | 23.1 | +| v2.0 | 512 | 25994.33 | 46.63 | +| v2.0 | 1024 | 27917.52 | 92.42 | + +![update non-index](../media/sysbench_v3_update_non_index.png) + +v2.1 与 v2.0 在 Update Non-Index 写入性能上基本一致。 + +### Update Index 测试 + +| 版本 | threads | qps | 95% latency(ms) | +| :-: | :-: | :-: | :-: | +| v2.1 | 64 | 9934.49 | 12.08 | +| v2.1 | 128 | 10505.95 | 25.28 | +| v2.1 | 256 | 11007.7 | 55.82 | +| v2.1 | 512 | 11198.81 | 106.75 | +| v2.1 | 1024 | 11591.89 | 200.47 | +| v2.0 | 64 | 9754.68 | 11.65 | +| v2.0 | 128 | 10603.31 | 24.38 | +| v2.0 | 256 | 11011.71 | 50.11 | +| v2.0 | 512 | 11162.63 | 104.84 | +| v2.0 | 1024 | 12067.63 | 179.94 | + +![update index](../media/sysbench_v3_update_index.png) + +v2.1 与 v2.0 在 Update Index 写入性能上基本一致。 \ No newline at end of file diff --git a/benchmark/tpch-v2.md b/benchmark/tpch-v2.md new file mode 100644 index 000000000000..de31f746af7d --- /dev/null +++ b/benchmark/tpch-v2.md @@ -0,0 +1,102 @@ +--- +title: TiDB TPC-H 50G 性能测试报告 +category: benchmark +--- + +# TiDB TPC-H 50G 性能测试报告 + +## 测试目的 + +测试 TiDB 在 OLAP 场景下 2.0 和 2.1 版本的性能对比。 + +> **注意**：不同的测试环境可能使测试结果发生改变。 + +## 测试环境 + +### 测试机器信息 + +1. 系统信息 + +| 机器 IP | 操作系统 | 内核版本 | 文件系统类型 | +|--------------|------------------------|------------------------------|--------------| +| 10.0.1.4 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | +| 10.0.1.5 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | +| 10.0.1.6 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | +| 10.0.1.7 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | +| 10.0.1.8 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | +| 10.0.1.9 | CentOS 7.5.1804 64bit | 3.10.0-862.3.3.el7.x86\_64 | ext4 | + +2. 硬件信息 + +| 类别 | 10.0.1.4 | 10.0.1.5, 10.0.1.6, 10.0.1.7, 10.0.1.8, 10.0.1.9 | +|------------|------------------------------------------------------|------------------------------------------------------| +| CPU | 16 vCPUs, Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz | 8 vCPUs, Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz | +| 内存 | 110G | 55G | +| 磁盘 | 221G SSD | 111G SSD | +| 网卡 | 万兆网卡, 10000Mb/s | 万兆网卡, 10000Mb/s | + +### TPC-H + +[tidb-bench/tpch](https://github.com/pingcap/tidb-bench/tree/master/tpch) + +### 集群拓扑 + +| 机器 IP | 部署的实例 | +|----------|------------| +| 10.0.1.5 | TiKV \* 1 | +| 10.0.1.6 | TiKV \* 1 | +| 10.0.1.7 | TiKV \* 1 | +| 10.0.1.8 | TiKV \* 1 | +| 10.0.1.9 | TiKV \* 1 | +| 10.0.1.4 | PD \* 1 | +| 10.0.1.4 | TiDB \* 1 | + +### TiDB 版本信息 + +TiDB 2.0： + +| 组件名 | 版本号 | commit hash | +|--------|-------------|--------------------------------------------| +| TiDB | v2.0.7 | 29ec059cb3b7d14b6f52c2f219f94a89570162bc | +| TiKV | v2.0.7 | d0b8cd7c7f62f06e7ef456837bd32a47da1ca4cd | +| PD | v2.0.5 | b64716707b7279a4ae822be767085ff17b5f3fea | + +TiDB 2.1： + +| 组件名 | 版本号 | commit hash | +|--------|-------------|--------------------------------------------| +| TiDB | v2.1.0-rc.2 | 16864f95b47f859ed6104555ccff0387abdc2429 | +| TiKV | v2.1.0-rc.2 | 8458ce53ebbd434c48baac6373fe0f0a43a54005 | +| PD | v2.1.0-rc.2 | 55db505e8f35e8ab4e00efd202beb27a8ecc40fb | + +## 测试结果 + +| Query ID | TiDB 2.0 | TiDB 2.1 | +|-----------|----------------|----------------| +| 1 | 121.550595999s | 91.4755480289s | +| 2 | 53.0638680458s | 23.1186130047s | +| 3 | 75.7236940861s | 61.790802002s | +| 4 | 30.2647120953s | 26.3483440876s | +| 6 | 51.4850790501s | 34.6432199478s | +| 7 | 216.787364006s | 94.9856910706s | +| 8 | 188.717588902s | 181.852752209s | +| 9 | 546.438174009s | 414.462754965s | +| 10 | 109.978317022s | 37.0369961262s | +| 11 | 42.9398438931s | 37.6951580048s | +| 12 | 60.455039978s | 40.2236878872s | +| 13 | 230.278712988s | 70.2887151241s | +| 14 | 61.2673521042s | 35.8372960091s | +| 16 | 30.2539310455s | 18.5897550583s | +| 17 | 3200.70173788s | 263.095014811s | +| 18 | 1035.59847498s | 296.360667944s | +| 19 | 54.3732938766s | 40.4523630142s | +| 20 | 105.094577074s | 53.2429068089s | +| 21 | 389.883709908s | 361.034544945s | +| 22 | 64.0494630337s | 65.7153418064s | + +![TPC-H Query Result](../media/tpch-query-result-v2.png) + +说明： +- 图中橙色为 Release 2.1，蓝色为 Release 2.0，纵坐标是 Query 的处理时间，越低越好 +- Query 15 因为 2.1 和 2.0 都还未支持视图，所以未列出结果 +- Query 5 因为 Join Order 问题长时间未跑出结果来，所以未列出结果 diff --git a/features.md b/features.md new file mode 100644 index 000000000000..b62582fd27fb --- /dev/null +++ b/features.md @@ -0,0 +1,28 @@ +--- +title: TiDB 核心特性 +category: introduction +--- + +# TiDB 核心特性 + +本文详细介绍 TiDB 的两大核心特性：水平扩展与高可用。 + +## 水平扩展 + +无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。 + +## 高可用 + +高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。 + +- TiDB + + TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。 + +- PD + + PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。 + +- TiKV + + TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。 \ No newline at end of file diff --git a/media/sysbench_v3_point_select.png b/media/sysbench_v3_point_select.png new file mode 100644 index 000000000000..42232abc105d Binary files /dev/null and b/media/sysbench_v3_point_select.png differ diff --git a/media/sysbench_v3_update_index.png b/media/sysbench_v3_update_index.png new file mode 100644 index 000000000000..bbc65d10814a Binary files /dev/null and b/media/sysbench_v3_update_index.png differ diff --git a/media/sysbench_v3_update_non_index.png b/media/sysbench_v3_update_non_index.png new file mode 100644 index 000000000000..0c003ace60f3 Binary files /dev/null and b/media/sysbench_v3_update_non_index.png differ diff --git a/media/tpch-query-result-v2.png b/media/tpch-query-result-v2.png new file mode 100644 index 000000000000..035a4d33e224 Binary files /dev/null and b/media/tpch-query-result-v2.png differ diff --git a/op-guide/ansible-deployment-rolling-update.md b/op-guide/ansible-deployment-rolling-update.md index 4378d997c5fc..671125076caa 100644 --- a/op-guide/ansible-deployment-rolling-update.md +++ b/op-guide/ansible-deployment-rolling-update.md @@ -7,23 +7,22 @@ category: deployment 滚动升级 TiDB 集群时，会串行关闭服务，更新服务 binary 和配置文件，再启动服务。在前端配置负载均衡的情况下，滚动升级期间不影响业务运行（最小环境 ：pd * 3 、tidb * 2、tikv * 3）。 -> **注**： -> 如果 TiDB 集群开启了 binlog，部署了 Pump 和 Drainer 服务，升级 TiDB 服务时会升级 Pump，请先停止 Drainer 服务再执行滚动升级操作。 +> **注**：如果 TiDB 集群开启了 binlog，部署了 Pump 和 Drainer 服务，升级 TiDB 服务时会升级 Pump，请先停止 Drainer 服务再执行滚动升级操作。 ## 升级组件版本 -> **注**： -> 跨大版本升级，必须更新 `tidb-ansible`，从 TiDB 1.0 升级到 TiDB 2.0，请参考 [TiDB 2.0 升级操作指南](tidb-v2-upgrade-guide.md)。 -> 小版本升级，也建议更新 `tidb-ansible`，以获取最新的配置文件模板、特性及 bug 修复。 +跨大版本升级，必须更新 `tidb-ansible`，从 TiDB 1.0 升级到 TiDB 2.0，参考 [TiDB 2.0 升级操作指南](tidb-v2-upgrade-guide.md)。小版本升级，也建议更新 `tidb-ansible`，以获取最新的配置文件模板、特性及 bug 修复。 ### 自动下载 binary -1. 修改 `/home/tidb/tidb-ansible/inventory.ini` 中的 `tidb_version` 参数值，指定需要升级的版本号，如从 `v2.0.2` 升级到 `v2.0.3` +1. 修改 `/home/tidb/tidb-ansible/inventory.ini` 中的 `tidb_version` 参数值，指定需要升级的版本号，如从 `v2.0.6` 升级到 `v2.0.7` ``` - tidb_version = v2.0.3 + tidb_version = v2.0.7 ``` + > **注**：如果使用 master 分支的 tidb-ansible，`tidb_version = latest` 保持不变即可，latest 版本的 TiDB 安装包会每日更新。 + 2. 删除原有的 downloads 目录 `/home/tidb/tidb-ansible/downloads/` ``` @@ -31,7 +30,7 @@ category: deployment $ rm -rf downloads ``` -3. 使用 playbook 下载 TiDB `v2.0.3` 版本 binary，自动替换 binary 到 `/home/tidb/tidb-ansible/resource/bin/` +3. 使用 playbook 下载 TiDB binary，自动替换 binary 到 `/home/tidb/tidb-ansible/resource/bin/` ``` $ ansible-playbook local_prepare.yml @@ -39,10 +38,16 @@ category: deployment ### 手动下载 binary -除 “下载 binary” 中描述的方法之外，也可以手动下载 binary，解压后手动替换 binary 到 `/home/tidb/tidb-ansible/resource/bin/`，请注意替换链接中的版本号。 +除 “自动下载 binary” 中描述的方法之外，也可以手动下载 binary，解压后手动替换 binary 到 `/home/tidb/tidb-ansible/resource/bin/`，需注意替换链接中的版本号。 + +``` +$ wget http://download.pingcap.org/tidb-v2.0.7-linux-amd64.tar.gz +``` + +如果使用 master 分支的 tidb-ansible，使用以下命令下载 binary： ``` -wget http://download.pingcap.org/tidb-v2.0.3-linux-amd64-unportable.tar.gz +$ wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz ``` ### 使用 Ansible 滚动升级 diff --git a/op-guide/ansible-deployment.md b/op-guide/ansible-deployment.md index 8bbab0645181..ca6b24e5945b 100644 --- a/op-guide/ansible-deployment.md +++ b/op-guide/ansible-deployment.md @@ -7,7 +7,7 @@ category: deployment ## 概述 -Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingcap/tidb-ansible) 是 PingCAP 基于 Ansible playbook 功能编写的集群部署工具。使用 TiDB-Ansible 可以快速部署一个完整的 TiDB 集群。 +Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingcap/tidb-ansible) 是 PingCAP 基于 Ansible playbook 功能编写的集群部署工具。本文档介绍如何使用 TiDB-Ansible 部署一个完整的 TiDB 集群。 本部署工具可以通过配置文件设置集群拓扑，完成以下各项运维工作： @@ -21,6 +21,8 @@ Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingc - [清除集群数据](ansible-operation.md#清除集群数据) - [销毁集群](ansible-operation.md#销毁集群) +> **注**：对于生产环境，须使用 TiDB-Ansible 部署 TiDB 集群。如果只是用于测试 TiDB 或体验 TiDB 的特性，建议[使用 Docker Compose 在单机上快速部署 TiDB 集群](docker-compose.md)。 + ## 准备机器 1. 部署目标机器若干 @@ -77,10 +79,15 @@ Ansible 是一款自动化运维工具，[TiDB-Ansible](https://github.com/pingc tidb ALL=(ALL) NOPASSWD: ALL ``` -生成 ssh key: 执行 `su` 命令从 `root` 用户切换到 `tidb` 用户下，创建 `tidb` 用户 ssh key， 提示 `Enter passphrase` 时直接回车即可。执行成功后，ssh 私钥文件为 `/home/tidb/.ssh/id_rsa`， ssh 公钥文件为 `/home/tidb/.ssh/id_rsa.pub`。 +生成 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 rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/tidb/.ssh/id_rsa): @@ -107,11 +114,16 @@ The key's randomart image is: ## 在中控机器上下载 TiDB-Ansible -以 `tidb` 用户登录中控机并进入 `/home/tidb` 目录。 +以 `tidb` 用户登录中控机并进入 `/home/tidb` 目录。以下为 tidb-ansible 分支与 TiDB 版本对应关系，版本选择可以咨询官方。 + +| tidb-ansible 分支 | TiDB 版本 | 备注 | +| ---------------- | --------- | --- | +| release-2.0 | 2.0 版本 | 最新稳定版本，可用于生产环境。 | +| master | master 版本 | 包含最新特性，每日更新。 | -使用以下命令从 Github [TiDB-Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 TiDB-Ansible 相应版本，默认的文件夹名称为 `tidb-ansible`，以下为各版本下载示例，版本选择可以咨询官方。 +使用以下命令从 Github [TiDB-Ansible 项目](https://github.com/pingcap/tidb-ansible)上下载 TiDB-Ansible 相应分支，默认的文件夹名称为 `tidb-ansible`。 -下载 2.0 GA 版本： +下载 2.0 版本： ``` $ git clone -b release-2.0 https://github.com/pingcap/tidb-ansible.git @@ -446,8 +458,7 @@ TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy | cluster_name | 集群名称，可调整 | | tidb_version | TiDB 版本，TiDB-Ansible 各分支默认已配置 | | process_supervision | 进程监管方式，默认为 systemd，可选 supervise | -| timezone | 修改部署目标机器时区，默认为 `Asia/Shanghai`，可调整，与 `set_timezone` 变量结合使用 | -| set_timezone | 默认为 True，即修改部署目标机器时区，关闭可修改为 False | +| timezone | 新安装 TiDB 集群第一次启动 bootstrap（初始化）时，将 TiDB 全局默认时区设置为该值。TiDB 使用的时区后续可通过 `time_zone` 全局变量和 session 变量来修改，参考[时区支持](https://github.com/pingcap/docs-cn/blob/master/sql/time-zone.md)。 默认为 `Asia/Shanghai`，可选值参考[ timzone 列表](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。 | | enable_firewalld | 开启防火墙，默认不开启，如需开启，请将[部署建议-网络要求](recommendation.md#网络要求) 中的端口加入白名单 | | enable_ntpd | 检测部署目标机器 NTP 服务，默认为 True，请勿关闭 | | set_hostname | 根据 IP 修改部署目标机器主机名，默认为 False | @@ -468,7 +479,7 @@ TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy 1. 确认 `tidb-ansible/inventory.ini` 文件中 `ansible_user = tidb`，本例使用 `tidb` 用户作为服务运行用户，配置如下： - > `ansible_user` 不要设置成 `root` 用户，`tidb-ansbile` 限制了服务以普通用户运行。 + > `ansible_user` 不要设置成 `root` 用户，`tidb-ansible` 限制了服务以普通用户运行。 ```ini ## Connection diff --git a/op-guide/dashboard-overview-info.md b/op-guide/dashboard-overview-info.md index 2e3ab97a43e2..13e6cab50fa0 100644 --- a/op-guide/dashboard-overview-info.md +++ b/op-guide/dashboard-overview-info.md @@ -9,7 +9,7 @@ category: monitoring 目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node\_exporter、Overview 等。 -对于日常运维，我们单独挑选出重要的 Metrics 放在 Overview 页面，方便日常运维人员观察集群组件(PD, TiDB, TiKV)使用状态以及集群使用状态 。 +对于日常运维，我们单独挑选出重要的 Metrics 放在 Overview 页面，方便日常运维人员观察集群组件 (PD, TiDB, TiKV) 使用状态以及集群使用状态。 以下为 Overview Dashboard 监控说明： diff --git a/op-guide/docker-compose.md b/op-guide/docker-compose.md index d377f1b14f89..630c9ea042da 100644 --- a/op-guide/docker-compose.md +++ b/op-guide/docker-compose.md @@ -5,9 +5,9 @@ category: deployment # 使用 Docker Compose 快速构建集群 -本文档介绍如何在单机上通过 Docker Compose 快速一键部署一套 TiDB 测试集群。 +本文档介绍如何在单机上通过 Docker Compose 快速一键部署一套 TiDB 测试集群。[Docker Compose](https://docs.docker.com/compose/overview) 可以通过一个 YAML 文件定义多个容器的应用服务，然后一键启动或停止。 -[Docker Compose](https://docs.docker.com/compose/overview) 可以通过一个 YAML 文件定义多个容器的应用服务，然后一键启动或停止。 +> **注**：对于生产环境，不要使用 Docker Compose 进行部署，而应[使用 Ansible 部署 TiDB 集群](ansible-deployment.md)。 ## 准备环境 @@ -82,11 +82,9 @@ category: deployment PD，TiKV，TiDB 和 tidb-vision 支持从 GitHub 源码或本地文件构建 Docker 镜像，供开发测试使用。 - - 如果希望从 GitHub 源码构建某个组件的镜像，需要将其 `image` 字段留空，然后设置其 `buildFrom` 为 `remote`。 + - 如果希望从本地已编译好的 binary 文件构建 PD，TiKV 或 TiDB 镜像，需要将其 `image` 字段留空，并将已编译好的 binary 拷贝到对应的 `pd/bin/pd-server`，`tikv/bin/tikv-server`，`tidb/bin/tidb-server`。 - - 如果希望从本地已编译好的 binary 文件构建 PD，TiKV 或 TiDB 镜像，需要将其 `image` 字段留空，然后设置其 `buildFrom` 为 `local`，并将已编译好的 binary 拷贝到对应的 `pd/bin/pd-server`，`tikv/bin/tikv-server`，`tidb/bin/tidb-server`。 - - - 如果希望从本地构建 tidb-vision 镜像，需要将其 `image` 字段留空，然后设置其 `buildFrom` 为 `local`，并将 tidb-vision 项目拷贝到 `tidb-vision/tidb-vision`。 + - 如果希望从本地构建 tidb-vision 镜像，需要将其 `image` 字段留空，并将 tidb-vision 项目拷贝到 `tidb-vision/tidb-vision`。 4. 生成 `docker-compose.yml` 文件 diff --git a/op-guide/docker-deployment.md b/op-guide/docker-deployment.md index 8518429f23ff..767ab64a0f77 100644 --- a/op-guide/docker-deployment.md +++ b/op-guide/docker-deployment.md @@ -5,13 +5,14 @@ category: deployment # TiDB Docker 部署方案 -本篇将展示如何在多台主机上使用 Docker 部署一个 TiDB 集群。 +本文介绍如何使用 Docker 部署一个多节点的 TiDB 集群。 -阅读本章前，请先确保阅读 [TiDB 整体架构](../overview.md#tidb-整体架构) 及 [部署建议](../op-guide/recommendation.md)。 +> **注**：对于生产环境，不要使用 Docker 进行部署，而应[使用 Ansible 部署 TiDB 集群](ansible-deployment.md)。 ## 环境准备 ### 安装 Docker + Docker 可以方便地在 Linux / Mac OS / Windows 平台安装，安装方法请参考 [Docker 官方文档](https://www.docker.com/products/docker)。 ### 拉取 TiDB 的 Docker 镜像 diff --git a/op-guide/history-read.md b/op-guide/history-read.md index 75b515564586..aa1020f6882c 100644 --- a/op-guide/history-read.md +++ b/op-guide/history-read.md @@ -27,105 +27,112 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 TiDB 使用 MVCC 管理版本，当更新/删除数据时，不会做真正的数据删除，只会添加一个新版本数据，所以可以保留历史数据。历史数据不会全部保留，超过一定时间的历史数据会被彻底删除，以减小空间占用以及避免历史版本过多引入的性能开销。 -我们使用周期性运行的 GC （Garbage Collection， 垃圾回收）来进行清理，关于 GC 的详细介绍清参阅 [TiDB 垃圾回收 (GC)](gc.md) +TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，关于 GC 的详细介绍参见 [TiDB 垃圾回收 (GC)](gc.md)。 -这里我们需要重点关注的是 `tikv_gc_life_time` 和 `tikv_gc_safe_point` 这条。`tikv_gc_life_time` 用于配置历史版本保留时间，可以手动修改；`tikv_gc_safe_point` 记录了当前的 safePoint，用户可以安全地使用大于 safePoint 的时间戳创建 snapshot 读取历史版本。safePoint 在每次 GC 开始运行时自动更新。 +这里需要重点关注的是 `tikv_gc_life_time` 和 `tikv_gc_safe_point` 这条。`tikv_gc_life_time` 用于配置历史版本保留时间，可以手动修改；`tikv_gc_safe_point` 记录了当前的 safePoint，用户可以安全地使用大于 safePoint 的时间戳创建 snapshot 读取历史版本。safePoint 在每次 GC 开始运行时自动更新。 ## 示例 -初始化阶段，创建一个表，并插入几行数据： - -```sql -mysql> create table t (c int); -Query OK, 0 rows affected (0.01 sec) - -mysql> insert into t values (1), (2), (3); -Query OK, 3 rows affected (0.00 sec) -``` - -查看表中的数据： - -``` -mysql> select * from t; -+------+ -| c | -+------+ -| 1 | -| 2 | -| 3 | -+------+ -3 rows in set (0.00 sec) -``` - -查看当前时间： - -```sql -mysql> select now(); -+---------------------+ -| now() | -+---------------------+ -| 2016-10-08 16:45:26 | -+---------------------+ -1 row in set (0.00 sec) -``` - -更新某一行数据： - -```sql -mysql> update t set c=22 where c=2; -Query OK, 1 row affected (0.00 sec) -``` - -确认数据已经被更新： - -```sql -mysql> select * from t; -+------+ -| c | -+------+ -| 1 | -| 22 | -| 3 | -+------+ -3 rows in set (0.00 sec) -``` - -设置一个特殊的环境变量，这个是一个 session scope 的变量，其意义为读取这个时间之前的最新的一个版本。注意这里的时间设置的是 update 语句之前的那个时间： - -```sql -mysql> set @@tidb_snapshot="2016-10-08 16:45:26"; -Query OK, 0 rows affected (0.00 sec) -``` - -这里读取到的内容即为 update 之前的内容，也就是历史版本： - -```sql -mysql> select * from t; -+------+ -| c | -+------+ -| 1 | -| 2 | -| 3 | -+------+ -3 rows in set (0.00 sec) -``` - -清空这个变量后，即可读取最新版本数据： - -```sql -mysql> set @@tidb_snapshot=""; -Query OK, 0 rows affected (0.00 sec) -``` - -```sql -mysql> select * from t; -+------+ -| c | -+------+ -| 1 | -| 22 | -| 3 | -+------+ -3 rows in set (0.00 sec) -``` +1. 初始化阶段，创建一个表，并插入几行数据： + + ```sql + mysql> create table t (c int); + Query OK, 0 rows affected (0.01 sec) + + mysql> insert into t values (1), (2), (3); + Query OK, 3 rows affected (0.00 sec) + ``` + +2. 查看表中的数据： + + ```sql + mysql> select * from t; + +------+ + | c | + +------+ + | 1 | + | 2 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` + +3. 查看当前时间： + + ```sql + mysql> select now(); + +---------------------+ + | now() | + +---------------------+ + | 2016-10-08 16:45:26 | + +---------------------+ + 1 row in set (0.00 sec) + ``` + +4. 更新某一行数据： + + ```sql + mysql> update t set c=22 where c=2; + Query OK, 1 row affected (0.00 sec) + ``` + +5. 确认数据已经被更新： + + ```sql + mysql> select * from t; + +------+ + | c | + +------+ + | 1 | + | 22 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` + +6. 设置一个特殊的环境变量，这个是一个 session scope 的变量，其意义为读取这个时间之前的最新的一个版本。 + + ```sql + mysql> set @@tidb_snapshot="2016-10-08 16:45:26"; + Query OK, 0 rows affected (0.00 sec) + ``` + + > **注意**： + > + > - 这里的时间设置的是 update 语句之前的那个时间。 + > - 在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示全局变量，`@` 表示 Session 变量。 + + 这里读取到的内容即为 update 之前的内容，也就是历史版本： + + ```sql + mysql> select * from t; + +------+ + | c | + +------+ + | 1 | + | 2 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` + +7. 清空这个变量后，即可读取最新版本数据： + + ```sql + mysql> set @@tidb_snapshot=""; + Query OK, 0 rows affected (0.00 sec) + ``` + + ```sql + mysql> select * from t; + +------+ + | c | + +------+ + | 1 | + | 22 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` + + > **注意**：在 `tidb_snapshot` 前须使用 `@@` 而非 `@`，因为 `@@` 表示全局变量，`@` 表示 Session 变量。 \ No newline at end of file diff --git a/overview.md b/overview.md index f638b1956eed..04f68ae370ba 100644 --- a/overview.md +++ b/overview.md @@ -1,19 +1,17 @@ --- -title: TiDB 简介与整体架构 +title: TiDB 简介 category: introduction --- -# TiDB 简介与整体架构 - -## TiDB 简介 +# TiDB 简介 TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。 -TiDB 具备如下核心特性： +TiDB 具备如下特性： - 高度兼容 MySQL - 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 + [大多数情况下](https://www.pingcap.com/docs-cn/sql/mysql-compatibility/)，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 - 水平弹性扩展 @@ -43,50 +41,4 @@ TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间 - [说存储](https://pingcap.com/blog-cn/tidb-internal-1/) - [说计算](https://pingcap.com/blog-cn/tidb-internal-2/) -- [谈调度](https://pingcap.com/blog-cn/tidb-internal-3/) - -## TiDB 整体架构 - -要深入了解 TiDB 的水平扩展和高可用特点，首先需要了解 TiDB 的整体架构。TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有用于解决用户复杂 OLAP 需求的 [TiSpark](https://github.com/pingcap/tispark/) 组件。 - -![TiDB Architecture](media/tidb-architecture.png) - -### 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 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。 - -### TiSpark - -TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。 - -## 核心特性 - -### 水平扩展 - -无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。 - -### 高可用 - -高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。 - -+ TiDB - - TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。 - -+ PD - - PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。 - -+ TiKV - - TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。 +- [谈调度](https://pingcap.com/blog-cn/tidb-internal-3/) \ No newline at end of file diff --git a/releases/207.md b/releases/207.md new file mode 100644 index 000000000000..82cba1593466 --- /dev/null +++ b/releases/207.md @@ -0,0 +1,36 @@ +--- +title: TiDB 2.0.7 release notes +category: Releases +--- + +# TiDB 2.0.7 Release Notes + +2018 年 9 月 7 日，TiDB 发布 2.0.7 版。该版本在 2.0.6 版的基础上，对系统兼容性、稳定性做出了改进。 + +## TiDB + +- New Feature + - 在 `information_schema` 里添加 `PROCESSLIST` 表 [#7286](https://github.com/pingcap/tidb/pull/7286) +- Improvements + - 收集更多语句执行细节，并输出在 `SLOW QUERY` 日志里 [#7364](https://github.com/pingcap/tidb/pull/7364) + - `SHOW CREATE TABLE` 不再输出分区信息 [#7388](https://github.com/pingcap/tidb/pull/7388) + - 通过设置 RC 隔离级别和低优先级优化 `ANALYZE` 语句执行效率 [#7500](https://github.com/pingcap/tidb/pull/7500) + - 加速 `ADD UNIQUE INDEX` [#7562](https://github.com/pingcap/tidb/pull/7562) + - 增加控制 DDL 并发度的选项 [#7563](https://github.com/pingcap/tidb/pull/7563) +- Bug Fixes + - 修复 `PRIMARY KEY` 为整数的表，无法使用 `USE INDEX(PRIMARY)` 的问题 [#7298](https://github.com/pingcap/tidb/pull/7298) + - 修复 `Merge Join` 和 `Index Join` 在 inner row 为 `NULL` 时输出多余结果的问题 [#7301](https://github.com/pingcap/tidb/pull/7301) + - 修复 chunk size 设置过小时，`Join` 输出多余结果的问题 [#7315](https://github.com/pingcap/tidb/pull/7315) + - 修复建表语句中包含 `range column` 语法导致 panic 的问题 [#7379](https://github.com/pingcap/tidb/pull/7379) + - 修复 `admin check table` 对时间类型的列误报的问题 [#7457](https://github.com/pingcap/tidb/pull/7457) + - 修复以默认值 `current_timestamp` 插入的数据无法用 `=` 条件查询到的问题 [#7467](https://github.com/pingcap/tidb/pull/7467) + - 修复以 `ComStmtSendLongData` 命令插入空字符串参数被误解析为 `NULL` 的问题 [#7508](https://github.com/pingcap/tidb/pull/7508) + - 修复特定场景下 `auto analyze` 不断重复执行的问题 [#7556](https://github.com/pingcap/tidb/pull/7556) + - 修复 parser 无法解析以换行符结尾的单行注释的问题 [#7635](https://github.com/pingcap/tidb/pull/7635) + +## TiKV + +- Improvement + - 空集群默认打开 `dynamic-level-bytes` 参数减少空间放大 +- Bug Fix + - 在 Region merge 之后更新 Region 的 `approximate size` 和 keys \ No newline at end of file diff --git a/releases/21rc2.md b/releases/21rc2.md new file mode 100644 index 000000000000..231b3f653bfc --- /dev/null +++ b/releases/21rc2.md @@ -0,0 +1,119 @@ +--- +title: TiDB 2.1 RC2 Release Notes +category: Releases +--- + +# TiDB 2.1 RC2 Release Notes + +2018 年 9 月 14 日，TiDB 发布 2.1 RC2 版。相比 2.1 RC1 版本，该版本对系统稳定性、优化器、统计信息以及执行引擎做了很多改进。 + +## TiDB + +- SQL 优化器 + - 新版 Planner 设计方案 [#7543](https://github.com/pingcap/tidb/pull/7543) + - 提升常量传播优化规则 [#7276](https://github.com/pingcap/tidb/pull/7276) + - 增强 Range 的计算逻辑使其能够同时处理多个 `IN` 或者等值条件 [#7577](https://github.com/pingcap/tidb/pull/7577) + - 修复当 Range 为空时，`TableScan` 的估算结果不正确的问题 [#7583](https://github.com/pingcap/tidb/pull/7583) + - 为 `UPDATE` 语句支持 `PointGet` 算子 [#7586](https://github.com/pingcap/tidb/pull/7586) + - 修复 `FirstRow` 聚合函数某些情况下在执行过程中 panic 的问题 [#7624](https://github.com/pingcap/tidb/pull/7624) +- SQL 执行引擎 + - 解决 HashJoin 算子在遇到错误的情况下潜在的 DataRace 问题 [#7554](https://github.com/pingcap/tidb/pull/7554) + - HashJoin 算子同时读取内表数据和构建 Hash 表 [#7544](https://github.com/pingcap/tidb/pull/7544) + - 优化 Hash 聚合算子性能 [#7541](https://github.com/pingcap/tidb/pull/7541) + - 优化 Join 算子性能 [#7493](https://github.com/pingcap/tidb/pull/7493)、[#7433](https://github.com/pingcap/tidb/pull/7433) + - 修复 `UPDATE JOIN` 在 Join 顺序改变后结果不正确的问题 [#7571](https://github.com/pingcap/tidb/pull/7571) + - 提升 Chunk 迭代器的性能 [#7585](https://github.com/pingcap/tidb/pull/7585) +- 统计信息 + - 解决重复自动 Analyze 统计信息的问题 [#7550](https://github.com/pingcap/tidb/pull/7550) + - 解决统计信息无变化时更新统计信息遇到错误的问题 [#7530](https://github.com/pingcap/tidb/pull/7530) + - `Analyze` 执行时使用低优先级以及 RC 隔离级别 [#7496](https://github.com/pingcap/tidb/pull/7496) + - 支持只在一天中的某个时间段开启统计信息自动更新的功能 [#7570](https://github.com/pingcap/tidb/pull/7570) + - 修复统计信息写日志时发生的 panic [#7588](https://github.com/pingcap/tidb/pull/7588) + - 支持通过 `ANALYZE TABLE WITH BUCKETS` 语句配置直方图中桶的个数 [#7619](https://github.com/pingcap/tidb/pull/7619) + - 修复更新空的直方图时 panic 的问题 [#7640](https://github.com/pingcap/tidb/pull/7640) + - 使用统计信息更新 `information_schema.tables.data_length` [#7657](https://github.com/pingcap/tidb/pull/7657) +- Server + - 增加 Trace 相关的依赖库 [#7532](https://github.com/pingcap/tidb/pull/7532) + - 开启 Golang 的 mutex profile 功能 [#7512](https://github.com/pingcap/tidb/pull/7512) + - `Admin` 语句需要 `Super_priv` 权限 [#7486](https://github.com/pingcap/tidb/pull/7486) + - 禁止用户 Drop 关键的系统表 [#7471](https://github.com/pingcap/tidb/pull/7471) + - 从 `juju/errors` 切换到 `pkg/errors` [#7151](https://github.com/pingcap/tidb/pull/7151) + - 完成 SQL Tracing 功能原型 [#7016](https://github.com/pingcap/tidb/pull/7016) + - 删除 goroutine pool [#7564](https://github.com/pingcap/tidb/pull/7564) + - 支持使用 `USER1` 信号来查看 goroutine 信息 [#7587](https://github.com/pingcap/tidb/pull/7587) + - 将 TiDB 启动时的内部 SQL 设置为高优先级 [#7616](https://github.com/pingcap/tidb/pull/7616) + - 在监控中用不同的标签区分内部 SQL 和用户 SQL [#7631](https://github.com/pingcap/tidb/pull/7631) + - 缓存最近一周内最慢的 30 条慢查询日志在 TiDB Server 上 [#7646](https://github.com/pingcap/tidb/pull/7646) + - TiDB 集群设置时区的方案 [#7656](https://github.com/pingcap/tidb/pull/7656) + - 丰富 `GC life time is shorter than transaction duration` 错误信息 [#7658](https://github.com/pingcap/tidb/pull/7658) + - 在 TiDB 集群启动时设置集群时区信息 [#7638](https://github.com/pingcap/tidb/pull/7638) +- 兼容性 + - `Year` 类型字段增加 unsigned flag [#7542](https://github.com/pingcap/tidb/pull/7542) + - 修复在 Prepare/Execute 模式下，`Year` 类型结果长度设置问题 [#7525](https://github.com/pingcap/tidb/pull/7525) + - 修复 Prepare/Execute 模式下时间 0 值的处理问题 [#7506](https://github.com/pingcap/tidb/pull/7506) + - 解决整数类型除法实现中的错误处理问题 [#7492](https://github.com/pingcap/tidb/pull/7492) + - 解决 `ComStmtSendLongData` 处理过程中的兼容性问题 [#7485](https://github.com/pingcap/tidb/pull/7485) + - 解决字符串转为整数类型过程中的错误处理问题 [#7483](https://github.com/pingcap/tidb/pull/7483) + - 优化 `information_schema.columns_in_table` 表中的值精度 [#7463](https://github.com/pingcap/tidb/pull/7463) + - 修复使用 MariaDB 客户端对字符串类型数据的写入和更新的兼容性问题 [#7573](https://github.com/pingcap/tidb/pull/7573) + - 修复返回值别名的兼容性问题 [#7600](https://github.com/pingcap/tidb/pull/7600) + - 修复 `information_schema.COLUMNS` 表中浮点数的 `NUMERIC_SCALE` 值不正确的问题 [#7602](https://github.com/pingcap/tidb/pull/7602) + - 解决单行注释内容为空 Parser 报错的问题 [#7612](https://github.com/pingcap/tidb/pull/7612) +- 表达式 + - 在 `insert` 函数中检查 `max_allowed_packet` 的值 [#7528](https://github.com/pingcap/tidb/pull/7528) + - 支持内建函数 `json_contains` [#7443](https://github.com/pingcap/tidb/pull/7443) + - 支持内建函数 `json_contains_path` [#7596](https://github.com/pingcap/tidb/pull/7596) + - 支持内建函数 `encode/decode` [#7622](https://github.com/pingcap/tidb/pull/7622) + - 修复一些时间相关的函数在某些情况下和 MySQL 行为不兼容的问题 [#7636](https://github.com/pingcap/tidb/pull/7636) + - 解决从字符串中解析时间类型数据的兼容性问题 [#7654](https://github.com/pingcap/tidb/pull/7654) + - 解决计算 `DateTime` 类型数据的默认值时没有考虑时区的问题 [#7655](https://github.com/pingcap/tidb/pull/7655) +- DML + - `InsertOnDuplicateUpdate` 语句设置正确的 `last_insert_id` [#7534](https://github.com/pingcap/tidb/pull/7534) + - 减少需要更新 `auto_increment_id` 计数器的情况 [#7515](https://github.com/pingcap/tidb/pull/7515) + - 优化 `Duplicate Key` 错误的报错信息 [#7495](https://github.com/pingcap/tidb/pull/7495) + - 修复 `insert...select...on duplicate key update` 问题 [#7406](https://github.com/pingcap/tidb/pull/7406) + - 支持 `LOAD DATA IGNORE LINES` 语句 [#7576](https://github.com/pingcap/tidb/pull/7576) +- DDL + - 在监控中增加 DDL Job 的类型和当前 Schema 版本的信息 [#7472](https://github.com/pingcap/tidb/pull/7472) + - 完成 `Admin Restore Table` 功能方案设计 [#7383](https://github.com/pingcap/tidb/pull/7383) + - 解决 Bit 类型的默认值超过 128 的问题 [#7249](https://github.com/pingcap/tidb/pull/7249) + - 解决 Bit 类型默认值不能为 `NULL` 的问题 [#7604](https://github.com/pingcap/tidb/pull/7604) + - 减少 DDL 队列中检查 `CREATE TABLE/DATABASE` 任务的时间间隔 [#7608](https://github.com/pingcap/tidb/pull/7608) + - 使用 `ddl/owner/resign` HTTP 接口释放 DDL Owner 并开启新一轮 Owner 选举 [#7649](https://github.com/pingcap/tidb/pull/7649) +- TiKV Go Client + - 支持 `Seek` 操作只获取 `Key` [#7419](https://github.com/pingcap/tidb/pull/7419) +- [Table Partition](https://github.com/pingcap/tidb/projects/6)（实验性） + - 解决无法使用 Bigint 类型列作为 Partition Key 的问题 [#7520](https://github.com/pingcap/tidb/pull/7520) + - 支持 Partitioned Table 添加索引过程中遇到问题回滚操作 [#7437](https://github.com/pingcap/tidb/pull/7437) + +## PD + +- 新特性 + - 支持 `GetAllStores`的接口 [#1228](https://github.com/pingcap/pd/pull/1228) + - Simulator 添加评估调度的统计信息 [#1218](https://github.com/pingcap/pd/pull/1218) +- 功能改进 + - 优化 Down Store 的处理流程，尽快地补副本 [#1222](https://github.com/pingcap/pd/pull/1222) + - 优化 Coordinator 的启动，减少重启 PD 带来的不必要调度 [#1225](https://github.com/pingcap/pd/pull/1225) + - 优化内存使用，减少 heartbeat 带来的内存开销 [#1195](https://github.com/pingcap/pd/pull/1195) + - 优化错误处理，完善日志信息 [#1227](https://github.com/pingcap/pd/pull/1227) + - pd-ctl 支持查询指定 store 的 Region 信息 [#1231](https://github.com/pingcap/pd/pull/1231) + - pd-ctl 支持查询按 version 比对的 topN 的 Region 信息 [#1233](https://github.com/pingcap/pd/pull/1233) + - pd-ctl 支持更精确的 TSO 解码 [#1242](https://github.com/pingcap/pd/pull/1242) +- Bug 修复 + - 修复 pd-ctl 使用 hot store 命令错误退出的问题 [#1244](https://github.com/pingcap/pd/pull/1244) + +## TiKV + +- 性能优化 + - 支持基于统计估算进行 Region split，减少 I/O 开销 [#3511](https://github.com/tikv/tikv/pull/3511) + - 减少部分组件的内存拷贝 [#3530](https://github.com/tikv/tikv/pull/3530) +- 功能改进 + - 增加大量内建函数下推支持 + - 增加 `leader-transfer-max-log-lag` 配置解决特定场景 leader 调度失败的问题 [#3507](https://github.com/tikv/tikv/pull/3507) + - 增加 `max-open-engines` 配置限制 `tikv-importer` 同时打开的 engine 个数 [#3496](https://github.com/tikv/tikv/pull/3496) + - 限制垃圾数据的清理速度，减少对 `snapshot apply` 的影响 [#3547](https://github.com/tikv/tikv/pull/3547) + - 对关键 Raft 消息广播 commit 信息，避免不必要的延迟 [#3592](https://github.com/tikv/tikv/pull/3592) +- Bug 修复 + - 修复新分裂 Region 的 PreVote 消息被丢弃导致的 leader 选举问题 [#3557](https://github.com/tikv/tikv/pull/3557) + - 修复 Region merge 以后 follower 的相关统计信息 [#3573](https://github.com/tikv/tikv/pull/3573) + - 修复 local reader 使用过期 Region 信息的问题 [#3565](https://github.com/tikv/tikv/pull/3565) \ No newline at end of file diff --git a/releases/21rc3.md b/releases/21rc3.md new file mode 100644 index 000000000000..04170e77ceac --- /dev/null +++ b/releases/21rc3.md @@ -0,0 +1,63 @@ +--- +title: TiDB 2.1 RC3 Release Notes +category: Releases +--- + +# TiDB 2.1 RC3 Release Notes + +2018 年 9 月 29 日，TiDB 发布 2.1 RC3 版。相比 2.1 RC2 版本，该版本对系统稳定性、兼容性、优化器以及执行引擎做了很多改进。 + +## TiDB + ++ SQL 优化器 + - 修复语句内包含内嵌的 `LEFT OUTER JOIN` 时，结果不正确的问题 [#7689](https://github.com/pingcap/tidb/pull/7689) + - 增强 `JOIN` 语句上的 predicate pushdown 优化规则 [#7645](https://github.com/pingcap/tidb/pull/7645) + - 修复 `UnionScan` 算子的 predicate pushdown 优化规则 [#7695](https://github.com/pingcap/tidb/pull/7695) + - 修复 `Union` 算子的 unique key 属性设置不正确的问题 [#7680](https://github.com/pingcap/tidb/pull/7680) + - 增强常量折叠的优化规则 [#7696](https://github.com/pingcap/tidb/pull/7696) + - 把常量传播后的 filter 是 null 的 data source 优化成 table dual [#7756](https://github.com/pingcap/tidb/pull/7756) ++ SQL 执行引擎 + - 优化事务内读请求的性能 [#7717](https://github.com/pingcap/tidb/pull/7717) + - 优化部分执行器 Chunk 内存分配的开销 [#7540](https://github.com/pingcap/tidb/pull/7540) + - 修复点查全部为 NULL 的列导致数组越界的问题 [#7790](https://github.com/pingcap/tidb/pull/7790) ++ Server + - 修复配置文件里内存配额选项不生效的问题 [#7729](https://github.com/pingcap/tidb/pull/7729) + - 添加 tidb_force_priority 系统变量用来整体设置语句执行的优先级 [#7694](https://github.com/pingcap/tidb/pull/7694) + - 支持使用 `admin show slow` 语句来获取 SLOW QUERY LOG [#7785](https://github.com/pingcap/tidb/pull/7785) ++ 兼容性 + - 修复 `information_schema.schemata` 里 `charset/collation` 结果不正确的问题 [#7751](https://github.com/pingcap/tidb/pull/7751) + - 修复 `hostname` 系统变量的值为空的问题 [#7750](https://github.com/pingcap/tidb/pull/7750) ++ 表达式 + - 内建函数 `AES_ENCRYPT/AES_DECRYPT` 支持 `init_vecter` 参数 [#7425](https://github.com/pingcap/tidb/pull/7425) + - 修复部分表达式 `Format` 结果不正确的问题 [#7770](https://github.com/pingcap/tidb/pull/7770) + - 支持内建函数 `JSON_LENGTH` [#7739](https://github.com/pingcap/tidb/pull/7739) + - 修复 unsigned integer 类型 cast 为 decimal 类型结果不正确的问题 [#7792](https://github.com/pingcap/tidb/pull/7792) ++ DML + - 修复 `INSERT … ON DUPLICATE KEY UPDATE` 语句在 unique key 更新时结果不正确的问题 [#7675](https://github.com/pingcap/tidb/pull/7675) ++ DDL + - 修复在新建的 timestamp 类型的列上新建索引时，索引值没有做时区转换的问题 [#7724](https://github.com/pingcap/tidb/pull/7724) + - 支持 enum 类型 append 新的值 [#7767](https://github.com/pingcap/tidb/pull/7767) + - 快速新建 etcd session，使网络隔离后，集群更快恢复可用 [#7774](https://github.com/pingcap/tidb/pull/7774) + +## PD + ++ 新特性 + - 添加获取按大小逆序排序的 Region 列表 API (/size) [#1254](https://github.com/pingcap/pd/pull/1254) ++ 功能改进 + - Region API 会返回更详细的信息 [#1252](https://github.com/pingcap/pd/pull/1252) ++ Bug 修复 + - 修复 PD 切换 leader 以后 `adjacent-region-scheduler` 可能会导致 crash 的问题 [#1250](https://github.com/pingcap/pd/pull/1250) + +## TiKV + ++ 性能优化 + - 优化函数下推的并发支持 [#3515](https://github.com/tikv/tikv/pull/3515) ++ 新特性 + - 添加对 Log 函数的支持 [#3603](https://github.com/tikv/tikv/pull/3603) + - 添加对 `sha1` 函数的支持 [#3612](https://github.com/tikv/tikv/pull/3612) + - 添加 `truncate_int` 函数的支持 [#3532](https://github.com/tikv/tikv/pull/3532) + - 添加 `year` 函数的支持 [#3622](https://github.com/tikv/tikv/pull/3622) + - 添加 `truncate_real` 函数的支持 [#3633](https://github.com/tikv/tikv/pull/3633) ++ Bug 修复 + - 修正时间函数相关的报错行为 [#3487](https://github.com/tikv/tikv/pull/3487) [#3615](https://github.com/tikv/tikv/pull/3615) + - 修复字符串解析成时间与 TiDB 不一致的问题 [#3589](https://github.com/tikv/tikv/pull/3589) \ No newline at end of file diff --git a/releases/rn.md b/releases/rn.md index 5c7690f5f71d..c1bbab71c894 100644 --- a/releases/rn.md +++ b/releases/rn.md @@ -7,7 +7,10 @@ category: release TiDB 历史版本发布声明如下： - - [2.1 RC1](releases/21rc1.md) + - [2.1 RC3](21rc3.md) + - [2.1 RC2](21rc2.md) + - [2.0.7](207.md) + - [2.1 RC1](21rc1.md) - [2.0.6](206.md) - [2.0.5](205.md) - [2.1 Beta](21beta.md) diff --git a/sql/character-set-configuration.md b/sql/character-set-configuration.md index 9e2c88b3aa57..56f1ae25d55a 100644 --- a/sql/character-set-configuration.md +++ b/sql/character-set-configuration.md @@ -5,6 +5,6 @@ category: user guide # 字符集配置 -目前 TiDB 还没有相应的配置来设置字符集，默认为 `utf8mb4`。 +目前，TiDB 只支持 `utf8` 字符集，相当于 MySQL 中的 `utf8mb4`。MySQL 5.7 的默认字符集为 `latin1`。关于 TiDB 与 MySQL 字符集的区别，在[默认设置的区别](mysql-compatibility.md#默认设置的区别)中有相关说明。 更多[细节](https://dev.mysql.com/doc/refman/5.7/en/charset-configuration.html)。 \ No newline at end of file diff --git a/sql/datatype.md b/sql/datatype.md index 03f4beb06782..be8b4ba15367 100644 --- a/sql/datatype.md +++ b/sql/datatype.md @@ -63,7 +63,7 @@ BIGINT[(M)] [UNSIGNED] [ZEROFILL] | 语法元素 | 说明 | | ---- | --------| -| M | 类型长度，可选的 | +| M | 类型显示宽度，可选 | | UNSIGNED | 无符号数，如果不加这个标识，则为有符号数 | | ZEROFILL | 补零标识，如果有这个标识，TiDB 会自动给类型增加 UNSIGNED 标识，但是没有做补零的操作 | @@ -174,8 +174,8 @@ TIME[(fsp)] > 时间。范围是`-838:59:59.000000`到`838:59:59.000000`。以`HH:MM:SS[.fraction]`格式显示 TIME 值。 fsp 参数是表示秒精度，取值范围为：0-6。默认值取 0。 -YEAR[(2|4)] -> 两位或四位格式的年。默认是四位格式。在四位格式中，允许的值是 1901 到 2155 和 0000。在两位格式中，允许的值是 70 到 69，表示从 1970 年到 2069 年。 +YEAR[(4)] +> 四位格式的年。允许的值是 1901 到 2155 和 0000。 ``` ## 字符串类型 diff --git a/sql/information-functions.md b/sql/information-functions.md index 6aeb95c516e0..73d326f40e57 100644 --- a/sql/information-functions.md +++ b/sql/information-functions.md @@ -21,4 +21,4 @@ TiDB 中信息函数的使用方法与 MySQL 基本一致，详情参见：[Info | [`SYSTEM_USER()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_system-user) | 与 USER() 同义 | | [`USER()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_user) | 返回客户端提供的用户名和主机名 | | [`VERSION()`](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_version) | 返回当前 MySQL 服务器的版本信息 | -| `TIDB_VERSION` | 返回当前 TiDB 服务器的版本信息 | +| `TIDB_VERSION()` | 返回当前 TiDB 服务器的版本信息 | diff --git a/sql/json-functions-generated-column.md b/sql/json-functions-generated-column.md index cb6bc14b861c..9fc2d0ca79d3 100644 --- a/sql/json-functions-generated-column.md +++ b/sql/json-functions-generated-column.md @@ -65,10 +65,14 @@ SELECT JSON_EXTRACT(@person, '$.friends[2].name'); -- gets NULL * [JSON_REMOVE](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-remove) * [JSON_TYPE](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-type) * [JSON_UNQUOTE](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-unquote) +* [JSON_MERGE](https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-merge) +* [JSON_CONTAINS](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains) +* [JSON_CONTAINS_PATH](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-contains-path) +* [JSON_LENGTH](https://dev.mysql.com/doc/refman/5.7/en/json-attribute-functions.html#function_json-length) 直接从名字上，我们便能得出这些函数的大致用途，而且它们的语义也与 MySQL 5.7 完全一致，因此，想要查询它们具体的用法，我们可以直接查阅 MySQL 5.7 的[相关文档](https://dev.mysql.com/doc/refman/5.7/en/json-functions.html)。MySQL 5.7 的用户可以无缝迁移至 TiDB。 -熟悉 MySQL 5.7 的用户会发现，TiDB 尚未完全支持所有 MySQL 5.7 中的 JSON 函数。这是因为我们的一期目标是能够提供完备的 **MySQL X Plugin** 支持即可，而这已经涵盖大部分常用的 JSON 增删改查的功能了。如有需要，我们会继续完善对其他函数的支持。 +熟悉 MySQL 5.7 的用户会发现，TiDB 尚未完全支持 MySQL 5.7 中所有的 JSON 函数。通过 [TiDB #7546](https://github.com/pingcap/tidb/issues/7546) 可查看 TiDB 中添加新函数的进度。 ## 使用生成列对 JSON 建索引 diff --git a/sql/literal-values.md b/sql/literal-values.md index c2494ceba361..4e34d0759463 100644 --- a/sql/literal-values.md +++ b/sql/literal-values.md @@ -60,7 +60,7 @@ SELECT _utf8'some text'; - \\r: 回车符 - \\t: tab 符（制表符） - \\z: ASCII 26 (Ctrl + Z) -- \\\: 反斜杠 \\ +- \\\\: 反斜杠 \\ - \\%: \% - \\_: \_ diff --git a/sql/mysql-compatibility.md b/sql/mysql-compatibility.md index 81c6c98f64d4..189de50550ac 100644 --- a/sql/mysql-compatibility.md +++ b/sql/mysql-compatibility.md @@ -13,17 +13,21 @@ TiDB 支持包括跨行事务、JOIN 及子查询在内的绝大多数 MySQL 5.7 一些 MySQL 语法在 TiDB 中可以解析通过，但是不会做任何后续的处理，例如 Create Table 语句中 `Engine` 以及 `Partition` 选项，都是解析并忽略。更多兼容性差异请参考具体的文档。 - ## 不支持的特性 -* 存储过程 +* 存储过程与函数 * 视图 * 触发器 +* 事件 * 自定义函数 * 外键约束 * 全文索引 * 空间索引 -* 非 UTF8 字符集 +* 非 `utf8` 字符集 +* 增加主键 +* 删除主键 +* SYS schema +* MySQL 追踪优化器 ## 与 MySQL 有差异的特性 @@ -31,25 +35,24 @@ TiDB 支持包括跨行事务、JOIN 及子查询在内的绝大多数 MySQL 5.7 TiDB 的自增 ID (Auto Increment ID) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。 -> **注意：** -> -> 在集群中有多个 tidb-server 实例时，如果表结构中有自增 ID，建议不要混用缺省值和自定义值。否则在如下情况下会遇到问题： -> -> 假设有这样一个带有自增 ID 的表： -> -> ``` -> create table t(id int unique key auto_increment, c int); -> ``` -> -> TiDB 实现自增 ID 的原理是每个 tidb-server 实例缓存一段 ID 值用于分配（目前会缓存 30000 个 ID），用完这段值再去取下一段。 - -> 假设集群中有两个 tidb-server 实例 A 和 B（A 缓存 [1,30000] 的自增 ID，B 缓存 [30001,60000] 的自增 ID）， -> -> 依次执行操作： -> -> 1. 客户端向 B 插入一条将 `id` 设置为 1 的语句 `insert into t values (1, 1)`，并执行成功。 -> 2. 客户端向 A 发送 Insert 语句 `insert into t (c) (1)`，这条语句中没有指定 `id` 的值，所以会由 A 分配，当前 A 缓存了 [1, 30000] 这段 ID，所以会分配 1 为自增 ID 的值，并把本地计数器加 1。而此时数据库中已经存在 `id` 为 1 的数据，最终返回 `Duplicated Error` 错误。 +在集群中有多个 tidb-server 实例时，如果表结构中有自增 ID，建议不要混用缺省值和自定义值，否则在如下情况下会遇到问题。 + +假设有这样一个带有自增 ID 的表： + +```sql +create table t(id int unique key auto_increment, c int); +``` + +TiDB 实现自增 ID 的原理是每个 tidb-server 实例缓存一段 ID 值用于分配（目前会缓存 30000 个 ID），用完这段值再去取下一段。 + +假设集群中有两个 tidb-server 实例 A 和 B（A 缓存 [1,30000] 的自增 ID，B 缓存 [30001,60000] 的自增 ID），依次执行如下操作： +1. 客户端向 B 插入一条将 `id` 设置为 1 的语句 `insert into t values (1, 1)`，并执行成功。 +2. 客户端向 A 发送 Insert 语句 `insert into t (c) (1)`，这条语句中没有指定 `id` 的值，所以会由 A 分配，当前 A 缓存了 [1, 30000] 这段 ID，所以会分配 1 为自增 ID 的值，并把本地计数器加 1。而此时数据库中已经存在 `id` 为 1 的数据，最终返回 `Duplicated Error` 错误。 + +### Performance schema + +Performance schema 表在 TiDB 中返回结果为空。TiDB 使用 [Prometheus 和 Grafana](https://pingcap.com/docs/op-guide/monitor/#use-prometheus-and-grafana) 来监测性能指标。 ### 内建函数 @@ -89,9 +92,18 @@ TiDB 实现了 F1 的异步 Schema 变更算法，DDL 执行过程中不会阻 - 支持 LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE} 语法，但是不做任何事情（pass through）。 - 不支持对enum类型的列进行修改 -### 事务 +### 事务模型 + TiDB 使用乐观事务模型，在执行 Update、Insert、Delete 等语句时，只有在提交过程中才会检查写写冲突，而不是像 MySQL 一样使用行锁来避免写写冲突。所以业务端在执行 SQL 语句后，需要注意检查 commit 的返回值，即使执行时没有出错，commit的时候也可能会出错。 +### 大事务 + +由于 TiDB 分布式两阶段提交的要求，修改数据的大事务可能会出现一些问题。因此，TiDB 特意对事务大小设置了一些限制以减少这种影响： + +* 每个键值对不超过 6MB +* 键值对的总数不超过 300,000 +* 键值对的总大小不超过 100MB + ### Load data + 语法： @@ -100,6 +112,7 @@ TiDB 使用乐观事务模型，在执行 Update、Insert、Delete 等语句时 LOAD DATA LOCAL INFILE 'file_name' INTO TABLE table_name {FIELDS | COLUMNS} TERMINATED BY 'string' ENCLOSED BY 'char' ESCAPED BY 'char' LINES STARTING BY 'string' TERMINATED BY 'string' + IGNORE n LINES (col_name ...); ``` @@ -109,14 +122,39 @@ TiDB 使用乐观事务模型，在执行 Update、Insert、Delete 等语句时 TiDB 在执行 load data 时，默认每 2 万行记录作为一个事务进行持久化存储。如果一次 load data 操作插入的数据超过 2 万行，那么会分为多个事务进行提交。如果某个事务出错，这个事务会提交失败，但它前面的事务仍然会提交成功，在这种情况下一次 load data 操作会有部分数据插入成功，部分数据插入失败。而 MySQL 中会将一次 load data 操作视为一个事务，如果其中发生失败情况，将会导致整个 load data 操作失败。 +### 存储引擎 + +出于兼容性原因，TiDB 支持使用备用存储引擎创建表的语法。元数据命令将表描述为 InnoDB 存储引擎： + +```sql +mysql> CREATE TABLE t1 (a INT) ENGINE=MyISAM; +Query OK, 0 rows affected (0.14 sec) + mysql> SHOW CREATE TABLE t1\G +*************************** 1. row *************************** + Table: t1 +Create Table: CREATE TABLE `t1` ( + `a` int(11) DEFAULT NULL +) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin +1 row in set (0.00 sec) +``` + +从架构上讲，TiDB 确实支持类似 MySQL 的存储引擎抽象，在启动 TiDB（通常是 `tikv`）时 [`--store`](server-command-option.md#--store) 选项指定的引擎中创建用户表。 + +### EXPLAIN + +TiDB 的 `EXPLAIN` 命令返回的查询执行计划的输出与 MySQL 不同。更多内容参见 [理解 TiDB 执行计划](understanding-the-query-execution-plan.md)。 + ### 默认设置的区别 + 默认字符集不同： - + MySQL 5.7 中使用 `latin1`（MySQL 8.0 中使用 `UTF-8`） - + TiDB 使用 `utf8mb4` + + TiDB 中为 `utf8`，相当于 MySQL 的 `utf8mb4` + + MySQL 5.7 中为 `latin1`，但在 MySQL 8.0 中修改为 `utf8mb4` + 默认排序规则不同： + MySQL 5.7 中使用 `latin1_swedish_ci` + TiDB 使用 `binary` ++ 默认 SQL mode 不同： + + TiDB 中为 `STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION` + + MySQL 中为 `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` + `lower_case_table_names` 的默认值不同： + TiDB 中该值默认为 2，并且目前 TiDB 只支持设置该值为 2 + MySQL 中默认设置： diff --git a/sql/slow-query.md b/sql/slow-query.md index fe2e256932ae..acd008d893c0 100644 --- a/sql/slow-query.md +++ b/sql/slow-query.md @@ -11,7 +11,7 @@ category: user guide 通过在 TiDB 的日志文件上 grep `SLOW_QUERY` 这个关键字，可以得到执行时间超过 [slow-threshold](../op-guide/tidb-config-file.md#slow-threshold) 的语句日志。 -`slow-threshold` 可以通过配置文件修改，默认是 300ms。如果配置了 [slow-query-file](../op-guide/tidb-config-file.md#slow-query-file), 慢查询日志会全部写在这个文件里。 +`slow-threshold` 可以通过配置文件修改，默认是 300ms。如果配置了 [slow-query-file](../op-guide/tidb-config-file.md#slow-query-file)，慢查询日志会全部写在这个文件里。 ### 示例 @@ -35,7 +35,7 @@ sql:select count(c) from sbtest1 use index (k_1) #### wait_time -表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 coprocessor 线程数是有限的，当所有的 coprocessor 线程都在工作的时候，请求会排队，当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加。 +表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 Coprocessor 线程数是有限的，当所有的 Coprocessor 线程都在工作的时候，请求会排队，当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加。 #### backoff_time @@ -43,15 +43,15 @@ sql:select count(c) from sbtest1 use index (k_1) #### request_count -表示这个语句发送的 coprocessor 请求的数量。 +表示这个语句发送的 Coprocessor 请求的数量。 #### total_keys -表示 coprocessor 扫过的 key 的数量 +表示 Coprocessor 扫过的 key 的数量 #### processed_keys -表示 coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 mvcc 的旧版本和 mvcc delete 标记。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。 +表示 Coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 MVCC 的旧版本。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。 #### succ @@ -88,8 +88,3 @@ sql:select count(c) from sbtest1 use index (k_1) ### 定位问题语句的方法 并不是所有 SLOW_QUERY 的语句都是有问题的。会造成集群整体压力增大的，是那些 process_time 很大的语句。wait_time 很大，但 process_time 很小的语句通常不是问题语句，是因为被问题语句阻塞，在执行队列等待造成的响应时间过长。 - - - - - diff --git a/sql/string-functions.md b/sql/string-functions.md index de7cbe354f0b..b9d5f20817e6 100644 --- a/sql/string-functions.md +++ b/sql/string-functions.md @@ -53,8 +53,6 @@ category: user guide | [`FORMAT()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_format) | 返回指定小数位数格式的数字 | | [`ORD()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_ord) | 返回参数中最左字符的字符代码 | | [`QUOTE()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_quote)                         | 引用一个字符串，返回一个在 SQL 语句中可用作正确转义的数据值的结果                                                                                           | -| [`SOUNDEX()`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_soundex) | 返回一个 soundex 字符串 | -| [`SOUNDS LIKE`](https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#operator_sounds-like)               | 按发音比较字符串   | ## 字符串比较函数 @@ -63,7 +61,6 @@ category: user guide | [`LIKE`](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_like) | 进行简单模式匹配 | | [`NOT LIKE`](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#operator_not-like) | 否定简单模式匹配 | | [`STRCMP()`](https://dev.mysql.com/doc/refman/5.7/en/string-comparison-functions.html#function_strcmp) | 比较两个字符串 | -| [`MATCH`](https://dev.mysql.com/doc/refman/5.7/en/fulltext-search.html#function_match) | 执行全文搜索 | ## 正则表达式 diff --git a/sql/tidb-specific.md b/sql/tidb-specific.md index 32464112cd64..a90fc830c435 100644 --- a/sql/tidb-specific.md +++ b/sql/tidb-specific.md @@ -318,7 +318,7 @@ TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用 这个变量用来设置是否禁用显式事务自动重试，设置为 1 时，不会自动重试，如果遇到冲突需要在应用层重试。 是否需要禁用自动重试，请参考[自动重试的风险](./transaction-isolation.md#乐观事务注意事项) -## tidb_enable_table_partition +### tidb_enable_table_partition 作用域：SESSION @@ -326,7 +326,7 @@ TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用 这个变量用来设置是否开启 TABLE PARTITION 特性。 -## tidb_backoff_lock_fast +### tidb_backoff_lock_fast 作用域：SESSION | GLOBAL @@ -334,7 +334,7 @@ TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用 这个变量用来设置读请求遇到锁的 backoff 时间。 -## tidb_ddl_reorg_worker_cnt +### tidb_ddl_reorg_worker_cnt 作用域: SESSION | GLOBAL @@ -342,11 +342,11 @@ TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用 这个变量用来设置 DDL 操作 re-organize 阶段的并发度。 -## tidb_ddl_reorg_priority +### tidb_ddl_reorg_priority 作用域：SESSION | GLOBAL -默认值：PRIORITY_NORMAL +默认值：PRIORITY_LOW 这个变量用来设置 `ADD INDEX` 操作 re-organize 阶段的执行优先级，可设置为 PRIORITY_LOW/PRIORITY_NORMAL/PRIORITY_HIGH。 diff --git a/sql/time-zone.md b/sql/time-zone.md index 1657e20758ad..d72d7c4d5dc2 100644 --- a/sql/time-zone.md +++ b/sql/time-zone.md @@ -5,7 +5,12 @@ category: user guide # 时区支持 -TiDB 使用的时区由 `time_zone` 全局变量和 session 变量决定。`time_zone` 的初始值是机器当前的系统时区 'SYSTEM'。 +TiDB 使用的时区由 `time_zone` 全局变量和 session 变量决定。`time_zone` 的默认值是 `System`，`System` 对应的实际时区在 `TiDB` 集群 bootstrap 初始化时设置。具体逻辑如下: + +* 优先使用 `TZ` 环境变量 +* 如果失败，则从 `/etc/localtime` 的实际软链地址提取。 +* 如果上面两种都失败则使用 `UTC` 作为系统时区。 + 在运行过程中可以修改全局时区： diff --git a/sql/transaction-isolation.md b/sql/transaction-isolation.md index 8ddcc901272a..045ac220cee0 100644 --- a/sql/transaction-isolation.md +++ b/sql/transaction-isolation.md @@ -16,25 +16,13 @@ sql 92标准定义了4种隔离级别，读未提交、读已提交、可重复 | Repeatable read | Not possible | Not possible | Not possible in TiDB | Possible | | Serializable | Not possible | Not possible | Not possible | Not possible | -TiDB 实现了其中的两种：读已提交和可重复读。 +TiDB 实现了其中的可重复读。 TiDB 使用 [Percolator 事务模型](https://research.google.com/pubs/pub36726.html)，当事务启动时会获取全局读时间戳，事务提交时也会获取全局提交时间戳，并以此确定事务的执行顺序，如果想了解 TiDB 事务模型的实现可以详细阅读以下两篇文章：[TiKV 的 MVCC (Multi-Version Concurrency Control) 机制](https://pingcap.com/blog-cn/mvcc-in-tikv/)，[Percolator 和 TiDB 事务算法](https://pingcap.com/blog-cn/percolator-and-txn/)。 -可以通过以下命令设置 session 或者 global 的事务的隔离级别： - -``` -SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL [read committed|repeatable read] -``` - -如果不使用 session 或者 global 关键字，以下这条语句只会对下一个执行的事务生效，不会对整个会话或者全局生效： - -``` -SET TRANSACTION ISOLATION LEVEL [read committed|repeatable read] -``` - ## 可重复读 -可重复读是 TiDB 的默认隔离级别，当事务隔离级别为可重复读时，只能读到该事务启动时已经提交的其他事务修改的数据，未提交的数据或在事务启动后其他事务提交的数据是不可见的。对于本事务而言，事务语句可以看到之前的语句做出的修改。 +当事务隔离级别为可重复读时，只能读到该事务启动时已经提交的其他事务修改的数据，未提交的数据或在事务启动后其他事务提交的数据是不可见的。对于本事务而言，事务语句可以看到之前的语句做出的修改。 对于运行于不同节点的事务而言，不同事务启动和提交的顺序取决于从 PD 获取时间戳的顺序。 @@ -60,12 +48,6 @@ commit; | MySQL 可重复读隔离级别在更新时并不检验当前版本是否可见，也就是说，即使该行在事务启动后被更新过，同样可以继续更新。这种情况在 TiDB 会导致事务回滚并后台重试，重试最终可能会失败，导致事务最终失败，而 MySQL 是可以更新成功的。 MySQL 的可重复读隔离级别并非 snapshot 隔离级别，MySQL 可重复读隔离级别的一致性要弱于 snapshot 隔离级别，也弱于 TiDB 的可重复读隔离级别。 -## 读已提交 - -读已提交隔离级别和可重复读隔离级别不同，它仅仅保证不能读到未提交事务的数据，需要注意的是，事务提交是一个动态的过程，因此读已提交隔离级别可能读到某个事务部分提交的数据。 - -不推荐在有严格一致要求的数据库中使用读已提交隔离级别。 - ## 事务重试 对于 insert/delete/update 操作，如果事务执行失败，并且系统判断该错误为可重试，会在系统内部自动重试事务。 diff --git a/tools/new-tidb-binlog.md b/tools/new-tidb-binlog.md new file mode 100644 index 000000000000..f3439f565b1c --- /dev/null +++ b/tools/new-tidb-binlog.md @@ -0,0 +1,155 @@ +--- +title: 新版 TiDB-Binlog 部署方案 +category: advanced +--- + +# 新版 TiDB-Binlog 部署方案 + +> 新版 TiDB-Binlog 尚未发布正式版，本文档用于测试环境部署。 + +## 使用 tidb-ansible 部署 TiDB-Binlog +### 下载 tidb-ansible + +以 tidb 用户登录中控机并进入 `/home/tidb` 目录，使用以下命令 tidb-ansible `new-tidb-binlog` 分支，默认的文件夹名称为 tidb-ansible。 + +``` +$ git clone -b new-tidb-binlog https://github.com/pingcap/tidb-ansible.git +``` + +### 部署 pump +#### 修改 tidb-ansible/inventory.ini 文件 + +1. 设置 `enable_binlog = True`，表示 TiDB 集群开启 binlog。 + +``` +## binlog trigger +enable_binlog = True +``` + +2. 为 `pump_servers` 主机组添加部署机器 IP。 + +``` +## Binlog Part +[pump_servers] +172.16.10.72 +172.16.10.73 +172.16.10.74 +``` + +默认 pump 保留 5 天数据，如需修改可修改 `tidb-ansible/conf/pump.yml` 文件中 `gc` 变量值，并取消注释，如修改为 7。 + +``` +global: + # a integer value to control expiry date of the binlog data, indicates for how long (in days) the binlog data would be stored. + # must bigger than 0 + gc: 7 +``` + +请确保部署目录有足够空间存储 binlog，详见：[部署目录调整](../op-guide/ansible-deployment.md#部署目录调整)，也可为 pump 设置单独的部署目录。 + +``` +## Binlog Part +[pump_servers] +pump1 ansible_host=172.16.10.72 deploy_dir=/data1/pump +pump2 ansible_host=172.16.10.73 deploy_dir=/data1/pump +pump3 ansible_host=172.16.10.74 deploy_dir=/data1/pump +``` + +#### 部署并启动 TiDB 集群。 + +使用 ansible 部署 TiDB 集群的具体方法参考 [TiDB Ansible 部署方案](../op-guide/ansible-deployment.md)，开启 binlog 后默认会部署和启动 pump 服务。 + +#### 查看 pump 服务状态 + +使用 binlogctl 查看 pump 服务状态，pd-urls 参数请替换为集群 PD 地址，结果 State 为 online 表示 pump 启动成功。 + +``` +$ cd /home/tidb/tidb-ansible +$ resources/bin/binlogctl -pd-urls=http://172.16.10.72:2379 -cmd pumps +2018/09/21 16:45:54 nodes.go:46: [info] pump: &{NodeID:ip-172-16-10-72:8250 Addr:172.16.10.72:8250 State:online IsAlive:false Score:0 Label: MaxCommitTS:0 UpdateTS:403051525690884099} +2018/09/21 16:45:54 nodes.go:46: [info] pump: &{NodeID:ip-172-16-10-73:8250 Addr:172.16.10.73:8250 State:online IsAlive:false Score:0 Label: MaxCommitTS:0 UpdateTS:403051525703991299} +2018/09/21 16:45:54 nodes.go:46: [info] pump: &{NodeID:ip-172-16-10-74:8250 Addr:172.16.10.74:8250 State:online IsAlive:false Score:0 Label: MaxCommitTS:0 UpdateTS:403051525717360643} +``` + +### 部署 drainer +#### 获取 initial_commit_ts + +#### 修改 tidb-ansible/inventory.ini 文件 + +为 `drainer_servers` 主机组添加部署机器 IP，initial_commit_ts 请设置为获取的 initial_commit_ts，仅用于 drainer 第一次启动。 + +1. 以下游为 mysql 为例，别名为 `drainer_mysql`。 + +``` +[drainer_servers] +drainer_mysql ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" +``` + +2. 以下游为 pb 为例，别名为 `drainer_pb`。 + +``` +[drainer_servers] +drainer_pb ansible_host=172.16.10.71 initial_commit_ts="402899541671542785" +``` + +#### 修改配置文件 + +1. 以下游为 mysql 为例 + +``` +$ cd /home/tidb/tidb-ansible/conf +$ cp drainer.toml drainer_mysql_drainer.toml +$ vi drainer_mysql_drainer.toml +``` + +db-type 设置为 "mysql", 配置下游 mysql 信息。 + +``` +# downstream storage, equal to --dest-db-type +# valid values are "mysql", "pb", "tidb", "flash", "kafka" +db-type = "mysql" + +# the downstream mysql protocol database +[syncer.to] +host = "172.16.10.72" +user = "root" +password = "123456" +port = 3306 +# Time and size limits for flash batch write +# time-limit = "30s" +# size-limit = "100000" +``` + +2. 以下游为 pd 为例 + +``` +$ cd /home/tidb/tidb-ansible/conf +$ cp drainer.toml drainer_pd_drainer.toml +$ vi drainer_pd_drainer.toml +``` + +db-type 设置为 "pd"。 + +``` +# downstream storage, equal to --dest-db-type +# valid values are "mysql", "pb", "tidb", "flash", "kafka" +db-type = "pd" + +# Uncomment this if you want to use pb or sql as db-type. +# Compress compresses output file, like pb and sql file. Now it supports "gzip" algorithm only. +# Values can be "gzip". Leave it empty to disable compression. +[syncer.to] +compression = "" +``` + +#### 部署 drainer + +``` +$ ansible-playbook deploy_drainer.yml +``` + +#### 启动 drainer + +``` +$ ansible-playbook start_drainer.yml +``` diff --git a/tools/pd-control.md b/tools/pd-control.md index a19d3ff61fc5..0999e4fc6bdd 100644 --- a/tools/pd-control.md +++ b/tools/pd-control.md @@ -84,7 +84,7 @@ export PD_ADDR=http://127.0.0.1:2379 } ``` -### config [show | set \ \] +### config [show | set