终于来了,Percona发布XtraBackup for MySQL 8.0

在下文所有的废话之前,先说正事:

Percona在9月12日,终于宣布第一个测试用的XtraBackup for MySQL 8.0版本给大家试用:

（复制链接打开）https://www.percona.com/blog/2018/09/12/announcement-experimental-build-of-percona-xtrabackup-8-0/

MySQL 8.0今年4月份GA以来,虽然大家多有测试,但实际上敢用到生产环境的,只是极少数.而我个人认为最重要的原因之一,就是缺乏一个可用的备份工具.而在MySQL备份这件事情上,功德无量的Percona公司,却迟迟没有见到发布针对MySQL 8.0的备份工具,着实让人着急.

在9月12日之前,已知的MySQL 8.0的备份方式有这些:

1. 官方MySQL商业版备份工具. 这个名为 MySQL Enterprise Backup 的软件,是官方商业版本的一部分,如果需要用,得掏钱买授权.先不说用的人比较少,使用文档本身也不在 MySQL 的公开文档导致学都很繁琐,就只是照着实例数收钱这点,就断绝了现在这种千库万表的 MySQL 大规模部署形势下的使用.
2. 使用mysqldump命令.mysqldump 本身只是导出数据的命令行工具,但结合事务选项,以及master data选项,就可以导出满足一致性的备份SQL文件,即原生,又省心省力,对于小型数据库来说,是非常不错的选择(这里的小型,一般指的是100GB以下的数据库),但对于非常大个头的数据库来说,一来mysqldump是单线程导出,速度比较慢,说不定得搞一天,又由于MySQL的事务可见性的要求,undo文件会被执行导出的事务一直拖着不让缩小(如果没有使用独立表空间,那问题就更严重了–ibdata1过大的问题早年困扰不知多少DBA),导致磁盘空间比较大.而另外一个比较少遇到,但遇到就非常心碎的问题是,由于导出的是单个文本文件,如果文本文件中,某一个字节的存储出现问题,那么整个数据库的恢复就到此为止了.
3. FLUSH TABLES WITH READ LOCK;见过很多以为备份数据库就是把数据文件直接复制走的哥们,如果他们在复制文件前,使用命令停掉所有的写入,之后再复制,也不能说人家有问题,奈何大部分人就是少这一步,而且,考虑到8.0开始,授权表都是innodb了,如果不小心,导致授权表损坏了,那可真是苦都没地方哭了.
4. 考虑到很多人的备份不追求事务一致性,但速度要快,这种情况下,还有两个工具可以用,一个是mysql自带的mysqlpump,和 mysqldump 不同,mysqlpump支持表级别的并行导出,加快了导出速度,但放弃了事务的一致性要求.而mydumper则是早年,社区开发的一款并行导出MySQL数据的命令行工具,可以在一个表上,发起多个基于主键(或者唯一键)分区的并行导出,速度更快.
5. 备份是为了恢复,恢复就要讲究恢复时间,那怎么样加快数据的恢复时间呢?那就是MySQL复制给出的答案: 建立一个开启了延迟备份的从库,在需要恢复数据到指定时间点的时候,直接用start slave until命令搞定. 注:个人建议是,对重要数据库,以及超大数据库(比如1TB以上的),都使用这种方式,来降低恢复时间,参考官方文档:（复制链接打开） https://dev.mysql.com/doc/refman/8.0/en/replication-delayed.html
6. 既然说起从库,那么在从库上,就可以很方便地搞备份了,比如搞一个没有业务访问的从库,需要备份的时候,停掉slave(政治正确的叫法是replication)线程,然后用前面提到的方式3,4进行备份,也不是不可以,或者说,考虑到主库需要承担访问压力,这种备份方式从效率和一致性,以及对线上业务扰动综合看,实际上是非常好的一个方式.
7. 数据文件存在磁盘上,既然方式3可以用cp命令拷贝,实际上就是允许使用所有文件系统/块设备/存储设备的快照备份了,只要记得执行前后FLUSH TABLES WITH READ LOCK;,那备份就有保障了.

我故意漏掉了myisam这过时玩意的备份恢复的手段,估计没人看也应该没人用,就不写了.

在前面列举的种种备份中,最理想的,实际上就是MySQL Enterprise Backup这种,所谓真正的热备份,在备份效率,与备份的一致性,安全性等方面,都是非常好的选择,开源世界中,对应的就是 XtraBackup.

这里也不多说XtraBackup本身的意义与使用方式,估计用MySQL的DBA,没有几个没有折腾过这玩意的,下文主要讨论的,还是Xtrabackup for MySQL 8.0.

首先看看Percona公司自己的说法(以下为作者提取的重点,原文参考前面的链接地址):

1. 虽然已经发布了,但版本号是 8.0.1,并且提示为实验性质的(experimental)alpha版本.
2. innobackupex命令终于被彻底删除,宣告一个时代的正式落幕,当然,也宣告着,很多MySQL自动化备份脚本需要改了.
3. 由于MySQL 8.0数据目录,以及redo格式的种种变化,新的Xtrabackup for MySQL 8.0,仅仅提供给MySQL 8.0(以及Percona自己基于MySQL 8.0改的Percona Server),对于5.x版本,依然需要使用XtraBackup 2.4来备份,当然,也宣告着,很多MySQL自动化备份脚本需要改的地方更多了.
4. 目前提供支持的操作系统版本为(其中Ubuntu 14.04 Trusty以及Debian 8 Jessie后续可能不再支持):

• RHEL/Centos 6.x
• RHEL/Centos 7.x
• Ubuntu 14.04 Trusty*
• Ubuntu 16.04 Xenial
• Ubuntu 18.04 Bionic
• Debian 8 Jessie*
• Debian 9 Stretch

5. 如果需要下载,需要从Percona的repo源中下载,没有单独的下载地址(打算从官方软件下载页面找进去的同志可以放弃了): centos 7 http://repo.percona.com/experimental/7/RPMS/x86_64/percona-xtrabackup-80-8.0.1-1.alpha.el7.x86_64.rpm centos 6 http://repo.percona.com/experimental/6/RPMS/x86_64/percona-xtrabackup-80-8.0.1-1.alpha.el6.x86_64.rpm 至于其他发行版的同志,可以参考 https://www.percona.com/doc/percona-repo-config/index.html 这个地址的方法进行设置并下载

使用方法还是没有变化,想要试一把的同志,可以开搞了.

原创：刘伟。

投稿：有投稿意向技术人请在公众号对话框留言。

转载：意向文章下方留言。