1.一般使用的是mysqldump来进行备份，每次dump的数据是1000条，并且在这个过程中会进行锁表。
(这种方式是逻辑备份，即直接将数据库中的数据导成sql语句进行备份的过程)
主要的使用方法：
(1).不带参数的进行备份：
备份test数据库中的所有表数据和表结构
mysqldump -uroot -ppassword test >/tmp/test.sql 备份test数据库中的某个表数据和表结构
mysqldump -uroot -ppassword test student >/tmp/test_student.sql
(2).使用-B参数进行备份：（在SQL文件中自动创建原有的数据库名和连接数据库）
备份test数据库中的所有表数据和表结构 使用-B会自动的创建数据库并且使用数据库 mysqldump -uroot -ppassword -B test >/tmp/test.sql
(3).使用-B参数进行多个数据库的备份：
mysqldump --user root --password=myrootpassword -B db_test db_second db_third > db_test.sql
(4).使用gzip进行压缩数据文件进行备份：(使用管道符将数据传给gzip然后进行压缩数据成gz的包)
mysqldump --user root --password=myrootpassword -B db_test db_second db_third |gzip > db_test.sql.gz
(5).使用shell进行分库备份：
mysql -uroot -ppasswd -e "show databases;" |grep -Eiv "database|information|performance"|sed -r 's#^([a-zA-Z_0-9]*$)#mysql -uroot -ppasswd --events -B \1 |gzip> /opt/\1.sql.gz#g'|bash
上面的命令是将mysql中需要的库进行了分库的备份，这种是在遇到比较多的库的时候，我们可以进行分库的备份。
分库的意义何在：
有时一个企业的数据库中会有多个库，例如（bbs，www，blog），但是出问题的时候很可能往往是一个库，那如果我们将所有库的数据保存到一个文件中去，那么将来恢复数据的时候，可能会带来很大的麻烦，所以我们一般将库进行分库备份。
有的时候我们也需要将某个库中的多个表进行分别编程，思想也是和上面的分库备份一致的。
(6).备份mysql数据库的表结构（不包含数据）
mysqldump -uroot -ppassword -d test 参数 -d 的作用就是备份数据库的表结构。
(7).备份mysql的数据库中的数据（不包含表结构）
mysqldump -uroot -ppassword -t test 参数 -t 的作用就是备份数据库的表数据（不包含表结构）。
(8).备份的时候切割binlog日志：（进行增量备份的时候可以用到）
1 mysqldump -uroot -ppassword -t -B -F test
2
3 参数 -F 的作用就是备份数据库的时候，将binlog日志进行重新刷新。
(9).备份的时候会记录指定文件的位置以及mysqlbinglog的文件名称：
mysqldump -uroot -ppassword -t -B -F --master-data test 参数 --master-data=1 的作用就是备份数据库的时候，将binlog日志进行重新刷新。
mysqldump的一些关键参数总结：
1、-B：表示的是指定多个库，增加了建库语句和use数据库的语句。
2、--compact：去掉注释，适合调试输出，不适合在生产环境使用。
3、-A： 表示的是本分所有的库。
4、-F：刷新binlog日志，方便进行增量的恢复。
5、--master-data：增加binlog日志文件名及其对应的位置点。
6、-x，--lock-all-tables ：在备份的时候进行锁表，保持数据的一致性。
7、-d：只备份表的结构。
8、--single-transaction 适合innodb数据库的备份。
Innodb表在备份的时候，通常启用选项--single-transaction 来保证备份的一致性，实际上他的工作原理是设定本次备份的会话级别为：repeattable read ，以确保本次会话dump时，不会看到其他的会话提交了数据。
对于不同的引擎，表的备份数据：
MyISAM:
mysqldump -uroot -ppassword --flush-privileges -A -B --master-data=2 -x --flush-logs --triggers --routines --events --hex-blob |gzip > /opt/all.sql.gz
InnoDB:
mysqldump -uroot -ppassword --flush-privileges -A -B --master-data=2 --single-transaction --flush-logs --triggers --routines --events --hex-blob |gzip > /opt/all.sql.gz
推荐使用InnoDB的备份方式，备份数据。(--triggers 表示的是触发器)
企业场景全量和增量的频率是怎样做的呢？
1）中小公司，全量一般是每天一次，业务流量低谷执行的是全备，备份时会锁表。
2）单台数据库，如和增量。使用rsync（配合定时任务频率大点或者inotify，主从复制），把所有的binlog备份到远程服务器，尽量做主从复制。
3）大公司周备，每周六00点一次全量，下周日-下周六00点前都是增量。
优点：节省备份时间，减小备份压力。缺点：增量的binlog文件副本太多，还原会很麻烦
4）一主五从，会有一个从库做备份，延迟同步。
什么情况下会用到备份呢？
1) 需要升级数据库或者是需要增加一个从库的时候。
2）主库或者从库宕机，需要数据的备份。
3）人为的DDl或者是DML的语句，导致主从库的数据消失
4）跨机房的灾备，需要备份数据到远端程序。
什么情况下才会用到增量恢复呢？
1）主或者从库宕机（硬件损坏）是否需要增量恢复？
答：不需要增量恢复，主库宕机，只需要把其中的一个同步最快的从库提升为主库即可。
主库宕机，只要选择更新最快的从库，提升为主库即可
从库宕机，直接不用就好了（一般都会陪LVS负载均衡），或者就正常修复即可
2）人为操作数据库SQL语句破坏主库是否需要增量恢复？
在数据库主库内部命令行进行误操作，会导致所有的数据库（包括主从库）的数据丢失，例如：在主库执行了drop database test这样的删除语句，这时候所有的从库也会执行这个drop语句，从而导致所有的数据库上的数据库的数据丢失，这样的场景下面需要进行增量恢复的。
3）只有一个主库是否需要增量恢复呢？
如果公司只有一个主库的情况下，首先应该做定时的全量备份（每天一次）以及增量备份（每隔1-10分钟对binlog日志做切割然后被分到其他的服务器上，或者本地其他硬盘中）或者写到网络文件系统中。
使用binlog进行增量备份以及查看文件数据的方法：
/data1/mysql/bin/mysqlbinlog -uroot -psina.com mysql-bin. > bin.sql 我们也可以同时进行拆库的分析，使用-d参数即可指定数据库进行拆分
/data1/mysql/bin/mysqlbinlog -uroot -psina.com -d test mysql-bin. > bin.sql
是可以导成SQL语句进行查看的。
增量恢复的前提：
1）人为的SQL造成的误操作。
2）需要全备和增量的数据。
3）恢复时建议对外停止更新。
4）恢复的时候，先恢复全量，再把增量日志中有问题的SQL语句删除，然后恢复到数据库。
增量恢复的核心思想：
1）流程制度的控制。如果不做，面临服务和数据，鱼和熊掌不可得。
2）延迟备份来解决，通过监控，加白名单的方式进行控制。
3）业务需求的容忍度，可量化的目标，根据需求选择停库或锁表或者容忍丢失部分数据。