在管理MySQL、初始化服务器、克隆复制和进行备份/还原操作时，复制、压缩和解压缩大文件（常常是跨网络的）是很常见的任务。能够最快最好完成这些任务的方法并不总是显而易见的，并且方法好坏的差异可能非常显著。这个附录将通过几个例子演示使用常见的UNIX实用工具，将一个大尺寸的备份镜像从一台服务器复制到其他服务器。
通常从未压缩的文件开始，例如一台服务器上的InnoDB表空间和日志文件。当然，在把文件复制到目的地之后要再将它解压缩。另外一个常见的场景是以压缩文件开始，例如备份镜像文件，以解压文件结束。
如果网络传输能力有限，那么用压缩格式在网络间发送文件是个好方法。你可能还需要一个安全的传输途径，使数据不会被损坏；这对于备份镜像文件来说，是一个很常见的需求。
1.复制文件
这个任务实际上就是完成以下事情。
1.(可选）压缩数据。
2.发送到另外一台机器上。
3.把数据解压缩到最终目的地。.
4.在复制完成后，校验文件以确认其没有被损坏。
我们对能达成这些目标的一系列方法进行了基准测试。
对于在本书里讨论过的很多目的，例如备份，你可能要考虑在哪一台机器上做压缩会更好一点。如果有足够的网络带宽，还是复制未压缩形式的备份镜像文件为好，这样可以在MySQL服务器上节省出CPU资源供査询使用。
1.1 一个简单的示例
我们以1个简单的示例开始，安全地将一个未压缩的文件从一台机器发送到另外一台上，途中将它进行压缩，然后再解压。在称为server1的源服务器上，执行如下命令。
server1$ gzip -c /backup/mydb/mytable.MYD > mytable.MYD.gz
server1$ scp mytable.MYD.gz root@server2:/var/lib/myql/mydb/
然后，在server2上执行如下命令。
server2$ gunzip /var/lib/mysql/mydb/mytable.MYD.gz
这大概是最简单的实现方法了，但效率并不高，因为涉及压缩、复制和解压缩等串行化的步骤。每一个步骤都需要读/写磁盘，速度比较慢。上述命令的真正操作依次是这样的：在server1上gzip既要读又要写，scp在server1上读而在server2上写；gunzip在server2上既要读又要写。
1.2 一步到位的方法
下面这个方法更有效率一些，它将压缩、复制文件和在传输的另一端解压缩文件全部放在一个步骤里完成。这一次我们使用SSH，SCP就是基于这个安全协议的。下面是在server1上执行的命令。
server1$ gzip -c /backup/mydb/mytable.MYD | ssh root@server2"gunzip -c - > /var/lib >/mysql/mydb/mytable.MYD"
这个方法通常比第一个方法好，因为它极大地降低了磁盘I/O:磁盘活动被减少到只要在server1上读，在server2上写。这也使得磁盘操作更加有序。
也可以使用SSH内建的压缩来完成，但是我们展示的是用管道来做压缩和解压缩，这是因为这样能给予你更大的灵活性。例如，假如你不想在另一端解压缩文件，就无法使用SSH的压缩。
可以通过调整一些选项来提髙这个方法的效率，例如给gzip增加选项-l，使其压缩得更快。这个选项通常不会降低太多压缩率，但是能明显提髙压缩速度，这才是重点。你也可以使用不同的压缩算法。例如，如果想获得很高的压缩率，又不在乎会花费多少时间，那么，就可以使用bzip2来代替gzip。如果想要非常快的压缩速度，可以使用基于LZO的压缩程序。这样压缩后的数据会比其他方法的结果大20%左右，但是压缩的速度约快5倍。
1.3 避免加密的系统开销
SSH不是跨网传输数据的最快方法，因为它增加了加解密的系统开销。如果不需要加密，那就使用netcat把“裸”数据进行跨网复制。可以通过nc以非交互式操作方式调用这个工具，这正是我们想要的。
这里有一个例子。首先，在server2上监听12345端口（任何闲置的端口都可以)上的文件，把任何发送到该端口的东西都解压缩到期望的数据文件里。
server2$ nc -l -p 12345 | gunzip -c - > /var/lib/mysql/mydb/mytable.MYD
然后在server1上，开启另一个netcat实例，发送数据到目的服务器监听的端口上。-q选项告诉netcat当到达输入文件的末尾后就关闭连接。这会触发监听实例关闭接收的文件并退出。
server1$ gzip -c - /var/lib/mysql/mydb/mytable.MYD | nc -q 1 server2 12345
更容易的技术是使用tar，这样文件名称也会通过网络发送出去，从而消除了另一个错误的来源，并会自动将文件写到正确的位置。z选项告诉tar使用gzip做压缩和解压缩。下面是在server2上执行的命令。
server2$ nc -l -p 12345 | tar xvzf -
以下是在server1上执行的命令。
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资源和磁盘空间；网络是瓶颈所在。
| 表C-1:跨网复制文件的基准测试 | |
| 方法 | 时间(s) |
| rsync,不使用压缩 | 71 |
| scp,不使用压缩 | 68 |
| nc,不使用压缩 | 67 |
| rsync,使用压缩（-z） | 63 |
| gzip,scp和gunzip | 60（40+10+6） |
| ssh，使用压缩 | 44 |
| nc,使用压缩 | 42 |
注意通过网络发送文件时压缩有多大的帮助——最慢的三个方法并没有压缩文件。尽管这样，好处也不一。如果CPU和磁盘慢但有一个千兆以太网连接，那么读取和压缩文件可能是瓶颈，不压缩反而更快。
顺便提一下，使用类似gzip -fast的快速压缩比默认压缩级别要快许多，因为后者要使用许多的CPU时间来对文件多做一点压缩。我们的测试基于默认压缩级别。
传输文件的最后一步是验证复制过程没有损坏文件。可以使用许多方法，例如md5sum但再次对文件做完整扫描也相当昂贵。这也是压缩很有用的另外一个原因：压缩本身往往包括至少一个循环冗余检测（CRC)，而它应该能发现任何错误，因此不需要做错误检测。