MySQL5.5数据库-增量备份与恢复

1.恢复条件

• 增量恢复条件
  人为或程序逻辑的方式在数据库执行的SQL语句等操作，才需要增量恢复，因为从库也执行了误操作语句

• 增量恢复必备条件
  1.开启MySQL log-bin日志功能
  主库和从库都要开启binlog记录功能

  log-bin=/application/mysql/data/mysql-bin
  

  
  2.数据库全备
  参考博文：https://blog.csdn.net/cen50958/article/details/90311769

恢复实践

• 实践环境
  数据库：MySQL5.5 单实例
  数据库库名：study
  表结构:
  
  全量备份数据：
  

2.案例重现

• 零时执行数据全备

   mysqldump -uroot -p123456 -F -B --master-data=2 study|gzip >/server/backup/study.bak_$(date +%F).sql.gz
  

• 写入数据
  

• 执行误操作

   delete from t_user;
  

  

• 误操作后操作数据库

  insert into t_user(user_name,pass_word) values('误操作后数据1','误操作后数据2');
  insert into t_user(user_name,pass_word) values('误操作后数据2','误操作后数据2');
  insert into t_user(user_name,pass_word) values('误操作后数据3','误操作后数据3');  
  update  t_user set user_name ='误操作后更新1' where id=1;
  update  t_user set user_name ='误操作后更新2' where id=2; 
  update  t_user set user_name ='误操作后更新3' where id=4; 
  

  

3.增量数据恢复操作

通过防火墙禁止web等应用向主库写数据或者锁表。让主句暂时停止更新，然后进行恢复（最好操作）

• 检查零时全备
  

• 检查全备后的所有binlog

  ls -lrt /application/mysql/data/mysql-bin.*
  

  

• 找到全量备份时的binlog

  cd /server/backup/
  gzip -d study.bak_2019-05-26.sql.gz 
  grep -i "change" study.bak_2019-05-26.sql
  

  

• 立即刷新并备份出binlog

   mysqladmin -uroot -p123456 flush-logs
  

• 拷贝全量备份时对应的binlog

  cp /application/mysql/data/mysql-bin.000010 /server/backup/
  

• binlog导成sql文件

  mysqlbinlog -d study mysql-bin.000010 >bin.sql
  

• 删除bin.sql中误操作的语句

   vim bin.sql
  

  
  

• 增量恢复数据
  由于在执行备份sql语句时，MySQL会写入bin-log日志，这样在恢复期间的用户操作的bin-log日志无法找到
  A:数据库不对外提供服务恢复方法
  导入全备数据:

  mysql -uroot -p123456 study < /server/backup/study.bak_2019-05-26.sql    
  

  
  导入增量数据:

  mysql -uroot -p123456 study < /server/backup/bin.sql 
  

  

  B:数据库必须对外提供服务恢复方法
  1、停止一个从库,然后再主库刷新binlog,把mysql-bin.000014恢复成bin.sql（去掉误操作语句）
  2、把全备的SQL及误操作前的增量bin.sql回复到从库
  3、把bin.sql恢复到从库
  4、停止主库,快速把mysql-bin00015解析为sql，恢复到从库,让从库提供服务

  缺点：会有短暂的时间数据库无法提供服务