MySQL增量备份与恢复(一)

MySQL增量备份与恢复(一)

Scroll Down

MySQL 增量备份概念

使用 mysqldump 进行完全备份,备份的数据中有重复数据,备份时间与恢复时间长,而增量备份就是备份自上一次备份之后增加或改变的文件或内容

增量备份的特点:

1.没有重复数据,备份量不大,时间短
2.恢复麻烦:需要上次完全备份及完全备份之后所有的增量备份才能恢复,而且要对所 有增量备份进行逐个反推恢复
MySQL没有提供直接的增量备份办法,可以通过MySQL提供的二进制日志(binary logs)间接实现增量备份

MySQL 二进制日志对备份的意义:

1.二进制日志保存了所有更新或者可能更新数据库的操作
2.二进制日志在启动 MySQL 服务器后开始记录,并在文件达到 max_binlog_size 所设置的大小或者接收到 flush logs 命令后重新创建新的日志文件

[root@mysql-master ~]# vim /etc/my.cnf
53 max_binlog_size=1024000			//二进制日志最大1M

3.只需定时执行flush logs方法重新创建新的日志,生成二进制文件序列,并及把这 些日志保存到安全的地方就完成了一个时间段的增量备份要进行 MySQL 的增量备份,首先要开启二进制日志功能,开启 MySQL 的二进制日志功能
方法一
MySQL 的配置文件的[mysqld]项中加入 log-bin=文件存放路径/文件前缀,如log-bin=mysql-bin,然后重启 mysqld 服务。默认此配置存在。
方法二
使用 mysqld –log-bin=文件存放路径/文件前缀 重新启动 mysqld 服务 每周选择服务器负载较轻的时间段,或者用户访问较少的时间段进行备份

MySQL 增量恢复

应用场景

1.人为的 SQL 语句破坏了数据库
2.在进行下一次全备之前发生系统故障导致数据库数据丢失
3.在主从架构中,主库数据发生了故障

增量恢复的方法

1.一般的恢复:备份的二进制日志内容全部恢复

mysqlbinlog [--no-defaults] 增量备份文件 | mysql -u 用户名 -p 密码

2.基于时间点的恢复:便于跳过某个发生错误的时间点实现数据恢复
从日志开头截止到某个时间点的恢复:

mysqlbinlog [--no-defaults] --stop-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u用户名 -p密码

从某个时间点到日志结尾的恢复:

mysqlbinlog [--no-defaults] --start-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u用户名 -p密码

从某个时间点到某个时间点的恢复:

mysqlbinlog [--no-defaults] --start-datetime=’年-月-日 小时:分钟:秒’ --stop-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u 用户名 -p 密码

3.基于位置的恢复:可能在同一时间点既有错误的操作也有正确的操作,基于位置 进行恢复更加精准

mysqlbinlog --stop-position=’操作 id’ 二进制日志 |mysql -u 用户名 -p 密码 
mysqlbinlog --start-position=’操作 id’ 二进制日志 |mysql -u 用户名 -p 密码

制定企业备份策略的思路

1、确定当前 mysql 是处于哪种表类型下工作的,它们支持事物处理还是非事物的,因为我 们需要根据不同的特点来做一些设置
2、要选择备份的形式是完全备份还是增量备份,它们各有优缺点
3、为了保证恢复的完整性,我们得开启 binary log 功能,同时 binlog 给恢复工作也带来了很 大的灵活性,可以基于时间点或是位置进行恢复。考虑到数据库性能,我们可以将 binlog 文件保存到其他安全的硬盘中
4、正如最初所提到的,备份操作和应用服务得到同时运行,这样就十分消耗系统资源了, 会导致数据库服务性能下降,这就要求我们选择一个合适的时间(比如在应用负担很小的时 候)再来进行备份操作
5、不是备份完就万事大吉,我们还得确认备份是否可用,所以之后的恢复测试是完全有必要的
根据数据更新频繁,则应该较为频繁的备份
数据重要,则在有适当更新时进行备份
在数据库压力小的时段进行备份,如一周一次完全备份,然后每天进行增量备份
中小公司,全备一般可一天一次
大公司可每周进行一次全备,每天进行一次增量备份
尽量为企业实现主从复制架构