TiDB

TiDB Binary 部署指导 概述 一个完整的 TiDB 集群包括 PD，TiKV 以及 TiDB。启动顺序依次是 PD，TiKV 以及 TiDB。在关闭数据库服务时，请按照启动的相反顺序进行逐一关闭服务。 阅读本章前，请先确保阅读 TiDB 整体架构 及 部署建议 。 本文档描述了三种场景的二进制部署方式： 快速了解和试用 TiDB，推荐使用 单节点方式快速部署 。 功能性测试 TiDB，推荐使用 功能性测试部署 。 生产环境使用 TiDB，推荐使用 多节点集群模式部署 。 TiDB 组件及默认端口 1. TiDB 数据库组件（必装） | 组件 | 默认端口 | 协议 | 说明 | | :-- | :-- | :-- | :--------------- | | ssh | 22 | TCP | sshd 服务 | | TiDB | 4000 | TCP | 应用及 DBA 工具访问通信端口 | | TiDB | 10080 | TCP | TiDB 状态信息上报通信端口 | | TiKV | 20160 | TCP | TiKV 通信端口 | | PD | 2379 | TCP | 提供 TiDB 和 PD 通信端口 | | PD | 2380 | TCP | PD 集群节点间通信端口 | 2. TiDB 数据库组件（选装） | 组件 | 默认端口 | 协议 | 说明 |

作者： satoru 在 上篇文章 中，我们介绍了 TiDB 如何通过 Pump client 将 binlog 发往 Pump，本文将继续介绍 Pump server 的实现，对应的源码主要集中在 TiDB Binlog 仓库的 pump/server.go 文件中。 启动 Pump Server Server 的启动主要由两个函数实现： NewServer 和 (*Server).Start 。 NewServer 依照传入的配置项创建 Server 实例，初始化 Server 运行所必需的字段，以下简单说明部分重要字段： metrics ：一个 MetricClient ，用于定时向 Prometheus Pushgateway 推送 metrics。 clusterID ：每个 TiDB 集群都有一个 ID，连接到同一个 TiDB 集群的服务可以通过这个 ID 识别其他服务是否属于同个集群。 pdCli ： PD Client，用于注册、发现服务，获取 Timestamp Oracle。 tiStore ：用于连接 TiDB storage engine，在这里主要用于查询事务相关的信息（可以通过 TiDB 中的对应 interface 描述 了解它的功能）。 storage ：Pump 的存储实现，从 TiDB 发过来的 binlog 就是通过它保存的

stmt-count-limit TiDB 一个事务允许的最大语句条数限制。 默认: 5000 在一个事务中，超过 stmt-count-limit 条语句后还没有 rollback 或者 commit，TiDB 将会返回 statement count 5001 exceeds the transaction limitation, autocommit = false 错误。 需要修改Tidb-server的配置文件，进入容器查看，为根目录下， 检查docker-compose.yml文件，为该文件是映射出来，将物理服务器上的文件进行修改，将stmt-count-limit修改为100000，将Tidb-server服务重启后，配置正常修改了 选择增大 tidb 的单个事物语句数量限制，不过这个会导致内存上涨。 来源： https://blog.51cto.com/13767724/2431262

作者：张学程 本文为 DM 源码阅读系列文章的第九篇，在 上篇文章 中我们详细介绍了 DM 对 online schema change 方案的同步支持，对 online schema change 同步方案以及实现细节等逻辑进行了分析。 在本篇文章中，我们将对 shard DDL 同步机制以及 checkpoint 机制等进行详细的介绍，内容包括 shard group 的定义、shard DDL 的同步协调处理流程、checkpoint 机制以及与之相关的 safe mode 机制。 shard DDL 机制的实现 DM 中通过 库表路由与列值转换 功能，实现了对分库分表合并场景下 DML 的同步支持。但当需要同步的各分表存在 DDL 变更时，还需要对 DDL 的同步进行更多额外的处理。有关分表合并时 shard DDL 同步需要处理的问题以及 DM 中的同步支持原理，请先阅读 TiDB Ecosystem Tools 原理解读系列（三）TiDB-DM 架构设计与实现原理 。 shard group 在 这篇文章 中，我们介绍了 DM 在处理 shard DDL 同步时引入了两级 shard group 的概念，即用于执行分表合并同步任务的各 DM-worker 组成的 shard group、每个 DM-worker 内需要进行合表同步的各上游分表组成的 shard

