TiDB环境搭建与基础功能验证

Posted 2021-05-23 数通畅联

在实际的项目实施过程中，很多企业都会提出对大数据的要求，特别是一些大型企业，业务数据相对较多，历史数据比较复杂，为了实现对企业业务的整体管控需求，进行信息化建设时必然会提出大数据的需求，这就要求信息化系统具备大数据管理能力，那么系统在数据存储、数据读写等方面就要有比较好的性能。在以往项目中，一般都是采用数据库的主从结构、读写分离、集群部署等方式满足对于大数据量的处理需求，但是对于mysql数据库来说，本身在大数据量上就存在限制，因此必须找到一种方案实现大数据量的支持。

由于公司产品都是采用MySQL数据库，为了降低数据库切换和学习的成本，需要一个能和MySQL良好兼容的方案，TiDB由于其本身100%支持MySQL5.7协议，所以无论是从使用效果还是学习成本来说，TiDB都是最好的选择。本次针对TiDB数据库进行了初步的技术预研，部署了基础的数据库环境，并测试了相关功能。

1总体说明

本次主要是对TiDB产品进行初步技术预研，包括TiDB的基础环境部署，验证常用的SQL语句，并实现从MySQL和TiDB的数据同步，从而验证MySQL和TiDB数据库的差异和兼容性，为后续产品升级TiDB数据库提供技术支持，并通过将内部产品的数据库切换为TiDB，验证产品功能与TiDB数据库的适配程度。

1.1名词解释

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

TiUP：从TiDB 4.0版本开始，TiUP作为新的工具，承担着包管理器的角色，管理着TiDB生态下众多组件，如TiDB、PD、TiKV等。用户想要运行TiDB 生态中任何组件时，只需要执行TiUP一行命令即可。

TiKV：一个分布式事务型的键值数据库，提供了满足ACID约束的分布式事务接口，并且通过Raft协议保证多副本数据一致性以及高可用。TiKV作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。

TiFlash：TiDB HTAP形态的关键组件，是TiKV的列存扩展，在提供了良好隔离性的同时，也兼顾了强一致性。

TiCDC：主要是通过拉取TiKV变更日志实现的TiDB增量数据同步工具，具有将数据还原到与上游任意TSO一致状态的能力，同时提供开放数据协议（TiCDC Open Protocol），支持其他系统订阅数据变更。

TiDB Operator：是Kubernetes上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的TiDB全生命周期管理。借助TiDB Operator，TiDB可以无缝运行在公有云或私有部署的Kubernetes集群上。

TiDB Data Migration：DM是一体化的数据迁移任务管理工具，支持从与 MySQL协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的数据迁移。

1.2MySQL兼容

TiDB 100%兼容MySQL 5.7协议、MySQL 5.7常用的功能及语法。MySQL 5.7生态中的系统工具（phpMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客户端等均适用于 TiDB。

但MySQL的部分功能TiDB尚未支持：

1.存储过程与函数、XML函数、自定义函数、事件；

2.触发器、外键约束、临时表；

3.全文/空间函数与索引；

4.非 ascii/latin1/binary/utf8/utf8mb4 的字符集；

5.事务保存点Savepoints；

6.列级权限；

7.XA 、CREATE TABLE tblName AS SELECT stmt 、CHECK TABLE 、CHECKSUM TABLE 、GET_LOCK 、 RELEASE_LOCK 等语法或函数。

1.3功能验证

本次是第一次进行TiDB的功能验证，主要验证TiDB的数据库部署，部署TiDB、TiKV、PD、TiFlash以及Monitor、Grafana等相关组件和功能。由于是在本地搭建的虚拟机进行环境部署，所以本次只做基础功能验证，对于服务器要求比较高的功能考虑在服务器搭建环境验证。主要验证功能如下：

1.TiDB的安装部署，包括必需的功能组件；

2.在服务器上直接通过命令行访问TiDB数据库进行测试，以及远程访问TiDB Dashboard、Grafana监控页面；

3.通过Navicat连接TiDB数据库，进行建库、建表、建用户、授权、数据增删改查、结构修改等相关SQL语句的验证；

4.通过导入、导出工具实现TiDB和MySQL之间的数据同步；

5.通过产品中的工具在TiDB中初始化数据库，并连接TiDB数据库进行产品功能验证。

2TiDB部署

参考TiDB官方文档进行TiDB数据库的部署，包括单机部署和集群部署，以集群部署为主（单机只做安装验证），并通过本地访问服务器验证远程数据库访问。

2.1环境初始化

1.系统环境为CentOS7：

 

2.安装MySQL，版本为mysql5.7：

 

2.2TiDB安装

由于升级TiDB数据库的目的只为了满足内部产品在大数据量的高可用需要，后续项目中一定是使用集群部署的（通过K8S云平台部署）方案，所以TiDB也需要集群部署，单机部署只做简单测试，保证TiDB可以部署安装。

