注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MySQL备份恢复:Xtrabackup流传输实践

MySQL 彭东稳 2338次浏览 已收录 0个评论

XtraBackup支持流式备份,将备份以指定的tarxbstream格式发送到STDOUT,而不是直接将文件复制到备份目录。要使用此功能,仅需要使用--stream选项即可,指定流格式为tar或xbstream,以及指定存储临时文件的绝对路径。

innobackupex在子进程中以--log-stream模式启动xtrabackup,并将其日志重定向到临时文件。然后它使用xbstream将所有数据文件以特殊的xbstream格式流式传输到STDOUT。详情请参阅xbstream二进制文件。在完成将所有数据文件流式传输到STDOUT之后,它会停止xtrabackup并传输保存的日志文件。

流传输功能允许你使用其他程序来过滤备份的输出,为备份的存储提供更大的灵活性。例如,压缩是通过将输出管道输送到压缩实用程序来实现的。流式备份和使用Unix管道的优点之一就是备份可以被自动加密。

在使用传统备份模式下,不得不考虑以下问题:

1. 占用本地一倍磁盘空间(当然,你也可能直接使用NFS、SAMBA这样的文件共享服务器来备份)。

2. 如果使用共享文件系统来备份,又面临速度太快,把MySQL服务器网卡跑满的情况(我就遇到此问题)。

3. 备份文件传输到远程服务器后还得做压缩处理。

由于以上问题,就可以考虑使用流备份,利用好的情况下可以解决以上问题:

1. 使用流传输模式,通过管道传输给压缩备份程序,如gzip、pigz。

2. 如果使用共享文件系统来备份,把实时压缩文件直接存储到共享文件系统上,由于需要经过压缩处理,所以不会造成MySQL服务器网卡跑满的情况。

PS:以上考虑的更多是利用共享文件系统来备份的情况下,如何优雅解决相关问题,而不是备份到本地。

XtraBackup流传输备份使用方式有如下几种:

1. xbstream压缩备份实例

将备份解压

2. tar压缩备份实例

将tar存档文件发送到另一个主机

可以选择的压缩方式

重定向日志输出文件

PS:上面基本都是针对整个实例完全备份来阐述的,可能你的需求并不一样,比如有完整备份和增量备份,具体是否支持和怎么操作需要看官方文档。

再来说一说使用流传输备份时,tar和xbstream的不同点。使用tar备份时,直接可以使用tar命令解压(tar xvf *.tar.gz),但不支持增量备份模式。可以直接写成下面这种格式:

当使用xbstream作流式备份选项时,可以并行复制和压缩备份,从而大大加快备份过程。如果备份是压缩和加密,首先需要解密,以便不被压缩。支持增量备份模式,但是标准输出需要使用xbstream工具。一般写成如下格式:

解压的话就需要先使用gzip工具解压,然后在使用xbstream工具标准输出。

更多时候可能会需要增量备份,并且是流传输格式,这个时候需要用到innobackupex另外一个参数--extra-lsndir,这个参数用来指定xtrabackup_checkpoints文件的备份位置,这个文件存储着此次备份方式和结束LSN(to_lsn),这个LSN就是下次增量备份的起始位置。

增量备份时使用--incremental-basedir指定--extra-lsndir指定的位置即可。

其实--incremental-basedir参数会去xtrabackup_checkpoints文件找to_lsn参数对应的LSN号,你也可以使用--incremental-lsn参数手动指定to_lsn对应的LSN号,都是一样的。

最后推荐多线程压缩工具pigz,压缩那是非常快。下面是我某个环境备份方式。有一点需要说明的是,我的MySQL本地/backup目录挂载的是一个文件共享服务器的目录,所以我本地是不存放备份文件的,都是实时传输到文件服务器上。

另外,在这个备份模式下,下面是我在压测的一些数据,仅供参考。服务器配置是128G,40H,千兆,SSD,虽然这个并不重要。

数据大小 xtrabackup线程数 pigz压缩比 pigz线程数 压缩后大小 压缩比 CPU负载 网卡带宽 整体备份时间
100G 4 -9 2 16G 84% 2 <100M 130分钟
100G 4 -6 2 16G 84% 2 几兆到几百兆,忽大忽小,最大带宽未超过500M 30分钟
100G 4 -3 2 18G 82% 2 几兆到几百兆,忽大忽小,最大带宽偶尔能跑满网卡 15分钟
100G 4 -6 4 16G 84% 4 几兆到几百兆,忽大忽小,最大带宽偶尔能跑满网卡 18分钟
580G 4 -9 2 68G 88% 4 <100M 420分钟
580G 4 -9 4 68G 89% 4 几兆到几百兆,忽大忽小,最大带宽未超过500M 220分钟
580G 4 -6 2 70G 88% 2 几兆到几百兆,忽大忽小,最大带宽未超过500M 120分钟
580G 4 -6 4 70G 88% 4 几兆到几百兆,忽大忽小,最大带宽偶尔能跑满网卡 70分钟

在这份模拟报告中,我需要关心xtrabackup线程数、pigz压缩比、pigz线程数的不同对压缩比、CPU负载、网卡流量,以及整体备份时间(压缩加传输)的差别。由于我是挂载的文件共享服务器,所以我可能特别需要关心一下网卡带宽,确保不能把MySQL服务器网卡跑满了,导致其他服务无法正常运行。所以我需要平衡备份时间和网卡流量,找一个折中点,把控好压缩比和压缩线程,不能过快。

最后,从报告上可以看出,我们pigz压缩比-9与-6压缩后的数据时一样大的,而-6比-9快80%左右,不知道是否因为数据库的特性。有兴趣可以测测普通文件看看。

对于网卡IO限速的工具,没有找到好用的,如果有好的工具推荐欢迎留言。但是我知道Unix下有一个pv(Pipe Viewer)命令,通过管道显示数据处理进度的信息。这些信息包括已经耗费的时间,完成的百分比(通过进度条显示),当前的速度,全部传输的数据,以及估计剩余的时间等等。所以可以很好地监视系统状态,复制、移动、删除文件,命令执行进度等。要使用PV,需要配合合适的选项,把它放置在两个进程之间的管道,命令的标准输入将会通过标准输出传进来的,而进度会被输出到标准错误输出。

接下来,pv还有一个命令行选项,就是“-L”,可以让你修改 pv 命令的传输速率。配置innobackupex使用,我们举个例子:

这里限制传输速度为2M,可以自己尝试尝试。

<参考>

https://yq.aliyun.com/articles/419618


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (0)or分享 (0)
关于作者:

您必须 登录 才能发表评论!