作者：沈瑀昊 DM（TiDB Data Migration）是由 PingCAP 开发的一体化数据同步平台，支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据同步。无论是从 MySQL 向 TiDB 进行平滑数据迁移还是用 TiDB 作为多个 MySQL 实例的数据汇总库，都可以通过 DM 来实现。DM 在 TiDB DevCon 2019 上正式开源，经过半年多时间在大量用户、开发者的支持和反馈下，其功能和稳定性越来越完善。在今天，我们宣布 DM 1.0 GA 正式发布。 <center>DM Architecture</center> 核心特性 一体化数据同步 在进行上下游数据同步的时候，一般需要先进行全量数据复制，再进行增量数据同步。DM 同步任务支持配置多个上游 MySQL/MariaDB 实例，并且同时执行全量迁移和增量同步，可以简单稳定地满足用户迁移数据的场景。 同步规则可配置 DM 提供了包括库表路由（Table routing）、黑白名单（Black & white table lists）、binlog 过滤（Binlog event filter）在内丰富的数据同步规则，支持在数据同步中进行自定义配置。 分库分表自动合并 在使用 MySQL 支撑大量数据时，经常会选择使用分库分表的方案。但当将数据同步到 TiDB 后

作者：lan 本文为 DM 源码阅读系列文章的第三篇， 上篇文章 介绍了 DM 的整体架构，DM 组件 DM-master 和 DM-worker 的入口代码，以及两者之间的数据交互模型。本篇文章详细地介绍 DM 数据同步处理单元（DM-worker 内部用来同步数据的逻辑单元），包括数据同步处理单元实现了什么功能，数据同步流程、运行逻辑，以及数据同步处理单元的 interface 设计。 数据同步处理单元 从上图可以了解到目前 DM 包含 relay log、dump、load、binlog replication（sync） 4 个数据同步处理单元，涵盖了以下数据同步处理的功能： 处理单元 功能 relay log 持久化 MySQL/MariaDB Binlog 到磁盘 dump 从 MySQL/MariaDB dump 全量数据 load 加载全量数据到 TiDB cluster binlog replication（sync） 复制 relay log 存储的 Binlog 到 TiDB cluster 数据同步流程 Task 数据同步流程初始化操作步骤： DM-master 接收到 task， 将 task 拆分成 subtask 后 分发给对应的各个 DM-worker ； DM-worker 接收到 subtask 后 创建一个 subtask 对象 ，然后

作者：王相 简介 TiDB-Binlog 组件用于收集 TiDB 的 binlog，并提供实时备份和同步功能。该组件在功能上类似于 MySQL 的主从复制，MySQL 的主从复制依赖于记录的 binlog 文件，TiDB-Binlog 组件也是如此，主要的不同点是 TiDB 是分布式的，因此需要收集各个 TiDB 实例产生的 binlog，并按照事务提交的时间排序后才能同步到下游。如果你需要部署 TiDB 集群的从库，或者想订阅 TiDB 数据的变更输出到其他的系统中，TiDB-Binlog 则是必不可少的工具。 架构演进 TiDB-Binlog 这个组件已经发布了 2 年多时间，经历过几次架构演进，去年十月到现在大规模使用的是 Kafka 版本，架构图如下： Kafka 版本的 TiDB-Binlog 主要包括两个组件： Pump：一个守护进程，在每个 TiDB 主机的后台运行。其主要功能是实时记录 TiDB 产生的 binlog 并顺序写入 Kafka 中。 Drainer： 从 Kafka 中收集 binlog，并按照 TiDB 中事务的提交顺序转化为指定数据库兼容的 SQL 语句或者指定格式的数据，最后同步到目的数据库或者写到顺序文件。 这个架构的工作原理为： TiDB 需要与 Pump 绑定，即 TiDB 实例只能将它生成的 binlog 发送到一个指定的 Pump 中；

