mysqldump用于备份时的参数选项

在用mysqldump备份使用那些参数选项是最完美的组合呢？

--skip-opt

--create-option                       -----------添加create相关的选项

--single-transaction                --------一致性备份

-q                                                --------采用快速的dump方式(提高导出性能)

-e                                                --------采用多重insert语句形式(提高还原性能)，当一个表的数据量很大情况下不知道会不会导致死锁？

--no-autocommit                     -------采用批量提交方式(提高还原性能)

-R                                                 -------导出存储过程，函数，和触发器

--master-data                           -------如果有写log-bin且版本为5.0以上的版本，则再加上 --master-data=2

--events                                      ----如果是5.1以上的版本使用，包含事件

 

 

几个使用mysqldump时的报错

1.mysqldump:Got error:2013

在使用mysqldump的时候（尤其是向NFS上备份的时候），很多人都被'mysqldump:Got error:2013: Lost connection to MySQL server during query when dumping table'的问题困扰，在Manual中对这个问题有一些简单的说明。

解决办法：增加net_write_timeout可以解决上述的问题的

 

2.Mysqldump导出AUTO_INCREMENT列的问题

如果是复制表的结构需要去掉auto_increment的option，可以写个脚本把这个选项去掉

 

3.Mysqldump过程中遇到的Out of Memory问题处理

当DB数据量很大的时候，导出数据可加上-q Option。但是如果用了--skip-opt,那么-q Option必须放在--skip-opt的后面

 

4.如果提高dump文件的导入速度

使用工具按表拆分mysqldump备份文件后并行导入，详细信息如下链接

 

附

是怎么做备份的？

原文意译:

 

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所需要的空间还是差不多的.