tidb生态工具-笔记

spark计算引擎 tispark 面临大批量数据报表

列存储天然对OLAP友好 ，数据实时性，采取raft-log

计算下推

写入是最昂贵的，增加物理节点，意味着整个集群写入容量进行提升

两地三中心 金融级

5.0以上事务采取去中心化的两段提交

mysql分库分表 弹性差、resharding成本大

逻辑备份：可读，慢，可异构迁移

物理备份：速度快，不可读，不支持异构迁移

复制备份：比如主从架构，从库作为备份；异步复制，有传输延时，可能丢失数据

lightning：

• 整张表相关联的所有引擎文件完成导入后，tidb-lightning 会对比本地数据源及下游集群的校验和 (checksum)，确保导入的数据无损，然后让 TiDB 分析 (ANALYZE) 这些新增的数据，以优化日后的操作。同时，tidb-lightning 调整 AUTO_INCREMENT 值防止之后新增数据时发生冲突。
• 表的自增 ID 是通过行数的上界估计值得到的，与表的数据文件总大小成正比。因此，最后的自增 ID 通常比实际行数大得多。这属于正常现象，因为在 TiDB 中自增 ID 不一定是连续分配的。
• 
  
• TiDB Lightning 目前支持两种导入模式，即后端。不同的后端决定 TiDB Lightning 如何将数据导入到目标 TiDB 集群。

• 以上几种后端导入数据的区别如下：

• Local-backend：tidb-lightning 先将数据编码成键值对并排序存储在本地临时目录，然后将这些键值对以 SST 文件的形式上传到各个 TiKV 节点，然后由 TiKV 将这些 SST 文件 Ingest 到集群中。和 Importer-backend 原理相同，不过不依赖额外的 tikv-importer 组件。
• Importer-backend：tidb-lightning 先将 SQL 或 CSV 数据编码成键值对，由 tikv-importer 对写入的键值对进行排序，然后把这些键值对 Ingest 到 TiKV 节点中。
• TiDB-backend：tidb-lightning 先将数据编码成 INSERT 语句，然后直接在 TiDB 节点上运行这些 SQL 语句进行数据导入。

适用大量新数据需要迅速导入到tidb中，每小时400GB~500GB

lightning 吃硬件，资源密集程序

下游数据库所需空间：空间3副本，导入方式再tikv节点生成临时文件，所以需要2倍空间

x*3*2

目标 TiKV 集群必须有足够空间接收新导入的数据。除了标准硬件配置以外，目标 TiKV 集群的总存储空间必须大于 数据源大小 × 副本数量 × 2。例如集群默认使用 3 副本，那么总存储空间需为数据源大小的 6 倍以上。

确保 CPU 核数和内存（GB）比为 1:2 以上

过滤表导入有两种方法，第一种在lightning命令行中制定，第二种在配置文件dumper中

DM：

原理与架构 数据迁移 适用场景

dmm-master 负责管理和调度数据迁移任务的各项工作，保存整个dm的拓扑信息、高可用，监控各个几点的运行状态，提供数据统一接口

dm-worker ：负责执行具体的数据迁移i任务，binlog，一个worker对应一个mysql，即一个源端；超过上游数据库个数，free状态，如果有其他worker故障，则保证高可用，master进行任务重新分配，如果没有等待其他任务完成后接管。

dmctl：用来控制DM集群的命令行工具

异步修改