30G 的数据库如何高效搬运到服务器？

mysql 和 es 我都很少用，但是这类使用习惯都是先分析，想清楚历史数据和增量数据以及使用的特征，先在服务器建好库分区分表索引，把数据直接扔上去再根据新结构插进去，这样逻辑清楚，兼顾未来使用，就几千万条数据而已，很快。

30G dump 很快的，然后再压缩一下，估计没多少

@GTim 都是文本，压缩完都还有 25G

@Maxwe11 意思就是先上传数据，然后在服务器建立 es 索引？

都是文本，不是压缩完更小吗？

@xsir2020 都是实打实的文本，没有多少压缩空间的

实打实的文本是啥意思？感觉我们聊的不在一个时空。

@tellmeworld 纯文本压缩空间非常大啊

可以跟本地数据库组个主从同步

@xsir2020
@yggd 纯文本压缩空间是很大，我是说压缩出来文件还是很大

ES 可以打个快照，然后再恢复，mysql 就 dump 一个文件上传吧。30G 上传也没多久吧。撑死半小时吧。

压缩，分块，多线程上传，合并，解压，导入

你问这个问题的时间，估计就能够处理完了。do it

你有这个问的功夫，直接上传也早传完了。 30G ，没必要用什么奇技淫巧。

才 30G ，直接传就完事，等待时间就当在摸鱼吧

正确方法：压缩 mysql 上传到百度网盘，配合直链下载助手，生成直链使用 curl 链接下载到服务器上，比自己上传到服务器上快多了。

@iPc666 厉害了

@iPc666 需要百度超级会员，否则 10k 的速度，直接撞墙。

Logstash 读取 mysql 写入 es
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html

这些数据都是不变的咩，其实既然是 mysql 就应该用 binlog 将变更数据发送到消息队列，再由消费者消费写入 ES ，做准实时的同步；

存量的数据可以用 SELECT 的方式下发给消费者一并处理，也可以直接 SELECT 然后程序写入 ES 。至于要跑多少时间如果两个机器都在同一个网络内的话应该速度会挺快的，还是不要考虑跨网络的方案了叭

30G 压缩完还是 25G ，你压缩的是 mysql 的 data 文件夹，还是 dump 文件？

建议的做法是 dump 出来，然后压缩 dump 文件，传到数据库，重建数据库。
建议用 xz 压缩。

如果你有强力 CPU ，可以试试 -9e 级别的压缩，我曾经压缩 300G 的 mysql dump 文件，在一个 4 路 20 核 40 线程（共 160 线程）的机器上压了 8 个多小时才完成，160 核全跑满了，压缩完大概 20 多 g 。

条条大路通罗马呀

如果服务器外网带宽多，直接用 es dump 工具，把你本地的 es 同步到 server
如果是小水管，那就麻烦点，可以把 es 的数据目录打包上传，再服务器配好环境放到指定目录下（用 docker 也可以，目录映射）


我估计两种方法差不太多

用 DB 备份工具，选择压缩备份，上传到公有云的对象存储（支持断续），然后服务器去下载。

mysqldump 出来 再用 zstd 压缩，应该最终文件 3G 左右，随便怎么传

除非你的数据是二进制 blob ，纯文件压缩效率很高的

mysql dump 出来重新加载一遍完事

不能装 U 盘里, 插到机房电脑上么

@tellmeworld 这个是我的习惯，因为我不是系统应用研发，我们是搞数据研发的，所以基础的业务数据行为数据等一些结构设计等，都不太符合我们做数据的要求，为了更满足我们处理的要求，一般都会有很多调整，处理好基本结构后再把数据插回去。

@godall 换成阿里 /天翼 /迅雷 /夸克也可以，都支持

传输大文件的话直接 rsync 命令，自带压缩跟断点续传，一步到位

3T 再来考虑这个问题