mysql全量备份与增量备份

Posted 2021-01-10 时光浅夏wk

一、全量备份

全量备份就是把数据库中所有的数据进行备份。

备份所有库：

mysqldump -uroot -p456 -S /data/3306/mysql.sock -F -A -B |gzip >/server/backup/mysqlbak_$(date+%F).sql.gz

备份一个库：

mysqldump -uroot -p456 -S /data/3306/mysql.sock -F -B oldboy|gzip >/server/backup/mysqlbak_$(date+%F).sql.gz

二、增量备份

从上次全备之后，到下次全备之前更新的新数据。对于mysql来说，binlog日志就是mysql的增量数据。

1）按天备份

周一00点全量备份	周二00点全量备份
01.sql.gz	02.sql.gz
周一增量备份	周二增量备份
mysql-bin.000021 mysql-bin.000022 mysql-bin.000023 ...	mysql-bin.000035 mysql-bin.000036 mysql-bin.000037 ...

 

 

 

 

 

 

优点：

恢复时间：短，维护成本：低

缺点：

占用空间：多，占用资源：多，经常锁表影响用户体验

2）按周备份

周六00点全量备份
01.sql.gz
周一增量备份	周二增量备份	周三增量备份
mysql-bin.000021 mysql-bin.000022 mysql-bin.000023 ...	mysql-bin.000035 mysql-bin.000036 mysql-bin.000037 ...	mysql-bin.000043 mysql-bin.000044 mysql-bin.000045 ...

 

 

 

 

 

 

优点：

占用空间：小，占用资源：少，无需锁表用户体验相对好

缺点：

恢复时间：长、复杂，维护成本：高

三、从企业的角度看全量和增量

1）对于中小公司，全量一般每天一次，在业务量低估时执行全备并锁表。

2）对于单台数据库如何实现增量。利用rsync（配合定时任务频率高点，或者inotify主从复制）把所有binlog备份到远程服务器。但是尽量还是要做主从复制！

3）对于大公司，有可能会做周备，其他时间都是增量。

4）一主多从，会有一个从库做备份，延迟同步。

需要mysql的mysqldump全量备份场合：

迁移或升级数据库；

增加从库的时候；

由于硬件或异常情况导致的主库或从库宕机，主从可互相切换，无需备份；但是由于人为操作导致主库误删，主从都会执行，此时需要备份；

做跨机房灾备，需要全量备份到异地。

需要mysql的增量恢复场合：

人为操作导致主库误删（如drop），主从都会执行，此时需要增量备份；

只有一个主库的情况下需要增量恢复；

四、实战模拟误操作导致数据丢失进行恢复

思路一：

mysql -uroot -p456 -S /data/3306/mysql.sock 

mysql> use oldboy

mysql> show tables;

mysql> select * from student;

mysql> quit

date -s ‘2018/10/05‘

history |grep mysqld

mysqldump -uroot -p456 -S /data/3306/mysql.sock -F -B --master-data=2 oldboy|gzip >/server/backup/bak_$(date+%F).sql.gz      #假设现在是00点，一般全量备份只要指定为master-data=2，master-data的作用就是为拿到开始恢复的位置点，以便后面的增量备份有所依据，其他全备已存在不用更新；建立从库才需要指定master-data=1告诉从库从主库的哪个位置进行更新，只需做全备无需增量备份。最好记录切割前的mysql-bin位置点（可以通过锁表看下master.info中记录的信息）   

mysql -uroot -p456 -S /data/3306/mysql.sock 

mysql> use oldboy

mysql> desc student;

mysql> insert into student(name) values(‘oldboy101‘);

mysql> insert into student(name) values(‘oldboy102‘);       #模拟00点到早上10点的增量

mysql> select * from student;

mysql> drop database oldboy;  #模拟早上10点做的误操作，应用开始出现故障

mysql> quit

通过防火墙禁止web等应用向主库写数据或者主库锁表，让主库暂时停止更新，进行数据恢复

ll /server/backup

gzip -d bak_2018-10-05.sql.gz

grep -i "change" bak_2018-10-05.sql   #如果先前忘记查看位置点，可以尝试在此找到，假设为000014

mysqladmin -uroot -p456 -S /data/3306/mysql.sock flush-logs   #刷新binlog，将恢复的目标定到上步找到的位置，下面一个binlog则是新产生的了

cd /data/3306/

cp mysql-bin.000014 /server/backup/

cd /server/backup/

mysqlbinlog -d oldboy mysql-bin.000014 >bin.sql

vi bin.sql  将drop database oldboy这句删掉，并保存文件

mysql -uroot -p456 -S /data/3306/mysql.sock

mysql -uroot -p456 -S /data/3306/mysql.sock <bak_2018-10-05.sql

mysql -uroot -p456 -S /data/3306/mysql.sock oldboy <bin.sql

mysql -uroot -p456 -S /data/3306/mysql.sock 

mysql> use oldboy

mysql> select * from student;   #发现恢复成功

{补充：

mysql> show variables like ‘%log_bin%‘;    #有个参数sql_log_bin，如果关掉此参数，则利用mysqldump进行恢复的时候，就不会记录新的binlog日志mysql-bin.000015中}

思路二：

1.停止一个从库，然后在主库刷新binlog，把mysql-bin.000014恢复成bin.sql（去掉drop语句的）

2.把全备bak_2018-10-05.sql及10点前的增量bin.sql恢复到从库

3.此时数据丢失多少？10点刷新binlog以后的数据，即mysql-bin.000015

4.停止主库，快速把mysql-bin.000015解析为SQL，恢复到从库    #避免主键冲突问题，尽量使停库时间缩到最短，尽量减少应用停止的时间

5.切换到从库提供服务

>>>增量恢复小结：

人为SQL造成的误操作；

需准备全备和增量；

恢复时建议对外停止更新；

恢复全量，然后把增量日志中有问题的SQL语句删除，恢复数据库

>>>增量恢复的核心思想：

流程制度控制，否则将面临服务和数据故障的风险；

可以通过延迟备份来解决，或者通过监控，或者通过制定黑、白名单（where子句）机制来控制；

选择停库修复，定义可量化的目标，满足业务需求的最低限制。

 五、mysqlbinlog

作用：解析mysql的binlog日志 （mysql-bin.0000XX，mysql-bin.index记录了所有mysql-bin文件）

mysql内部增删改查等对mysql数据库有更新记录的文件——mysql-bin文件

-d 指定单独的数据库恢复（适用于对单个库做了误操作，只需恢复此库的备份恢复操作）

--start-position --stop-position 指定位置恢复     mysqlbinlog mysql-bin.000020 --start-position=365 --stop-position=456 -r pos.sql

--start-datetime --stip-datetime 指定时间点恢复  mysqlbinlog mysql-bin.000020 --start-datetime=‘2018-10-06 15:00:00‘ --stop-datetime=‘2018-10-06 15:09:00‘ -r time.sql

 

思考：

mysql出现同步延迟原因是什么？如何解决？   当主库的TPS并发较高时，产生的DDL(修改类的sql语句)数量，超过了slave机器sql线程所能承受的能力，那么延时就会产生了。

数据库的读写分离软件，mysql-proxy和amoeba；

了解mysql高可用MMM技术；

mysql半同步应用，xtrabackup物理备份

mysql+heartbeat+drbd高可用          http://blog.51cto.com/oldboy/1240412