2.2.1单机部署

1.下载并安装 TiUP：

 

2.声明全局环境变量：

 

3.执行以下命令启动集群：

 

注意：playground的命令行参数说明：

 

 

4.启动效果：

 

2.2.2集群部署

单机模拟生产环境部署。

1.下载并安装 TiUP：

 

2.声明全局环境变量

 

3.安装 TiUP 的 cluster 组件：

 

4.如果已经安装 TiUP cluster，需要更新软件版本：

 

5.通过root用户调大 sshd 服务的连接数限制：

 

 

6.编辑配置文件，命名为 topo.yaml：

 

 

1)user: "tidb"：TiDB部署自动创建的用户，默认为tidb；

2)ssh_port: ssh访问的端口，默认为22；

3)host：TiDB部署的服务器IP地址。

7.创建并启动集群：

 

1)tidb-demo：集群名称；

2)v4.0.10：集群版本，可以通过 tiup list tidb 命令来查看当前支持部署的 TiDB 版本。

根据提示进行设置：

 

集群部署成功（如果部署失败可以通过部署命令重试）：

 

8.启动集群：

 

9.访问 TiDB 数据库，密码为空：

 

10.查询用户：

 

11.修改密码：

 

12.查询当前已经部署的集群列表：

 

13.查看集群的拓扑结构和状态：

 

2.3注意事项

1.在进行单机部署时，TiDB一般默认监听端口为127.0.0.1，即本地监听，部署后无法远程访问，需要通过—host手动定义IP，以支持远程访问，官方文档有提示，但是没有具体用法，需要参考playground 组件介绍：https://docs.pingcap.com/zh/tidb/stable/tiup-playground；

2.在TiDB部署时需要使用root用户进行部署，同时关闭防火墙，或者开放TiDB所需端口，相关端口参考：https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#%E7%BD%91%E7%BB%9C%E8%A6%81%E6%B1%82。

3TiDB测试

TiDB测试主要验证三部分，分别是访问测试、连接测试和数据测试，其中访问测试是通过远程访问TiDB Dashboard和Grafana查看TiDB的监控效果，连接测试主要测试命令行和Navicat的数据库连接测试，再通过SQL语句进行TiDB的数据操作测试。

3.1访问测试

1.Dashboard：http://192.168.0.120:2379/dashboard，用户名root，密码为root用户密码，默认为空；

 

2.Prometheus：http://192.168.0.120:9090

 

3.Grafana：http://192.168.0.120:3000，用户名admin，密码admin；

 

3.2连接测试

1.TiDB默认用户为root，密码为空，安装成功后手动访问进行密码修改；

 

2.访问mysql：

 

3.查询用户：

 

4.修改密码：

 

5.Navicat连接测试：

 

3.3数据测试

数据测试是通过执行SQL实现的，按照SQL类型进行划分：数据定义语言DDL、数据控制语言DCL、数据操作原因DML和数据查询语言DQL，分别验证建库、改库、建表、改表、建用户、权限分配、权限回收、数据增删改查等操作。

3.3.1DDL

1.数据库：

 

2.数据表：

 

注意：

1)TiDB不支持部分字段类型修改（即使没有数据，如int和varchar）；

2)TiDB默认不支持主键修改，可以通过配置文件修改，但该参数只能通过TiDB 配置文件修改，不能通过命令行配置；

 

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file

3.3.2DCL

3.3.3DML

3.3.4DQL

4数据迁移

数据迁移主要是验证TiDB和MySQL之间的数据传输，主要实现方式是通过导入、导出工具将MySQL/TiDB的数据导出成文件，然后再导入到TiDB/MySQL，验证两个数据库之间的数据兼容性和迁移的可能性。本次验证的工具有第三方工具Mydumper/Myloader、TiDB官方工具Dumpling/Lightning，另外TiDB也提供了一种数据迁移任务管理工具TiDB Data Migration，由于该工具也需要进行集群部署，所以本次暂不做验证。

4.1导入TiDB

主要是将MySQL中的数据导出成备份文件，再导入到TiDB数据库，验证导出导入时数据的完整性以及不同工具进行数据迁移的效率，由于性能测试需要配置相对较高的服务器，暂时未做测试。

Mydumper/Myloader：

1.部署Mydumper/Myloader，参考如下：    https://www.cnblogs.com/keme/p/11679446.html#auto_id_0

https://www.cnblogs.com/lizhi221/p/7010174.html

2.创建备份目录：

 

3.mydumper备份数据：

 

说明：mydumper支持全库备份以及单库、单库多表备份，但是没有找到多库备份的方式，只能一个一个备份。

4.myloader还原数据：

 

说明：

1)myloader还原数据性能较低，dap_ods_erp（122张表，最大38万行，mydumper备份958M），导入失败；

