# MySQL 增量备份概念 使用 mysqldump 进行完全备份，备份的数据中有重复数据，备份时间与恢复时间长,而增量备份就是备份自上一次备份之后增加或改变的文件或内容 ## 增量备份的特点: 1.没有重复数据，备份量不大，时间短 2.恢复麻烦:需要上次完全备份及完全备份之后所有的增量备份才能恢复，而且要对所 有增量备份进行逐个反推恢复 MySQL没有提供直接的增量备份办法，可以通过MySQL提供的二进制日志(binary logs)间接实现增量备份 ## MySQL 二进制日志对备份的意义: 1.二进制日志保存了所有更新或者可能更新数据库的操作 2.二进制日志在启动 MySQL 服务器后开始记录，并在文件达到 max_binlog_size 所设置的大小或者接收到 flush logs 命令后重新创建新的日志文件 ```bash [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.一般的恢复:备份的二进制日志内容全部恢复 ```bash mysqlbinlog [--no-defaults] 增量备份文件 | mysql -u 用户名 -p 密码 ``` 2.基于时间点的恢复:便于跳过某个发生错误的时间点实现数据恢复 从日志开头截止到某个时间点的恢复: ```bash mysqlbinlog [--no-defaults] --stop-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u用户名 -p密码 ``` 从某个时间点到日志结尾的恢复: ```bash mysqlbinlog [--no-defaults] --start-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u用户名 -p密码 ``` 从某个时间点到某个时间点的恢复: ```bash mysqlbinlog [--no-defaults] --start-datetime=’年-月-日 小时:分钟:秒’ --stop-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u 用户名 -p 密码 ``` 3.基于位置的恢复:可能在同一时间点既有错误的操作也有正确的操作，基于位置 进行恢复更加精准 ```bash mysqlbinlog --stop-position=’操作 id’ 二进制日志 |mysql -u 用户名 -p 密码 mysqlbinlog --start-position=’操作 id’ 二进制日志 |mysql -u 用户名 -p 密码 ``` # 制定企业备份策略的思路 1、确定当前 mysql 是处于哪种表类型下工作的，它们支持事物处理还是非事物的，因为我 们需要根据不同的特点来做一些设置 2、要选择备份的形式是完全备份还是增量备份，它们各有优缺点 3、为了保证恢复的完整性，我们得开启 binary log 功能，同时 binlog 给恢复工作也带来了很 大的灵活性，可以基于时间点或是位置进行恢复。考虑到数据库性能，我们可以将 binlog 文件保存到其他安全的硬盘中 4、正如最初所提到的，备份操作和应用服务得到同时运行，这样就十分消耗系统资源了， 会导致数据库服务性能下降，这就要求我们选择一个合适的时间(比如在应用负担很小的时 候)再来进行备份操作 5、不是备份完就万事大吉，我们还得确认备份是否可用，所以之后的恢复测试是完全有必要的 根据数据更新频繁，则应该较为频繁的备份 数据重要，则在有适当更新时进行备份 在数据库压力小的时段进行备份，如一周一次完全备份，然后每天进行增量备份 中小公司，全备一般可一天一次 大公司可每周进行一次全备，每天进行一次增量备份 尽量为企业实现主从复制架构