使用MySQL学习数据库备份、恢复技术，深入理解DBMS事务技术原理

实验七 使用MySQL学习数据库备份、恢复技术，深入理解DBMS事务技术原理

1.对学生课程数据库进行备份，包括数据文件和日志文件的备份，要求至少使用两种备份方法，如海量备份和增量备份。

2.利用备份对数据库的恢复操作，理解事务故障恢复、系统故障恢复以及介质故障恢复原理。

3.通过备份和恢复，理解数据库关于事务、日志、备份和恢复等概念。理解一个数据库DBMS事务处理的原理和应用。

实验步骤

从恢复角度看，使用海量转储得到的后副本进行恢复一般来说回更方便些，但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用有效。

一、海量备份

海量转储是指每次转储全部数据库。

navicat for mysql实现数据库的手动备份与定时自动备份

手动备份

insert into Student VALUES ('201215126','张成民','男',18,'CS');

备份 的相关信息

还原备份

定时自动备份

以及设置密码（开机密码）

start

二、增量备份

增量转储则指每次只转储上次转储后更新过的数据

知识：

完全备份会有大量的重复数据，并且完全备份的时间与恢复的时间很长。解决完全备份存在的问题就是使用增量备份的方式，增量备份就是备份自上一次备份之后增加或改变的文件或者内容。

特点：

优点：没有重复数据，备份量不大，时间短。
缺点：需要上次完全备份及完全备份之后所有的增量备份才能恢复，
MySQL没有提供直接的增量备份方法，但是可以通过mysql的二进制文件（binarylogs）间接实现增量备份。二进制日志对备份的意义如下：
（1）二进制日志文件保存了所有更新或者可能更新数据库的操作。
（2）二进制日志在启动MySQL服务器后开始记录，并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件。
（3）只需要定时执行flush logs方法重新创建新的日志，生成二进制文件序列，并及时把这些日志保存到安全的地方就完成了一个时间段的增量备份。

mysql -u root -p	//登录
show databases		//查看数据库
use database_third; //连接数据库
show tables;		//查看数据表
show variables like "%char%"; //查看安装路径
show variables like 'log_bin' //发现二进制文件是否开启

2.1 时间点的恢复建立在一下规则的基础上:

mysql服务器需要开启二进制日志–log-bin

开启二进制文件：

打开mysql 的配置文件my.ini(别说找不到哦)

1、在mysqld配置项下面加上log_bin=mysql_bin

注意：在 MySQL 5.7.3 及以后版本,如果没有设置server_id, 那么设置binlog后无法开启MySQL服务.

[mysqld]
log_bin=mysql_bin
server_id=10

要去服务中重新手动启动MySql

show binary logs;	 // 查看所有binlog文件
show master status;		//查看当前binlog文件信息（包含文件名，当前位置等）
FLUSH LOGS ;     //我们先用命令将记录刷到log bin中 
show binlog events in 'mysql_bin.000001';
/*mysqlbinlog  --stop-datetime="2019-06-16 15:40:59" E:/IDEA/mysql/mysql-5.7.24-winx64/data/mysql_bin.000003 |mysql -u root -p*/
//进入E:\IDEA\mysql\mysql-5.7.24-winx64\data下执行 要理解start stop 啥意思 ？ 日志起始时间 终止时间  那分别有什么作用，比如下面第二条命令就是恢复477之前的状态 而第一条就是可能在219之前出现错误但是我们会修改回来对于219之后的这些操作是正确的仍旧恢复回来
mysqlbinlog --start-position=219 --stop-position=477 mysql_bin.000005 > e:\\update.sql
mysqlbinlog  --stop-position=477 mysql_bin.000005 > e:\\update.sql
//登录数据库执行下面语句
source e:\\update.sql

2 、mysqlbinlog工具将binary log文件由二进制转换为可读的文本文件，可以选择基于时间或位置的事件。
3 、从binary log文件中执行事件会导致数据的修改，表示要重做数据。命令为：

…看了一些博客，天下博客。。。我很无语，就不能好好写吗？就算写不好也不要把错的写上去误导大家啊！

恢复实例：

delete from Student where Sno = '201215126';

mysqlbinlog  --stop-position=477 mysql_bin.000005 > e:\\update.sql

MySQL没有直接提供增量备份的工具，需要借助二进制日志文件进行操作。

使用分割日志的方式进行增量备份。
增量恢复需要根据日志文件的时间先后，逐个执行。
使用基于时间和位置的方式进行恢复，可以更精确地恢复数据。
大企业应每周做一次全备，每天做一次增量备份；中小企业应每天进行一次全备。

事务故障恢复

有的是可以通过事务程序本身发现的（转账）；

有的是非预期的，如：死锁而选中该事务撤销

恢复：

（1） 反向扫描日志文件，查找该事务的更新操作。
（2） 对该事务的更新执行逆操作，即将日志记录中“更新前的值”写入数据库。
（3） 继续反向扫描日志文件，查找该事物的其它更新操作，并做同样处理。
（4） 如此继续下去，直到读到此事务的开始标记，事务故障恢复就完成了。

系统故障恢复

称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动。

整个系统的正常运行突然被破坏；

所有正在运行的事务都非正常终止；

不破坏数据库内存中数据库缓冲区的信息全部丢失；
特定类型的硬件错误（如CPU故障）；

操作系统故障；

DBMS代码错误；

系统断电

恢复：

发生系统故障时，事务未提交
恢复策略：强行撤消（UNDO）所有未完成事务
发生系统故障时，事务已提交，但缓冲区中的信息尚未完全写回到磁盘上。
恢复策略：重做（REDO）所有已提交的事务

介质故障恢复

称为硬故障，指外存故障

磁盘损坏

磁头碰撞

操作系统的某种潜在错误

瞬时强磁场干扰
装入数据库发生介质故障前某个时刻的数据副本

重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库

resourse

navicat备份：https://blog.csdn.net/zyb2017/article/details/77879123

命令行操作：https://www.cnblogs.com/qmfsun/p/4837934.html

Linux下利用mysql的binlog日志实现增量备份：

https://blog.51cto.com/13721050/2172797

http://seanlook.com/2014/12/05/mysql_incremental_backup_example/

Windows下利用mysql的binlog日志实现增量备份：https://blog.csdn.net/JesseYoung/article/details/41211841