MySQL：增量备份和恢复（5）

介绍

增量备份的特点
MySQL数据库二进制日志对备份的意义

增量备份的优点是没有重复数据，备份量不大，时间短。缺点也很明显，需要上次完全备份及完全备份之后所有的增量备份才能恢复，反推恢复，操作较为繁琐。

Mysql没有提供增量备份的方法，但是可以通过二进制日志间接实现增量备份。

二进制日志对备份的意义如下：
1）二进制日志保存了所有更新或者可能更新数据库的日志文件

2）二进制日志在启动Mysql服务器后开始记录，并在文件达到max_binlog_size 所设置的大小或者接收到的flush logs命令后重新创建新的日志文件。

3）只需要定时执行flush logs 方法重新创建新的日志，生成二进制文件序列，并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份。

增量恢复的场景：
1）人为的SQL语句破坏了数据库

2）在进行下一次全备份之前发生系统故障导致数据库的数据丢失

3）在主从架构中，主库数据发生了故障。
根据数据丢失的情况可以分为两类：
1）只丢失了完全备份之后更改的数据
2）完全备份之后丢失所有数据

---

开始实现增量备份 

创建环境 

我们先去MySQL主文件中开启二进制日志功能

vim my.cnf

加一句这个

log_bin=/usr/local/mysql/mysql-bin

然后重启mysql

systemctl restart mysqld

就发现多出两个文件夹上面那个000001结尾的就是二进制文件

 

 我们再去数据库里

aaa库下创建了一个tarro的表内容为姓名和年龄

 

在这我做一下完全备份

然后去aaa库里tarro原有基础上再插入内容

我们在原有的基础上又插入了6用户

这时我们直接刷新一下二进制日志

flush logs;

 

现在我们就可以去模拟数据库被摧毁了

 

我们在aaa库里什么都没了

---

恢复

这时我们先去使用一下完全备份

 mysql -uroot -p aaa< /backup/aaa-tarro.sql 

 

 现在我们的的tarro数据库又回来了

增量备份的完全恢复 

但是内容是我么当时完全备份的时候内容，这时我就需要使用二进制日志去恢复备份了

我刚刚刷新了一下权限所以我刚刚上一次所有的操作都在000001中了，如果我做完操作再以刷新，我的这次所有操作就会全保存在000002中了 ，同时就会生成一个000003依次类推

mysqlbinlog mysql-bin.000001

弹出的内容就是上一次的操作所记录下来的

现在我将上一次的全部恢复

mysql]# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -uroot -p

现在就全部恢复上来了

---

 基于位置恢复

基于数据编号

 现在我们再把tarro库删除，再次进行恢复

这次我不打算 恢复到aaa只恢复到王五结束

我们去使用       mysqlbinlog mysql-bin.000001

 

可以看到aaa上面的at为851

我们使用 

mysqlbinlog --no-defaults --stop-position='851' mysql-bin.000001 | mysql -uroot -p

 意思是我到851编号停止，我的851编号正好是aaa，所一就是到aaa停下，不再恢复

 

我们再次恢复到上一次完全备份

 

这次我不想恢复张三，李四，王五了想跳过他们，我可以使用

mysqlbinlog --no-defaults --start-position='851' mysql-bin.000001 | mysql -uroot -p

 意思为我从851编号开始恢复，这次恢复出的只有851以后信息

直接跳过了张三，李四，王五

---

基于日期恢复

其实和编号的差不多 

 我们执行了这条命令

mysqlbinlog mysql-bin.000001

可以看到要恢复的位置上有一个日期

我么再次恢复到上次完全备份

我还要到aaa结束 

可以看到2023-10-07  2:41:00 时间

mysqlbinlog --no-defaults --stop-datetime='2023-10-07 2:41:00' mysql-bin.000001 | mysql -uroot -p

同样想在aaa开始可以直接使用 

mysqlbinlog --no-defaults --start-datetime='2023-10-07 2:41:00' mysql-bin.000001 | mysql -uroot -p

 

这样就恢复成功了