码迷,mamicode.com
首页 > 数据库 > 详细

mysql全量备份与增量备份

时间:2018-10-06 16:43:43      阅读:202      评论:0      收藏:0      [点我收藏+]

标签:半同步   其他   火墙   datetime   机房   补充   info   恢复操作   备份   

一、全量备份

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

备份所有库:

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

mysql全量备份与增量备份

标签:半同步   其他   火墙   datetime   机房   补充   info   恢复操作   备份   

原文地址:https://www.cnblogs.com/wangke2017/p/9745183.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!