TiDB简明教程

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

1. TiDB简介

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

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

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

2. TIDB整体结构

TiDB的架构图如下:

TiDB简明教程_第1张图片
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简明教程_第2张图片
TiDB监控架构图

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

  • Overview 面板重要监控指标详解
  • TiDB 重要监控指标详解
  • PD 重要监控指标详解
  • TiKV 重要监控指标详解

监控对于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的官方文档手册

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

  1. 在Prometheus中添加DM的监控项,内容大致如下:
  - job_name: "dm"
    static_configs:
    - targets:
      - '192.168.113.20:8262'
  1. 在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

更多的用法请参考官网

10.必须要看的几个博客

10.1 TiDB原理相关

  • 三篇文章了解 TiDB 技术内幕 - 说存储
  • 三篇文章了解 TiDB 技术内幕 - 说计算
  • 三篇文章了解 TiDB 技术内幕 - 谈调度

10.2 最佳实践相关

  • TiDB 最佳实践系列(一)高并发写入常见热点问题及规避方法
  • TiDB 最佳实践系列(二)PD 调度策略最佳实践
  • TiDB 最佳实践系列(三)乐观锁事务
  • TiDB 最佳实践系列(四)海量 Region 集群调优
  • TiDB Best Practice

你可能感兴趣的:(TiDB简明教程)