Mysql的增量备份及基于时间点与位置的恢复

时间：2018-07-03 20:12:39 阅读：260 评论：0 收藏：0 [点我收藏+]

标签：依次 system log stop 文件的 alt decode res 意义

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

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

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

增量备份

开启Mysql的二进制日志功能

# vim /etc/my.cnf
    [mysql]
    log-bin=mysql-bin    //在[mysql]项下添加
# systemctl restart mysqld          //重启服务  
（此时usr/local/mysql/data/ 目录下会生成 mysql-bin.000001二进制文件）

flush-logs 将上次至当前的数据及操作保存在上次生成的二进制文件中同时生成另一个新的二进制文件

    # mysqldump -u root -p school > /opt/school.sql   //完全备份 数据库school
    # mysqladmin -u root -p flush-logs  //增量备份 生成新的二进制文件
    （此时usr/local/mysql/data/ 目录下会生成 mysql-bin.000002二进制文件）

查看二进制文件的内容

    # mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002

增量恢复

增量恢复的场景：
1）认为的SQL语句破坏了数据库
2）在进行下一次全备份之前发生系统故障导致数据库的数据丢失
3）在主从架构中，主库数据发生了故障。

根据数据丢失的情况可以分为两类：
1）只丢失了完全备份之后更改的数据
2）完全备份之后丢失所有数据

丢失了完全备份之后更改的数据恢复

# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p
（恢复操作  注意恢复的顺序，要先恢复最先生成的二进制文件）

丢失了完全备份之后所有的数据恢复

# mysql -u root -p school < /opt/school.sql 
# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p
# mysqlbinlog --no-defaults mysql-bin.000002 | mysql -u root -p
（恢复操作  注意恢复的顺序，要先恢复最先生成的二进制文件）

下面对增量备份原理做个总结：首先是每周使用mysqldump完全备份整库，在整库备份的时间点之后，每天使用flush logs 生成新的二进制文件，二进制文件保存的是每天对数据库的操作变化的内容，内容是不重复的。所以每周的备份整库加上每天的二进制备份文件，相当于数据库现在的数据状态

基于时间点与位置的数据恢复
利用二进制日志可以实现基于时间点和位置的恢复，列如我们在执行操作中途误操作删除了一张表，
我们可以查看二进制日志的时间或者位置恢复的时候跳过这一步错误操作。
如图我们误删了zhangsan
mysqladmin -u root -p flush-logs 先生成二进制文件
然后查看这个二进制文件误操作的时间点、位置和正确操作的时间点、位置

技术分享图片

进入数据库 
# mysql -u root -p
> use school;     
> drop table info；    删除表

依次恢复

# mysqldump -u root -p school > /opt/school.sql
# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p
# mysqlbinlog --no-defaults mysql-bin.000002 | mysql -u root -p 
# mysqlbinlog --no-defaults mysql-bin.000003 | mysql -u root -p
# mysqlbinlog --no-defaults mysql-bin.000004 | mysql -u root -p

基于时间的恢复

跳过了错误的时间

# mysqlbinlog --no-defaults --stop-datetime=‘2018-07-03 18:19:49‘ /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p
# mysqlbinlog --no-defaults --start-datetime=‘2018-07-03 18:22:21‘ /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p

基于位置的恢复

跳过了错误的位置

# mysqlbinlog --no-defaults --stop-position=‘347‘ /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p
# mysqlbinlog --no-defaults --start-position=‘395‘ /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p

Mysql的增量备份及基于时间点与位置的恢复

标签：依次 system log stop 文件的 alt decode res 意义

原文地址：http://blog.51cto.com/13630803/2135741

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行

Mysql的增量备份 及基于时间点与位置的恢复

Mysql的增量备份及基于时间点与位置的恢复