在用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的后面
附
FaceBook是怎么做备份的？
原文翻译：http://www.stor.com.cn/mysql/201308/328.html
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所需要的空间还是差不多的。
2014-07-13 16:37:37