MySQL 数据库备份（增量备份与恢复）

Posted 2021-11-23 姜姜是美女

文章目录

• 前言
• 一、MySQL增量备份
• • 1.增量备份的特点
  • 2.二进制日志对备份的意义
  • 2.增量备份示例
• 二、MySQL增量恢复
• • 1.增量恢复的场景
  • 2.丢失完全备份之后更改的数据的恢复步骤
  • 3.完全备份之后丢失所有数据的恢复步骤
  • 4.基于时间点与位置的恢复
  • ①基于时间点的恢复
  • ②基于位置操作
• 总结

前言

前面说了完全备份有两种方式，一种是使用tar打包数据文件，另一种是使用mysqldump进行完全备份，完全备份存在的问题很容易看到，每次都是把所有的数据内容进行备份，备份数据中有大量的重复数据，并且完全备份的时间与恢复的时间很长，解决完全备份存在的问题就是使用增量备份的方式，增量备份就是备份自上一次备份之后增减或改变的文件或者内容

一、MySQL增量备份

增量备份是在完全备份的基础上，减少备份文件的大小，从而加快备份和恢复的速度

1.增量备份的特点

• 优点：没有重复数据，备份量不大，时间短
• 缺点：需要上次完全备份及完全备份之后所有的增量备份才能恢复，而且对所有增量备份进行逐个反推恢复，操作较为繁琐
• MySQL没有提供直接的增量备份方法，可以痛过二进制文件间接实现增量备份

2.二进制日志对备份的意义

• 二进制日志保存了所有更新或者可能更新数据库的操作
• 在启动MySQL服务器后开始开始记录，并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件
• 只需要定时执行flush logs方法重新创建新的日志，生成二进制文件序列，并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份

2.增量备份示例

①开启二进制日志功能

vim /etc/my.cnf

...
[mysqld]
log-bin=mysql-bin
binlog_format = MIXED
#指定二进制日志(binlog)的记录格式为 MIXED（混合输入）


systemctl restart mysqld.service
#重启服务

cd /usr/local/mysql/data
ls -l /usr/local/mysql/data/mysql-bin.*
#查看二进制文件


#二进制日志(binlog)有3种不同的记录格式：STATEMENT(基于SQL语句)、ROW(基于行)、MIXED(混合模式)
#默认格式是 STATEMENT

②每周选择服务器负载较轻的时间段，或者用户访问较少的时间段进行备份

mysqldump -uroot -p123123 puxin xjj > /opt/puxin_xjj_$(date +%F).sql
#对表进行完全备份

mysqldump -uroot -p123123 --all-databases puxin > /opt/puxin_$(date +%F).sql
#对库进行完全备份

crontab -e
#也可以使用计划性任务来执行
30 3 * * 3 mysqldump -uroot -p123123 puxin xjj > /opt/puxin_xjj_$(date +%F).sql
30 3 * * 3 mysqldump -uroot -p123123 --all-databases puxin > /opt/puxin_$(date +%F).sql
每周三的凌晨 3:30 对数据库和表进行完全备份

1.statement（基于SQL语句）：每一条涉及到被修改的sql都会被记录在binlog中，缺点：日志量过大，如sleep()函数，last_insert_id()>，以及user-defined fuctions（udf）、主从复制等架构记录日志时会出现问题

2.② ROW(基于行)
只记录变动的记录，不记录sql的上下文环境
缺点:如果遇到update…set…where true 那么binlog的数据量会越来越大

总结：update、delete以多行数据起作用，来用行记录下来，
只记录变动的记录，不记录sql的上下文环境，
比如sql语句记录一行，但是ROW就可能记录10行，但是准确性高，高并发的时候由于操作量，性能变低 比较大所以记录都记下来，

③ MIXED 推荐使用
一般的语句使用statement，函数使用ROW方式存储

③可每天进行增量备份操作，生成新的二进制日志文件，这样在插入新的数据后，新的二进制文件对应的就是数据库的变化

ls /usr/local/mysql/data

mysqladmin -uroot -p123123 flush-logs

④插入新的数据，以模拟数据的增加或变更

use puxin;
insert into xjj values(4,'jiang','25','haha');
insert into xjj values(3,'wu','24','shopping');

select * from xjj;

⑤生成新的二进制文件并查看其内容

cd /usr/local/mysql/data/
ls

mysqladmin -uroot -p123123 flush-logs

cp mysql-bin.000002 /opt/
#将记录变更的二进制文件02复制至/opt目录下
cd /opt/
ls

mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
#使用64位编码机制去解码，按行读取详细内容

二、MySQL增量恢复

• 增量恢复比完全恢复操作更为频繁
• 每个增量备份都是单独的个体，数据不重复，需要控制得更加精确

