MySQL的备份的一些策略和方法的总结

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）业务需求的容忍度，可量化的目标，根据需求选择停库或锁表或者容忍丢失部分数据。