MySQL增量备份与恢复
一、前言
上篇文章(MySQL完全备份与恢复概念及操作)中我们详细介绍了MySQL完全备份与恢复的概念以及详细的命令操作进行验证,并且也讲述了一些增量备份的概念。而本文将就MySQL的增量备份及恢复作进一步介绍与实例操作。
二、再谈MySQL增量备份
2.1问题引出与解决
首先我们思考一个问题:既然有了完全备份和差异备份,为什么还需要增量备份呢?
上篇文章中我们谈到可以使用tar命令将数据库的数据目录中的目录和文件进行xz格式的打包从而进行数据库的变相备份,也可以使用MySQL数据库自带的mysqldump工具进行完全备份。
但是我们会发现这样一个问题:当数据库系统中的数据库包含的数据表越来越多(在生产环境中,尤其是大型企业,数据表中必然会有大量的数据),那么我们继续使用tar压缩解压恢复或者说进行完全备份操作来备份数据库的数据时,就会造成诸多问题,比如:备份时间加长,备份冗余数据庞大,服务器存储资源占用大,占用网络带宽,备份过程中出现网络瘫痪,服务器宕机等问题时就会造成无法承担的灾难,而差异备份也是如此,毕竟差异备份的参考对象仅仅是完全备份的内容。
因此,我们需要考虑如何在节约各种成本的情况下,兼顾安全与性能,得出一个相对更好的方法来备份数据,而这个方法就是进行“增量备份”,其余差异备份的差别在于参考对象,可以参考上面博文中画出的比较三者区别的表格案例,看了之后您一定会理解。
2.2进一步理解增量备份及其优缺点,考虑其适用场景
个人比较喜欢使用身边生活中的例子来理解各种知识点,那么就举一个例子来加深大家对“增量备份”的理解。
在我们使用计算机的时候必定会存储一些文件,细心的人更加会在另一个终端或者说使用U盘进行一次备份,防止原来的丢失或出错,而一个细心且有条理的人会过一段时间将新产生的文件再次进行备份,而不是全盘重新进行备份,因为这样的人是希望提高效率并且节约时间,尤其在工作数据量大的情况下,之后循环此类的操作。
而我们所说的“增量备份”就是这样一种“细心而又条理的人”。
2.2.1增量备份的特点
MySQL没有提供直接的增量备份方法,但是可以通过MySQL的二进制日志文件(binary logs)简接实现增量备份。二进制日志对备份的意义如下:
(1)二进制日志保存了所有更新或者可能更新数据库的操作;
(2)二进制日志在启动MySQL服务器后开始记录,并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件;
(3)只需要定时执行flush logs方法重新创建新的日志,生成二进制文件序列,并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份。
2.2.2增量备份的优点
- 增量备份没有冗余数据,备份量少;
- 时间短,效率高,成本低;
2.2.3增量备份的缺点
备份具备优势的同时,其恢复数据的要求必然严苛,这就是所谓“收之桑榆,失之东隅”了。增量备份的恢复就需要依赖于最初的完全备份以及截至目前的所有的增量备份才可以完成恢复数据库数据的操作:对所有的增量备份进行逐个反推,操作非常繁琐。
2.3适用场景
一般,在数据库系统建立后可预测未来数据量非常庞大的场景中比较适合适用增量备份;数据库中的数据更新迭代速度快内容多的情况也适用增量备份,可以使用周期计划任务等其他方法来进行备份数据。
三、增量备份操作
上文中谈到MySQL并没有给出直接的增量备份的方法,而是依赖二进制日志文件简接实现增量备份。因此我们首先需要先开启二进制日志功能,开启方法如下:
修改配置文件,当初我们在手工编译安装MySQL时,修改过/etc/my.cnf文件,开启二进制日志功能也是需要更改配置文件,并重启服务。
在配置文件的mysqld目录下添加如下一行:
log-bin=mysql-bin
我们重启服务之后就可以才data目录下看到mysql-bin.000001的一个文件
[root@localhost data]# systemctl restart mysqld.service
[root@localhost data]# ls
auto.cnf fruit ib_buffer_pool ibdata1 ib_logfile0 ib_logfile1 ibtmp1 mysql mysql-bin.000001 mysql-bin.index performance_schema sys
[root@localhost data]#
因为差异备份和增量备份都是基于完全备份的基础上执行操作的,因此我们需要先进行一次完全备份操作,并模拟增加数据、误操作删除了数据的操作,最后依赖上述类型的二进制日志文件进行必要的数据恢复。
具体的操作过程如下:
1)首先是进行完全备份并查看文件
[root@localhost data]# mysqldump -uroot -p fruit > /opt/fruit-$(date +%F).sql
Enter password:
[root@localhost data]# ls /opt/
fruit-2020-01-08.sql mysql-5.7.17 rh
使用mysqladmin命令刷新日志文件
[root@localhost data]# mysqladmin -uroot -p flush-logs
Enter password:
[root@localhost data]# ls
auto.cnf ib_logfile0 mysql-bin.000001 sys
fruit ib_logfile1 mysql-bin.000002
ib_buffer_pool ibtmp1 mysql-bin.index
ibdata1 mysql performance_schema
我们之后对数据的操作会以编码形式存放到mysql-bin.000002文件中
2)插入新的数据
先了解一下当前表的结构内容
mysql> use fruit;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> use fruit;
Database changed
mysql> show tables;
+-----------------+
| Tables_in_fruit |
+-----------------+
| fruit_info |
+-----------------+
1 row in set (0.00 sec)
mysql> select * from fruit_info;
+----+-------+---------+
| id | price | newtype |
+----+-------+---------+
| 1 | 2.50 | banana |
| 2 | 5.50 | apple |
| 3 | 6.00 | peach |
+----+-------+---------+
3 rows in set (0.00 sec)
插入新的数据
mysql> insert into fruit_info values (4,4.5,'pear');
Query OK, 1 row affected (0.00 sec)
mysql> select * from fruit_info;
+----+-------+---------+
| id | price | newtype |
+----+-------+---------+
| 1 | 2.50 | banana |
| 2 | 5.50 | apple |
| 3 | 6.00 | peach |
| 4 | 4.50 | pear |
+----+-------+---------+
4 rows in set (0.00 sec)
3)误删数据
mysql> delete from fruit_info where id = 1;
Query OK, 1 row affected (0.00 sec)
mysql> select * from fruit_info;
+----+-------+---------+
| id | price | newtype |
+----+-------+---------+
| 2 | 5.50 | apple |
| 3 | 6.00 | peach |
| 4 | 4.50 | pear |
+----+-------+---------+
3 rows in set (0.00 sec)
4)再次插入数据
mysql> insert into fruit_info values (5,3.5,'orange');
Query OK, 1 row affected (0.00 sec)
mysql> select * from fruit_info;
+----+-------+---------+
| id | price | newtype |
+----+-------+---------+
| 2 | 5.50 | apple |
| 3 | 6.00 | peach |
| 4 | 4.50 | pear |
| 5 | 3.50 | orange |
+----+-------+---------+
4 rows in set (0.00 sec)
5)首先我们来查看一下二进制日志的相关内容
mysqlbinlog --no-defaults mysql-bin.000002
我们所操作的SQL语句就在该文件的BINLOG下
来源:51CTO
作者:wx5d8a17c45cb5b
链接:https://blog.51cto.com/14557673/2465211