TiDB

作者：satoru TiDB Binlog 架构简介 TiDB Binlog 主要由 Pump 和 Drainer 两部分组成，其中 Pump 负责存储 TiDB 产生的 binlog 并向 Drainer 提供按时间戳查询和读取 binlog 的服务，Drainer 负责将获取后的 binlog 合并排序再以合适的格式保存到对接的下游组件。 在《 TiDB Binlog 架构演进与实现原理 》一文中，我们对 TiDB Binlog 整体架构有更详细的说明，建议先行阅读该文。 相关源码仓库 TiDB Binlog 的实现主要分布在 tidb-tools 和 tidb-binlog 两个源码仓库中，我们先介绍一下这两个源码仓库中的关键目录。 1. tidb-tools Repo: https://github.com/pingcap/tidb-tools/ 这个仓库除了 TiDB Binlog 还有其他工具的组件，在这里与 TiDB Binlog 关系最密切的是 tidb-binlog/pump_client 这个 package。 pump_client 实现了 Pump 的客户端接口，当 binlog 功能开启时，TiDB 使用它来给 pump 发送 binlog 。 2. tidb-binlog Repo: https://github.com/pingcap/tidb

在刚刚结束的 TiDB DevCon 2019 上，我们宣布将大家期待已久的 TiDB-Ligthning Toolset 和 TiDB-DM 开源（惊不惊喜、意不意外？！），感兴趣的小伙伴们赶紧前排关注一波，开“坑（issues）”讨论，PR 走起！ TiDB-Lightning Toolset TiDB-Lightning Toolset 是一套快速全量导入 SQL dump 文件到 TiDB 集群的工具集 ，自 2.1.0 版本起随 TiDB 发布，最新的测试结果显示，速度可达到传统执行 SQL 导入方式的至少 5 倍，导入 1T 数据需要 5 ～ 6 个小时，适合在上线前用作迁移现有的大型数据库到全新的 TiDB 集群。 原理解读： TiDB-Lightning Toolset 介绍 项目地址： github.com/pingcap/tidb-lightning TiDB-DM TiDB-DM（Data Migration）是用于将数据从 MySQL/MariaDB 迁移到 TiDB 的工具 。该工具既支持以全量备份文件的方式将 MySQL/MariaDB 的 数据导入到 TiDB，也支持通过解析执行 MySQL/MariaDB binlog 的方式将数据增量同步到 TiDB。特别地，对于有多个 MySQL/MariaDB 实例的分库分表需要合并后同步到同一个 TiDB

一 创建nfs（maste节点操作，两个node节点也需要安装） 1 首先安装一个nfs服务器，配置共享目录, [yx@tidb-tidb-02 ~]$ cat /etc/exports /home/yx/hnf *(rw,no_root_squash) 然后启动nfs 2 然后在master上面创建一个nfs pv的动态供给，需要三个文件class.yaml deployment.yaml rbac.yaml 这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy rbac是让nfs有权限访问apiserver，其中需要更改的地方是deploynment.yaml里面的nfsip地址和nfs所共享的目录 kubectl create -f rbac.yaml kubectl create -f class.yaml kubectl create -f deployment.yaml #第一次创建的时候回提示存在，不知道什么原因，然后删除，再次创建即可 最后查看是否创建成功 [yx@tidb-tidb-03 nfs]$ kubectl get pods NAME READY STATUS RESTARTS AGE nfs-client

作者：黄佳豪 TiDB Binlog 组件用于收集 TiDB 的 binlog，并准实时同步给下游，如 TiDB、MySQL 等。该组件在功能上类似于 MySQL 的主从复制，会收集各个 TiDB 实例产生的 binlog，并按事务提交的时间排序，全局有序的将数据同步至下游。利用 TiDB Binlog 可以实现数据准实时同步到其他数据库，以及 TiDB 数据准实时的备份与恢复。随着大家使用的广泛和深入，我们遇到了不少由于对 TiDB Binlog 原理不理解而错误使用的情况，也发现了一些 TiDB Binlog 支持并不完善的场景和可以改进的设计。 在这样的背景下，我们开展 TiDB Binlog 源码阅读分享活动，通过对 TiDB Binlog 代码的分析和设计原理的解读，帮助大家理解 TiDB Binlog 的实现原理，和大家进行更深入的交流，同时也有助于社区参与 TiDB Binlog 的设计、开发和测试。 背景知识 本系列文章会聚焦 TiDB Binlog 本身，读者需要有一些基本的知识，包括但不限于： Go 语言，TiDB Binlog 由 Go 语言实现，有一定的 Go 语言基础有助于快速理解代码。 数据库基础知识，包括 MySQL、TiDB 的功能、配置和使用等；了解基本的 DDL、DML 语句和事务的基本常识。 了解 Kafka 的基本原理。 基本的后端服务知识

