BR的备份数据加密功能支持在备份时候使用给定的密钥加密云上的文件，希望dumpling也支持这种逻辑
dumpling 未来是不计划支持的…我们目前是希望收敛这些工具，产品更聚焦，具体的计划是
- 数据进来，如果不走链路就走内核，用 import into 语法，支持本地/S3，最终废弃 lightning 这个外部工具
- 数据出去，如果不走链路也可以走内核，计划用 export 语法，支持本地/S3，最终废弃 dumpling 这个工具
- 数据进出的同步工具就是 DM（in-bound） 和 CDC（out-bound）
其他工具都不在计划内了，另外提到的这个场景用 BR 来备份加密有什么问题，为什么考虑 dumpling？
1 个赞
mark 一下，应该是逻辑备份吧
这里的「链路」是指？其实作为一个用户，我感觉维护独立的二进制工具反而更灵活，理由有下面几点：
- 当前dumpling / lightning都是单独的二进制文件，我可以在TiDB集群外，找其他机器来执行导出/导入任务。尤其是lightning，在导入时候lightning自身会占用大量资源，如果后续只能在TiDB内部通过SQL方式触发，肯定会影响集群稳定性的。 即便是现在支持将background task限制到某些tidb-server节点，操作成本也比较高，远不如直接二进制灵活，隔离的更彻底。
- 因为TiDB定位是兼容MySQL的，其实我经常用lightning / dumpling工具来替代 myloader / mydumper工具来对MySQL进行导入/导出，这两种工具其实能提升Pingcap的口碑，吸引一部分MySQL用户。
如果是为了集成到内部，放弃独立工具模式，那就太可惜了。
这个是两个不同维度的备份，当前我们两种模式都有使用，其中BR是物理备份，我们用来做容灾的；dumpling是逻辑备份，我们主要是归档时候，要将历史数据归档到OSS中，也不希望明文存放。
舍弃dumpling ，lightning感觉不太明智哎，dm，cdc比较重，逻辑备份还是导入导出方便
dumpling是逻辑导出，文件是SQL和csv或云，这个不支持加密
- 选择一个独立的节点，部署 TiDB 或者 Lightning，为什么 Lightning 的成本更低，更灵活？可以展开说明下么？在只部署少量 Lightning 的背景下，Lightning 和 TiDB 节点的导入成本，稳定性，性能应该是差不多的，但是一旦数据量大了，需要多 Lightning 并行的时候，因为 Lightning 缺少调度管理，稳定性和性能的上限都比较低，TiDB 内部可以直接通过并行调度管理来解决这个问题。background 资源组是一种隔离方案，独立的 TiDB 节点也是一种隔离方案，其实不用太担心资源隔离的问题。
TiDB 部署好之后，就可以直接通过以下方式导入，导出，这样还是觉得不满足诉求么？
导入：import into from local/S3
导出：export into local/S3
回到题目的问题，import/export 会支持几种加密、压缩呢？
机器成本确实都差不多，我其实最主要指的是操作的复杂度。在数据量小的时候，其实直接用IMPORT方式来导入数据，还挺方便的。但是在大数据量(上T，甚至几十T)导入的场景下，lightning导入时候必然会使用很大的CPU和内存，其实非常不适合和存在业务访问的tidb-server放在一起，很容易影响正常的业务请求。在这个前提下，肯定是要使用独立的机器来完成大数据量的导入工作。这里就有以下几个问题：
- 如果lightning作为普通的binary时，我只要把二进制文件拷上去就好了，这台机器即便负载很高也不用担心，因为这是正常现象。 其次这台机器还可以用作其它用途，不需要作为tidb集群的一部分。
- 而如果是通过扩容tidb-server节点来实现机器的隔离，首先扩容的操作成本就高一些，其次在导入期间，IMPORT节点的CPU和内存负载都会很高，肯定会触发之前集群默认配置的告警规则，现在基本上都是精细化管理，这种告警的解释成本也会增加。
- 如果内置为TiDB的一个功能，那其实就是把一个本可以适用于整个MySQL的工具，给缩小成TiDB专用工具，其实和Pingcap的开源理念也不太相符。
所以感觉，如果不是特别增加了开发难度，建议还是维持现状——IMPORT INTO和Lightning独立部署同时都提供。
其实这个确实也是个关键，后续import/export有考虑加密的事情么？
请问有计划支持跨库做import么，现在先dumpling然后lightning还要落地，不但时间长而且还要很大的磁盘空间。