之前看到的TiDB和MySql的性能对比都是大量短耗时请求下的压测，单机情况下TiDB和MySql的确有些差距，不过笔者最近碰到的场景更多是sql要扫描的行数不小的情况下单sql比较耗时的问题，所以自己做了个简单测试这类型sql的耗时。 TiDB单机环境部署 按照官方文档( https://pingcap.com/docs-cn/dev/how-to/get-started/deploy-tidb-from-docker-compose/)直接使用docker-composer部署 git clone https://github.com/pingcap/tidb-docker-compose.git # 下载 cd tidb-docker-compose && docker-compose pull # 拉取镜像 docker-compose up -d # 启动 命令行客户端连接方式 mysql -h 127.0.0.1 -P 4000 -u root 测试 表结构 create table testTable ( `id` int(10) unsigned auto_increment primary key, `uid` int(10) not null default 0, `day` int(6) not null default 0, `field1` varchar

作者：周昱行 在整个 SQL 执行过程中，需要经过 Parser，Optimizer，Executor，DistSQL 这几个主要的步骤，最终数据的读写是通过 tikv-client 与 TiKV 集群通讯来完成的。 为了完成数据读写的任务，tikv-client 需要解决以下几个具体问题： 如何定位到某一个 key 或 key range 所在的 TiKV 地址？ 如何建立和维护和 tikv-server 之间的连接？ 如何发送 RPC 请求？ 如何处理各种错误？ 如何实现分布式读取多个 TiKV 节点的数据？ 如何实现 2PC 事务？ 我们接下来就对以上几个问题逐一解答，其中 5、6 会在下篇中介绍。 如何定位 key 所在的 tikv-server 我们需要回顾一下之前 《三篇文章了解 TiDB 技术内幕——说存储》 这篇文章中介绍过的一个重要的概念：Region。 TiDB 的数据分布是以 Region 为单位的，一个 Region 包含了一个范围内的数据，通常是 96MB 的大小，Region 的 meta 信息包含了 StartKey 和 EndKey 这两个属性。当某个 key >= StartKey && key < EndKey 的时候，我们就知道了这个 key 所在的 Region，然后我们就可以通过查找该 Region 所在的 TiKV 地址

DDL 是数据库非常核心的组件，其正确性和稳定性是整个 SQL 引擎的基石，在分布式数据库中，如何在保证数据一致性的前提下实现无锁的 DDL 操作是一件有挑战的事情。本文首先会介绍 TiDB DDL 组件的总体设计，介绍如何在分布式场景下支持无锁 shema 变更，描述这套算法的大致流程，然后详细介绍一些常见的 DDL 语句的源码实现，包括 create table 、 add index 、 drop column 、 drop table 这四种。 DDL in TiDB TiDB 的 DDL 通过实现 Google F1 的在线异步 schema 变更算法，来完成在分布式场景下的无锁，在线 schema 变更。为了简化设计，TiDB 在同一时刻，只允许一个节点执行 DDL 操作。用户可以把多个 DDL 请求发给任何 TiDB 节点，但是所有的 DDL 请求在 TiDB 内部是由 owner 节点的 worker 串行执行的。 worker：每个节点都有一个 worker 用来处理 DDL 操作。 owner：整个集群中只有一个节点能当选 owner，每个节点都可能当选这个角色。当选 owner 后的节点 worker 才有处理 DDL 操作的权利。owner 节点的产生是用 Etcd 的选举功能从多个 TiDB 节点选举出 owner 节点。owner 是有任期的，owner