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

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

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

XtraBackup支持流式备份,将备份以指定的tar或xbstream格式发送到STDOUT,而不是直接将文件复制到备份目录。要使用此功能,仅需要使用 --stream选项即可。流传输功能允许您使用其他程序来过滤备份的输出,为备份的存储提供更大的灵活性。例如,压缩是通过将输出管道输送到压缩实用程序来实现的。流式备份和使用Unix管道的优点之一就是备份可以被自动加密。

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

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

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

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

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

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

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

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

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

1. xbstream压缩备份实例

将备份解压

2. tar压缩备份实例

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

可以选择的压缩方式

重定向日志输出文件

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

最后推荐多线程压缩工具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%左右,不知道是否因为数据库的特性。有兴趣可以测测普通文件看看。

<参考>

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


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

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