TiDB简明教程

2019-11-01 本文已影响0人 super_pcm

本文针对的TiDB版本为3.0，不一定适用于其他版本，可以作为参考

1. TiDB简介

Tidb是个高度兼容MySQL的分布式数据库，详细介绍见官网介绍.这里概括下TiDB拥有的几个特性：

高度兼容 MySQL
水平弹性扩展
分布式事务
真正金融级高可用
一站式 HTAP 解决方案
云原生 SQL 数据库

其中TiDB的核心特性是：水平扩展、高可用

2. TIDB整体结构

TiDB的架构图如下:

image

其中的TiDB、TiKV、PD是核心组件；TiSpark是为了解决复杂OLAP的组件。具体的介绍可以参考官网。

3. TIDB的安装部署

要部署一套分布式的数据库系统可不简单，特别像是TiDB这种有多个组件要部署多个节点的系统。TiDB官方建议并提供了TiDB Ansible来安装部署TiDB集群，具体的安装参考官网。
这里特别说明一点，如果你是在测试环境下安装部署的话，可以修改tidb-ansible目录下的 group_vars/all.yml 文件中的参数，这样就不会对你的硬件有太多的要求了：

dev_mode: True

4. TIDB的监控

使用TiDB-Ansible安装TiDB集群默认会安装一套Prometheus+Grafana的监控；我们使用Prometheus+Grafana对TIDB做监控。监控的架构图如下：

TiDB监控架构图

其中我们最需要关注的是 overview面板，其他的面板我们也要熟悉，下面是一些面板的介绍链接。

监控对于TIDB来说非常重要，建议单独对Prometheus以及Grafana深入学习。

5. 数据迁移

在多数场合下，我们使用TiDB是将其作为MySQL的一个补充。有些大表我们不希望通过MySQL的分库分表技术来处理，因为这样除了会增加技术及维护的难度之外，分库分表还会造成大量的数据孤岛，对我们分析数据也会造成很大的困扰。那我们用TiDB来存放什么数据呢？一是MySQL存放不下的大表，二是MySQL分库分表之后汇合的大表。在这里我们可以看到，我们的数据源都是与MySQL相关的，这里要说的是如何把数据从MySQL迁移到TiDB中去。

针对全量数据，我们可以使用Mydumper+Loader工具进行迁移，具体使用方法可以参考官网。
针对增量数据，我们可以使用syncer工具进行同步，同步的原理和MySQL的主从同步类似，具体使用方法参考官网
针对CSV文件，我们与MySQL操作一样，直接导入，使用方法参考官网

上面三个方法都是针对比较旧的方法了，目前使用得更多的是TIDB的DM工具。DM工具融合了Mydumper+Loader+syncer在里面，可以轻松做到全量数据的备份恢复以及增量数据的同步。

DM集群的部署及官方手册请参考官网教程，这里附上两个的链接：

如果你不想部署这么大的一个DM集群，那么你可以使用DM的二进制包进行简单的部署，使用方法可以参考官方文档。要注意的就是这样部署二进制包是没有Prometheus+Grafana的监控的，需要自行把DM的监控项目添加到Prometheus+Grafana中去。大概的流程如下：

在Prometheus中添加DM的监控项，内容大致如下：

  - job_name: "dm"
    static_configs:
    - targets:
      - '192.168.113.20:8262'

在Grafana中导入json模板，json在dm-ansible的scripts目录下（dm-ansible目录就是DM集群部署最开始下载的那个配置内容包）

在数据量特别大的时候，我们使用DM工具来进行迁移和同步的话效率太低了，这时候就需要使用TIDB Lighting了。这个组件我没有使用过，没有发言权。这里附上官网的连接

6. TIDB的运维

到了这一步，我们的TiDB上终于有了数据，这时候有必要说下怎么对TIDB进行运维了。

6.1 常用的TiDB运维操作

TiDB集群的操作都是通过Ansible来操作的，如果不懂Ansible的，请自己单独对Ansible进行学习.

启动集群

此操作会按顺序启动整个 TiDB 集群所有组件（包括 PD、TiDB、TiKV 等组件和监控组件）。

ansible-playbook start.yml

关闭集群

此操作会按顺序关闭整个 TiDB 集群所有组件（包括 PD、TiDB、TiKV 等组件和监控组件）。

ansible-playbook stop.yml

清除集群数据

此操作会关闭 TiDB、Pump、TiKV、PD 服务，并清空 Pump、TiKV、PD 数据目录。

ansible-playbook unsafe_cleanup_data.yml

销毁集群

此操作会关闭集群，并清空部署目录，若部署目录为挂载点，会报错，可忽略。

ansible-playbook unsafe_cleanup.yml

如果只针对某个组件进行操作可以加上 --tag参数，比如我只停止kv组件