1.增量恢复的场景

增量备份的场景：

• 认为的SQL语句破坏了数据库
• 在进行下一次全备之前发送系统故障导致数据库数据丢失
• 在主从架构中，主库数据发生故障

根据数据丢失的情况可以分为两类：

• 只丢失了完全备份之后更改的数据
• 完全备份之后丢失所有的数据

2.丢失完全备份之后更改的数据的恢复步骤

mysql -uroot -p123123
use puxin;
mysql> delete from xjj where id=3;
mysql> delete from xjj where id=4;
#删除插入的两条数据，模拟完全备份后数据丢失的故障

select * from xjj;
#检查
quit

mysqlbinlog --no-defaults /opt/mysql-bin.000002 | mysql -uroot -p123123
#使用二进制文件进行恢复操作

mysql -uroot -p123123 -e "select * from puxin.xjj;"
#检查表内容是否恢复

3.完全备份之后丢失所有数据的恢复步骤

• 当完全备份和增量备份之后，所有的数据丢失，需要把完全备份和所有增量备份文件逐个恢复

mysql -uroot -p123123
use puxin;
drop table xjj;
#直接删除整个表，假设完全备份后所有数据都丢失了
quit

mysql -uroot -p123123 puxin < /opt/puxin_xjj_2021-10-26.sql 
mysql -uroot -p123123 -e "select * from puxin.xjj;"
#进行完全备份后查看一下

mysqlbinlog --no-defaults /opt/mysql-bin.000002 | mysql -uroot -p123123
#增量备份
mysql -uroot -p123123 -e "select * from puxin.xjj;"

4.基于时间点与位置的恢复

• 利用二进制日志可实现基于时间点与位置的恢复，例如由于误操作删除了一张表，这时完全恢复是没有用的
• 因为日志里还有误操作的语句，我们需要的是恢复到误操作之前的状态，然后跳过误操作的语句，再恢复后面操作的语句

①基于时间点的恢复

• 将某个起始时间的二进制文件导入数据库中，从而跳过某个发生错误的时间点实现数据的恢复
• 使用mysqlbinlog加上 --stop-datetime选项，表示在哪个时间点结束，后面误操作的语句不执行， --start-datetime 选项表示执行后面的语句
• 结合使用就可以跳过误操作的语句，完成恢复工作
• 二进制文件中保存的日期格式需要调整为“-”分割

#恢复用户“wu”的数据，而不恢复“jiang”
mysql -uroot -p123123 -e "truncate table puxin.xjj;"
mysql -uroot -p123123 -e "select * from puxin.xjj;"

#进二进制文件里查询执行“jiang"的时间点
mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000002
mysqlbinlog --no-defaults --stop-datetime='2021-10-26 15：50：00' /opt/mysql-bin.000003 |mysql -uroot -p123123
mysql -uroot -p123123 -e "select * from puxin.xjj;"

#恢复“jiang”的数据
mysqlbinlog --no-defaults --start-datetime='2021-10-26 15:50:00' /opt/mysql-bin.000002 |mysql -uroot -p

②基于位置操作

• 基于位置的恢复，就是使用基于时间点的恢复
• 可能会出现在一个时间点里既同时存在正确的操作又存在错误的操作，基于位置是一种更为精确的恢复方式

mysqlbinlog --no-defaults --stop-position='599' /opt/mysql-bin.000002 | mysql -uroot -p
#使用64位编码机制去解码并按行读取二进制文件02（增量备份）的详细内容

#仅恢复“599”之前的数据，即不恢复“jiang”的数据
mysql -uroot -p123123 -e "select * from puxin.xjj;"
mysql -uroot -p123123 -e "truncate table puxin.xjj;"
mysql -uroot -p123123 -e "select * from puxin.xjj;"
mysqlbinlog --no-defaults --stop-position='599' /opt/mysql-bin.000002 | mysql -uroot -p
mysql -uroot -p123123 -e "select * from puxin.xjj;"

#仅恢复“jiang”的数据，跳过“wu”的数据恢复，即仅有第四条记录
mysql -uroot -p123123 -e "select * from puxin.xjj;"
mysqlbinlog --no-defaults --start-position='599' /opt/mysql-bin.000002 | mysql -uroot -p123123
mysql -uroot -p123123 -e "select * from puxin.xjj;"

总结

• 指定企业备份策略要根据企业数据库的实际读写的频繁性与数据的重要性进行
• 数据更新频繁，则应该进行较为频繁的备份
• 数据较为重要，则在有适当更新时进行备份
• 在数据库压力小的时段进行全备，如一周一次，然后每天增备
• 根据公司的规模，中小公司可一天一次全备，大公司可每周一次全备，每天进行一次增备，并且尽量为企业实现主从复制架构