作者：Shirly TiDB 最佳实践系列是面向广大 TiDB 用户的系列教程，旨在深入浅出介绍 TiDB 的架构与原理，帮助用户在生产环境中最大限度发挥 TiDB 的优势。我们将分享一系列典型场景下的最佳实践路径，便于大家快速上手，迅速定位并解决问题。 在前两篇的文章中，我们分别介绍了 TiDB 高并发写入常见热点问题及规避方法 和 PD 调度策略最佳实践 ，本文我们将深入浅出介绍 TiDB 乐观事务原理，并给出多种场景下的最佳实践，希望大家能够从中收益。同时，也欢迎大家给我们提供相关的优化建议，参与到我们的优化工作中来。 建议大家在阅读之前先了解 TiDB 的整体架构 和 Percollator 事务模型。另外，本文重点关注原理及最佳实践路径，具体的 TiDB 事务语句大家可以在 官方文档 中查阅。 TiDB 事务定义 TiDB 使用 Percolator 事务模型，实现了分布式事务（建议未读过该论文的同学先浏览一下 论文 中事务部分内容）。 说到事务，不得不先抛出事务的基本概念。通常我们用 ACID 来定义事务（ ACID 概念定义 ）。下面我们简单说一下 TiDB 是怎么实现 ACID 的： A（原子性）：基于单实例的原子性来实现分布式事务的原子性，和 Percolator 论文一样，TiDB 通过使用 Primary Key 所在 region 的原子性来保证。 C

2018 年 TiDB 产品变得更加成熟和稳定，同时 TiDB 社区力量也在发展壮大。在 TiDB DevCon 2019 上，我司联合创始人崔秋带大家一起回顾了 2018 年 TiDB 社区成长足迹，在社区荣誉时刻环节，我们为新晋 Committer 授予了证书，并为 2018 年度最佳贡献个人/团队颁发了荣誉奖杯。 <center>图 1 我司联合创始人崔秋</center> 在我们眼里运营开源社区最重要的是两点，一个是人才，一个是用户。人才方面主要面向开发者，包括 TiDB Contributor、Committer 以及 TiDB 生态周边的开发者等等。另外更重要的一方面是用户。用户对 TiDB 的认识和经验、给予的反馈是更直观、更贴近业务的，并且用户实际应用的场景与我们自身测试的场景相比，会更复杂、更丰富，他们的使用经验会让大家更有共鸣，另外当用户使用 TiDB 过程中遇到一些问题，这时社区有良好的反馈，帮助用户顺利解决问题，会让用户对 TiDB 更有信心，就会考虑扩大使用的规模和深度，同时 TiDB 社区本身也会得到成长。所以，运营一个好的开源社区，更重要的是以用户为中心。2019 年我们也会秉承这个想法， 继续把「用户至上」的观念和理念发挥到极致，与用户一起成长。 ——崔秋 Product <center>图 2 TiDB 产品架构</center>

一、重要文档 ● 【TiDB 中文文档】 https://pingcap.com/docs-cn ● 【FAQ】 https://pingcap.com/doc-FAQ-zh ● 【OPS】 https://www.tidb.cc 二、TiDB 的技术原理 ● 【TiDB 技术内幕】 ○ 说存储 http://t.cn/RTKRRWv ○ 说计算 http://t.cn/RTKRkBh ○ 说调度 http://t.cn/RTKEZ0U rocksdb wiki: https://en.wikipedia.org/wiki/RocksDB github: https://github.com/facebook/rocksdb/wiki/RocksDB-Basics ● 【TiDB 基准测试】 ○ http://t.cn/RT8oi0j ● 【TiDB 最佳实践】 ○ http://t.cn/RTKEWf0 ● 【TiSpark】 ○ 用户指南 http://t.cn/RTKEgWm ● 【TiDB 事务相关】 ○ http://t.cn/RaxOmRZ ● 【Raft 相关】 ○ http://t.cn/ROYYxse ● 【TiDB 在线 Schema 变更】 ○ http://t.cn/RbDaPjf 三、TiDB 核心特性 ● 水平线性弹性扩展 ● 数据强一致的分布式事务 ●

近来newsql大热，尤以TIDB最火，pingcap不断打磨TiDB，现如今版本已经迭代到3.0，产品已经基本趋于成熟。 对于TiDB，整体架构图如下图所示 是由四个模块组成，TiDB Server，PD Server，TiKV Server，TiSpark。 TiDB Server 负责接受SQL请求，处理SQL的相关逻辑，并通过PD找到存储计算所需数据的TiKV地址，与TiKV交互获取数据，最终返回结果。TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVD，HAPROXY，F5等）对外提供统一的接入地址。推荐部署俩个实例，前端通过负载均衡组件对外提供服务，当单个实例失效时，会影响正在这个实例上进行的session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。 Placement Driver (简称 PD)，是整个集群的管理模块，其主要的工作有三个，一是存储集群的元信息，（某个Key存储在哪个TiKV节点上）；二是对TiKV集群进行调度和负载均衡（如数据的迁移，Raft group leader的迁移等），三是分配全局唯一且递增的事务ID。PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作，其余的 PD server 仅用于保证高可用

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 的单个事物语句数量限制，不过这个会导致内存上涨。 来源： 51CTO 作者： Hermoso 链接： https://blog.51cto.com/13767724/2431262

单机版的TiDB体验 注：操作系统是CentOS 7.4 、 Ubuntu 16 # 下载压缩包 wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz wget http://download.pingcap.org/tidb-latest-linux-amd64.sha256 # 检查文件完整性，返回 ok 则正确 sha256sum -c tidb-latest-linux-amd64.sha256 # 解开压缩包 tar -xzf tidb-latest-linux-amd64.tar.gz cd tidb-latest-linux-amd6 快速部署 如下步骤依次启动PD, TiKV, TiDB 启动PD 注：如果是单界面回话可以放到后台运行，我这边是xshell所以没有放到后台多界面操作 ./bin/pd-server --data-dir=pd --log-file=pd.log & 命令行输出 ······ 2018/09/09 14:38:28 server.go:190: [info] init cluster id 6373614252582442019 2018/09/09 14:38:28 leader.go:194: [info] PD cluster leader pd is