Tidb

TiDB简介

TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。（TiDB是什么，有什么特点，解决什么问题..）

TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。

MySQL 的主从复制 + GTID 的方案可能也基本够用，这不够的话，还有最近引入的 Group Replication，分库分表

灰度上线变得平滑，甚至从 TiDB 无缝的迁移回来，而且有些小数据量的业务你仍然可以继续使用 MySQL

MySQL 的第三方框架和工具的测试用例是我们一个很重要的测试资源，

TiDB系统架构

计算存储分离

• 独立更新设计， 增加运维友好性。如果所有部件都是耦合在一起的话，你面临的就是一次整个集群的滚动更新，如果分层得当的话，你可能需要的只是更新无状态的 SQL 层

• 提高服务器资源利用率 存储和 SQL 所依赖的计算资源是不一样的，存储会依赖 IO，而计算对 CPU 以及内存的要求会更高。

• 开发的友好性

  计算和存储可以选择不同的编程语言，

AWS Aurora直接基于 MySQL 的源码，保留 SQL 层，下面替换存储引擎的方式实现扩展;

TiDB技术内幕

存储 TiKV

• RocksDB 作为单机KV存储引擎
• 目前的环境下，做一个新的数据库，底层的存储数据结构能选的大概就两种：1. B+Tree, 2. LSM-Tree。
• Raft 用来解决分布式KV存储问题
• 以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每个节点上服务的 Region 数量差不多
• MVCC控制并发写入问题
• TiKV 的事务采用的是 Percolator 模型，采用乐观锁

计算 TiDB

• 关系模型到KV模型的映射（Row、Index和元数据）
• 分布式SQL运算，将过滤、聚合下推到存储节点
• SQL的语法解析、查询计划制定和优化、执行查询计划获取和处理数据

调度 PD (Placement Driver)

• 一个 Region 的 Replica 数量正确

• 一个 Raft Group 中的多个 Replica 不在同一个位置（最小容错单元）

• 副本在 Store 之间的分布均匀分配

• Leader 数量在 Store 之间均匀分配

• 访问热点数量在 Store 之间均匀分配

• 各个 Store 的存储空间占用大致相等

• 控制调度速度，避免影响在线服务

实战MySQL迁移到TiDB

软硬件环境需求

操作系统 TiDB建议部署在 CentOS 7.3上，因为Pingcap和社区在该系统上进行了大量测试和最佳实践。

硬件

物理机及 VMware、KVM、XEN 主流虚拟化环境，建议配置，

• 单机测试环境

• 开发测试环境（最少4个实例）

• 产品环境（最少7个实例）

使用TiDB-Ansible部署TiDB集群

测试环境，4个节点（机器）

跨数据中心

https://www.pingcap.com/docs-cn/op-guide/cross-dc-deployment/

迁移数据

全量迁移

• mydumper

  ./bin/mydumper -h 127.0.0.1 -P 3306 -u root -t 16 -F 64 -B test -T t1,t2 --skip-tz-utc -o ./var/test
  

  关于mydumper,https://www.cnblogs.com/lizhi221/p/7016062.html 关于Flush table with read lock, FTWRL详解

• loader

(END)