2)经验证：不超过10M的单一SQL可以正常导入；

3)导入失败可能是由于服务器配置太低造成的，后续需要进一步验证；

4)根据TiDB官方说明，由于分布式事务的提交机制，如果一个事务非常大，会使得提交过程非常慢，建议每个事务的行数不超过200行，且单行数据小于100k；

 

5)对于数据导入，可以通过TiKV 的参数进行调优，具体可参考https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance；

Dumpling/Lightning：

根据PingPAC官方说明，TiDB早期的导出/导入工具是Mydumper/ Loader，

Mydumper：

 

mydumper project：https://github.com/maxbube/mydumper，即为1.4.1中的Mydumper工具。

Loader：

 

所以本次主要验证Dumpling/Lightning。

1.下载tidb-toolkit（包含dumpling和tidb-lightning）：

 

2.备份数据库：

 

说明：Dumpling除SQL外支持导出CSV文件，同时支持—where的条件过滤以及filter的表名模糊匹配，可以参考：https://docs.pingcap.com/zh/tidb/stable/dumpling-overview；

3.手动添加tidb-lightning.toml文件:

 

说明：data-source-dir：通过dumpling导出的数据源目录，本次导入四个库，所以需要配置四个文件（或者每次修改配置），详细参数可参考：https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-configuration#tidb-lightning-%E5%85%A8%E5%B1%80%E9%85%8D%E7%BD%AE；

4.上传tidb-lightning.toml至root目录：

 

5.创建脚本文件：tidb-lightning.sh

 

6.执行导入导入：

 

说明：dap_biz_erp、dap_ods_erp、dap_edw_trial等其他数据库操作类似。

4.2导入MySQL

1.通过dumpling创建备份：

 

2.使用myloader

 

5产品验证

本次以ESB产品为例进行功能验证，主要通过esb_server中的数据库初始化工具连接TiDB数据库，并进行数据库初始化，验证初始化脚本以及数据库驱动使用。二是通过esb_server连接TiDB数据库进行启动并验证SMC的相关功能是否可用。三是通过设计器进行服务样例开发部署，验证是否可以进行服务开发。

5.1数据初始化

1.建立tidb数据库连接：

 

2.创建ESB数据库：

 

3.startconfigtool连接测试：

 

4.初始化数据库：

 

5.启动esb_server：

 

5.2SMC测试

1.首页：

 

2.服务工程：

 

3.应用集成：

 

4.文件传输：

 

5.监控统计：

 

6.系统资源：

 

5.3设计器测试

1.创建工程：

2.创建样例：

3.工程部署：

4.服务查看：

5.服务测试：

6分析总结

本次技术预研只是作为TiDB数据库的初步探索，验证环境部署、SQL执行、MySQL导入导出等基础功能应用，以及初步通过产品验证TiDB的使用效果，并未对TiDB性能、集群、高可用等功能进行深入研究，本次只是为后续TiDB的深入分析、应用，内部产品的TiDB数据库升级提供了一个基础的技术支撑。

6.1能力提升

通过对TiDB的技术预研，初步了解了Linux下TiDB的集群部署与应用，以及TiDB和MySQL进行数据迁移的过程，为后续各类产品迁移TiDB数据库提供了借鉴，为了支持大数据量的处理，后续公司产品都要支持TIDB数据库，并且由于TiDB是支持K8S部署的，所以后续TiDB也会部署K8S中，从而和UMC的云平台部署进行无缝对接，更便捷的实现集中部署维护。

6.2后续完善

由于本次是在本机验证，很多功能都没有进行验证，包括大数据量测试、压力测试、集群高可用测试，以及TiDB和MySQL的大数据量迁移、增量同步等，后续通过服务器部署TiDB后，相关的功能都要进行验证。对于后续的产品升级，也要通过TiDB的增量同步机制实现从MySQL到TIDB的迭代切换，保证产品的稳定过渡。

6.3个人总结

随着公司产品的不断完善，在项目中不断进行实践，不断总结相关的业务场景时使用要求，对于大数据量的存储和操作是大多数项目都不可避免的问题，而目前产品都是使用MySQL数据库，由于MySQL本身的限制要求找到一个可替代方案来满足大数据层面的要求，而TiDB在大数据方面的优势，以及和MySQL集成特性恰好满足需要，并且数据库切换的成本也相对较低。

技术预研的工作之前做过很多，特别是在DAP开发的过程中，但是深入的从部署到使用再到验证的数据库研究还是比较少的，通过研究TiDB不仅了解了TiDB的相关功能，对于Linux服务器、集群部署等技术点也有了更多的了解。数据库的使用是开发工作和实施工作都要熟悉和了解的内容，所以掌握数据库的部署、使用、优化等工作是非常有必要的，并且需要在平时的工作中不断深化、加强，提升这方面的相关能力。