MySQL大文件传输

本文主要是介绍MySQL大文件传输，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

在管理MySQL、初始化服务器、克隆复制和进行备份/还原操作时，复制、压缩和解压缩大文件（常常是跨网络的）是很常见的任务。能够最快最好完成这些任务的方法并不总是显而易见的，并且方法好坏的差异可能非常显著。这个附录将通过几个例子演示使用常见的UNIX实用工具，将一个大尺寸的备份镜像从一台服务器复制到其他服务器。

通常从未压缩的文件开始，例如一台服务器上的InnoDB表空间和日志文件。当然，在把文件复制到目的地之后要再将它解压缩。另外一个常见的场景是以压缩文件开始，例如备份镜像文件，以解压文件结束。 

如果网络传输能力有限，那么用压缩格式在网络间发送文件是个好方法。你可能还需要一个安全的传输途径，使数据不会被损坏；这对于备份镜像文件来说，是一个很常见的需求。

1.    复制文件

这个任务实际上就是完成以下事情。

1.(可选）压缩数据。

2.发送到另外一台机器上。

3.把数据解压缩到最终目的地。.

4.在复制完成后，校验文件以确认其没有被损坏。

我们对能达成这些目标的一系列方法进行了基准测试。

对于在本书里讨论过的很多目的，例如备份，你可能要考虑在哪一台机器上做压缩会更好一点。如果有足够的网络带宽，还是复制未压缩形式的备份镜像文件为好，这样可以在MySQL服务器上节省出CPU资源供査询使用。

1.1   一个简单的示例

我们以1个简单的示例开始，安全地将一个未压缩的文件从一台机器发送到另外一台上， 途中将它进行压缩，然后再解压。在称为server1的源服务器上，执行如下命令。

1. server1$ gzip -c /backup/mydb/mytable.MYD > mytable.MYD.gz
2. server1$ scp mytable.MYD.gz root@server2:/var/lib/myql/mydb/

然后，在server2上执行如下命令。

1. server2$ gunzip /var/lib/mysql/mydb/mytable.MYD.gz

这大概是最简单的实现方法了，但效率并不高，因为涉及压缩、复制和解压缩等串行化 的步骤。每一个步骤都需要读/写磁盘，速度比较慢。上述命令的真正操作依次是这样的：在server1上gzip既要读又要写，scp在server1上读而在server2上写；gunzip在server2上既要读又要写。

1.2 一步到位的方法

下面这个方法更有效率一些，它将压缩、复制文件和在传输的另一端解压缩文件全部放 在一个步骤里完成。这一次我们使用SSH，SCP就是基于这个安全协议的。下面是在server1上执行的命令。

1. server1$ gzip -c /backup/mydb/mytable.MYD | ssh root@server2"gunzip -c - > /var/lib
2. >/mysql/mydb/mytable.MYD"

这个方法通常比第一个方法好，因为它极大地降低了磁盘I/O :磁盘活动被减少到只要在server1上读，在server2上写。这也使得磁盘操作更加有序。

也可以使用SSH内建的压缩来完成，但是我们展示的是用管道来做压缩和解压缩，这是 因为这样能给予你更大的灵活性。例如，假如你不想在另一端解压缩文件，就无法使用SSH的压缩。

可以通过调整一些选项来提髙这个方法的效率，例如给gzip增加选项-l，使其压缩得更快。这个选项通常不会降低太多压缩率，但是能明显提髙压缩速度，这才是重点。你也可以使用不同的压缩算法。例如，如果想获得很高的压缩率，又不在乎会花费多少时间，那么，就可以使用bzip2来代替gzip。如果想要非常快的压缩速度，可以使用基于LZO的压缩程序。这样压缩后的数据会比其他方法的结果大20%左右，但是压缩的速度约快5倍。

1.3 避免加密的系统开销

SSH不是跨网传输数据的最快方法，因为它增加了加解密的系统开销。如果不需要加密，那就使用netcat把“裸”数据进行跨网复制。可以通过nc以非交互式操作方式调用这个工具，这正是我们想要的。

这里有一个例子。首先，在server2上监听12345端口（任何闲置的端口都可以)上的文件，把任何发送到该端口的东西都解压缩到期望的数据文件里。

1. server2$ nc -l -p 12345 | gunzip -c - > /var/lib/mysql/mydb/mytable.MYD

然后在server1上，开启另一个如实例，发送数据到目的服务器监听的端口上。-q选项告诉netcat当到达输入文件的末尾后就关闭连接。这会触发监听实例关闭接收的文件并退出。

1. server1$ gzip -c - /var/lib/mysql/mydb/mytable.MYD | nc -q 1 server2 12345

更容易的技术是使用tar，这样文件名称也会通过网络发送出去，从而消除了另一个错 误的来源，并会自动将文件写到正确的位置。z选项告诉tar使用gzip做压缩和解压缩。下面是在server2上执行的命令。

1. server2$ nc -l -p 12345 | tar xvzf -

以下是在server1上执行的命令。

1. server1$ tar cvzf - /var/lib/mysql/mydb/mytable.MYD | nc -q 1 server2 12345

你可以把这些命令集成到一个单独的脚本里，这样压缩和复制大量的文件到网络连接时 效率会比较高，然后在另一端解压缩。

1.4 其他选项

另外一个选择rsync。rsync是非常简便，因为它易于在源和目标之间做镜像，并且还可以断点续传。但是，当它的二进制差异算法无法被很好地发挥时，它不太会得到很好应用。在知道文件中的大部分内容都不需要传输的场景下，例如，如果要续传一个中途退出的nc复制的任务，就可以考虑用它。

在还没有处于危急关头时就应该针对文件传输做一些实验，因为发现哪一种方法最快可 能要做许多试验和遇到许多错误。哪一种方法最快取决于你的系统。其中最大的影响因素是服务器上的磁盘驱动器、网卡和CPU的数量，以及它们之间相对的速度有多快。有个不错的方法是监控vmstat –n 5,看磁盘或CPU是否就是速度的瓶颈。

如果有闲置的CPU,就可能通过运行并行复制操作来加快整个过程。相反，如果CPU已经是瓶颈，而磁盘和网络的承载能力还比较充裕，那就可以不压缩。在导出和还原时，出于速度的考虑，并行执行这些操作往往是个不错的主意。此外，监控服务器性能，看看是否还有闲置的承载能力。过度的并行反而会降低处理速度。

2.     文件复制的基准测试

为了便于比较，表C-1显示的是在局域网里通过一块标准的百兆以太网链路复制一个样 本文件能达到的最快速度。这个文件未压缩时的大小是738MB，使用默认选项压缩后是100MB。源和目的机器都有充足的可用内存、CPU资源和磁盘空间；网络是瓶颈所在。 

注意通过网络发送文件时压缩有多大的帮助——最慢的三个方法并没有压缩文件。尽管 这样，好处也不一。如果CPU和磁盘慢但有一个千兆以太网连接，那么读取和压缩文件可能是瓶颈，不压缩反而更快。 

顺便提一下，使用类似gzip -fast的快速压缩比默认压缩级别要快许多，因为后者要使用许多的CPU时间来对文件多做一点压缩。我们的测试基于默认压缩级别。

传输文件的最后一步是验证复制过程没有损坏文件。可以使用许多方法，例如md5sum但再次对文件做完整扫描也相当昂贵。这也是压缩很有用的另外一个原因：压缩本身往往包括至少一个循环冗余检测（CRC)，而它应该能发现任何错误，因此不需要做错误检测。

这篇关于MySQL大文件传输的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！