ansible-playbook stop.yml --tags=tikv

如果只对某一个节点进行操作则使用 -l 参数，具体使用方法同上。

6.2 备份与恢复

备份与恢复其实前面已经说过了，就是迁移的过程。我们可以使用Mydumper来对TiDB进行全量的备份，使用Loader工具对TiDB进行全量的恢复。具体的使用方法参考前面提到的官方链接，这里针对Mydumper特别说明下。

如果 mydumper 出现以下报错：

** (mydumper:27528): CRITICAL **: 13:25:09.081: Could not read data from testSchema.testTable: GC life time is shorter than transaction duration, transaction starts at 2019-08-05 21:10:01.451 +0800 CST, GC safe point is 2019-08-05 21:14:53.801 +0800 CST

上面的提示说是读取不到对应的表信息，建议调整GC的时间。由于TIDB使用的是乐观锁和MVCC，其中MVCC的版本默认保存10分钟。如果你的mydumper操作超过10分钟的话，那就有可能会出现上面的情况，这时候需要手动调大GC的时间。

##查询GC设置的值
SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time';

##设置GC的值为720h
update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';

执行 mydumper 命令后，将 TiDB 集群的 GC 值恢复到初始值。

update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time';

6.3 定位慢查询

慢查询在数据库里面几乎是不可避免的，TiDB的慢查询定位方法可以参考MySQL。也就是通过分析慢查询日志，现在TiDB的慢查询日志格式与MySQL一致，可以使用同样的方法慢查询日志进行分析了（比如使用pt-query-diges）。

与MySQL不同的是，TiDB还提供了一个内存表可以直接查询慢查询的情况，这给开发和运维人员提供了很大的便利。用户可通过查询 INFORMATION_SCHEMA.SLOW_QUERY 表来查询慢查询日志中的内容，表中列名和慢日志中字段名一一对应。
例如我要查询用户的慢查询，我可以这么写SQL。

select query_time, query
from information_schema.slow_query
where is_internal = false  -- 排除 TiDB 内部的慢查询 SQL
order by query_time desc
limit 20;

此外，还可以使用admin show slow命令来查询慢查询，这里需要说明的是TiDB认为的慢查询是超过 300毫秒的查询，其中包括大量的内部查询。

慢查询的定位方法具体可以参考官网

7. TiDB的扩容缩容

在最开始，我们有说到TiDB的一个最大的特点是水平拓展，几乎所有的组件都可以很方便地水平拓展，这也是与MySQL集群方案的一个很大的区别。计算能力不够，我们可以增加TiDB节点；存储能力不够，我们可以增加TiKV节点；调度能力不足，我们可以增加PD节点。

TiDB具体的扩容和缩容的方法这里不说，具体可以参考官网。这里要特别说明：

TiKV默认是使用3副本的，意思是要让TiKV能够正常运行，TiKV的节点数不能小于3个。

8. TIDB的升级

TiDB版本的更新迭代非常快，每次大版本的更新都会大来新的功能以及性能的提升，小版本的更新也通常会修复一些问题，所以我们使用TiDB，不建议使用旧版本。目前TiDB的最新版本为3.0.5，在生产环境下官方也建议使用该版本。

关于TiDB的升级方法，这里不做介绍，具体参见官方文档。这里要注意一点：

TiDB这几个组件中升级耗时最长的是TiKV，主要耗时在region的转移。如果在升级的过程中有大量的写入操作，这会大大增加这一步的耗时。所以建议在业务低峰的时候进行升级，有DM同步的可以暂停同步任务，升级完成后再恢复。

9. TIDB生态工具的使用

TiDB生态工具包含了我们上面提到的Mydumper，Loader，Syncer，Data Migration(DM)，TiDB Lighting，除此之外，还有PD Control，TiKV Control，TiDB Control等。这里我只对PD Control做一个简单的介绍，因为这个工具在我们使用TiDB中要经常用到的。

PD Control默认在tidb ansible下的resources/bin目录下，打开方式比较简单，只要指定pd的地址即可，如：

单命令模式：

./pd-ctl -u http://127.0.0.1:2379 store

交互模式：

./pd-ctl -u http://127.0.0.1:2379 -i

使用PD Control工具对我们设置TiDB的配置以及查看TiDB的运行状况有很大帮助，在排错或者扩缩容的时候我们都需要使用到PD Control工具。下面介绍一些常用的命令：

显示集群的基本信息

cluster

显示所有的配置信息

config show all

显示kv节点的信息

store

查看最大的两个region

region topsize 2

把region id为2001的region leader转移到id 为1 的kv节点上（手动迁移region leader）

operator add  transfer-leader 2001 1

查看PD中运行的调度器

scheduler show

更多的用法请参考官网