[译]Facebook是怎么做MySQL备份的?

原文意译:http://www.facebook.com/note.php?note_id=10150098033318920
转载请注明下,谢谢..

Facebook的用户每天创造大量的数据，为了确保数据可靠的存储，我们每天进行数据备份.我们通过将原来的逻辑备份改成定制化的物理备份,显著地提升了备份的速度(不增加体积的情况下).

从mysqldump到xtrabackup
我们使用mysqldump来进行每日的数据库备份,mysqldump对数据进行逻辑备份,就像应用访问数据库那样,mysqldump以SQL语句的方式从数据库中读取一张张表,将表结构和数据转保存到文本文件.mysqldump最大的问题是速度太慢(对于我们的一些大的数据库,通常要花24小时,甚至更久),并且以SQL语句的方式读取数据可能造成磁盘的随机读,这就会造成主机的load增大,影响性能.对于时间太长,我们可以跑多个实例来并发的做备份,这能缩短备份的时间,但是会造成更多的load,更影响主机的性能.

另外一个可行的备份方式是进行物理备份(我们称之为二进制备份,binary backup),通过操作系统层面,读取数据库磁盘文件,而非通过SQL语句.这样的话在备份的过程中,数据不能像SQL读取的时候保持事务上一致的.只有当备份的数据文件在数据库里复原了,他们才又一致了,这类似于数据库down掉之重启一样.

我们通过修改增强xtrabackup来满足我们额外的需求:
1.支持快速的表级还原
2.增强全量和增量备份
3.支持混合增量备份

xtrabackup支持增量备份,也就是备份自上次全量备份后改变的数据.这样我们就能够减少备份的空间(比如每天一次增量备份,每周一次全量备份).xtrabackup也支持多级增量备份,不过我们不使用,避免复杂.

1.表级还原
我们写了一个PHP脚本,来从二进制备份文件中读取并还原指定的表.当前,这个脚本还不能自己从备份文件中读取信息创建表结构,因此必须事先准备好一个对应的空的表.我们对xtrabackup也做了相应的修改来支持这个工具.这个修改就是支持xtrabackup导入导出单表.单表的还原比全量还原快得多,因为只需要从文件中读取相应的表的信息.

2.调整全量和增量复制
fb是xtrabackup早期的增量备份功能的用户,起初对于一些有大量表的数据库，xtrabackup的增量备份不起作用.后来我们和percona一起解决了这些问题.
xtrabackup只有本地增量备份功能,也就是说增量备份的文件必须要和mysql在同台主机上.我们修改使之支持远程增量备份,也就是通过类似管道的方式将备份的数据同时发送到远程主机,.如果先在本地做增量备份,然后通过网络传到远程主机,对我们来说是不可取的,因为会大大增加本地的写操作.
xtrabackup以1MB为1个chunk来读取数据库文件,我们发现使用8MB时,能够使增量备份的速度快一倍,使全量备份快40%.

3.让增量备份成为真正的增量
xtrabackup的增量备份读取数据库的每个page,来判断哪些page改变了.我们创建了一个page追踪器,通过读取事务日志,并且通过每个表的bitmap,来追踪修改过的page,.这样我们就能很好的追踪哪些page改变了哪些没变,我们就可以只读取那些改变过的page.我们称这位真正的增量备份.
不过讽刺的是,我们发现这种真正的增量备份比普通的增量备份反而来的慢..这是因为普通的增量备份用8MB的chunk来读取文件,而真正的增量备份读取文件的大小是不定的,从16KB(INNODB中一个page的大小)到8MB,这取决于有多少连续的page是被修改过的.因此在我们的很多场景下(自上次全量备份后大概10%-30%的page修改了),真正的增量备份比普通的增量备份花了更多的IO调用.
因为我们进行了改进,有了一种混合增量的备份，通过避免读取未修改的page来减少IO次数,在我们的场景下,这种混合增量备份减少了20%-30%的IO,IO的大小从16KB到8MB不等.

下表描述了使用上述改进的方法来处理大概750GB数据时产生的不同结果.由于mysqldump速度的原因,mysqldump只在少数几个数据库上跑,我们使用gzip来对mysqldump的结果进行压缩,很慢,但是压缩率很高.
QPress用来压缩二进制备份,它比gzip快多了,但是压缩效率更低.由于我们经常作增量备份,较少作全量备份,整个二进制备份所需要的空间和mysqldump所需要的空间还是差不多的.

In mysql. You can leave a response, or trackback from your site.