数据库
首页 > 数据库> > 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资源和磁盘空间;网络是瓶颈所在。 

 

表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),而它应该能发现任何错误,因此不需要做错误检测。

 

标签:文件,压缩,文件传输,server1,server2,mytable,复制,MySQL
来源: https://www.cnblogs.com/lizexiong/p/15573424.html