ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

MySQL大文件传输

2021-11-18 17:31:45  阅读:180  来源: 互联网

标签:文件 压缩 文件传输 server1 server2 mytable 复制 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

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有