目录
4.2 专用备份工具 mysqldump 或 mysqlhotcopy?
前言
备份的主要目的是灾难恢复，备份还可以测试应用，回滚数据修改、查询历史数据、审计等。在备份、恢复中，日志起到了很重要的作用。
一、MySQL日志管理
MySQL 的日志默认保存位置为**/usr/local/mysql/data**
MySQL 的日志配置文件为/etc/my.cnf，里面有个**[mysqld]**项。
?1、日志类型与作用
1.1 redo（重做日志）
用来记录当MsSQL启动、停止或运行时发生的错误信息，默认已开启
达到事务一致性（每次重启都会重做）
作用：确保日志的持久性，防止在发生故障，脏页未写入磁盘。重启数据库会进行 redo log 执行重做，达到事务一致性。
1.2 undo（回滚日志）
作用：保证数据的原子性，记录事务发生之前的一个版本，用于回滚，innodb事务可重复和读取已提交隔离级别就是通过mvcc+undo实现。
1.3 errorlog（错误日志）
用来记录当MySQL启动、停止或运行时发生的错误信息，默认已开启
vim /etc/my.cnf
log-error=/usr/local/mysql/data/mysql_error.log #指定日志的保存位置和文件名
1.4 slow query log（慢查询日志）
作用：记录执行时间过长的sql语句，时间默认值为10s，可以配置，只记录执行成功，超过设置时间的sql语句，都会被存在到慢查询日志中。
还可以提醒优化，对于查询慢的语句进行操作（比如是网络问题，还是未添加索引等）
vim /etc/my.cnf
slow_query_log=ON
slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log
long_query_time=5
1.5 bin log（二进制日志）
作用：用于基于日志形式的数据恢复。用于主从复制，实现主从同步，记录的内容是：数据库中执行的sql语句
vim /etc/my.cnf
log-bin=mysql-bin
或
log_bin=mysql-bin
1.6 relay log（中继日志）
用于数据库主从同步，将主库发来的bin log保存在本地，然后从库进行回放。
一般情况下它在Mysql主从同步（复制）、读写分离集群的节点开始。主节点一般不需要这个日志。
1.7 general log（普通日志）
记录数据库的操作明细，默认关闭，开启后会降低数据库的性能
vim /etc/my.cnf
general_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
2、数据备份的重要性
备份的主要目的是灾难恢复
在生产环境中，数据的安全性至关重要
任何数据的丢失都可能产生严重的后果
造成数据丢失的原因：
① 程序错误
② 人为操作错误
③ 运算错误
④ 磁盘故障
⑤ 灾难(如火灾、地震)和盗窃
3、日志配置文件
#修改my.cnf配置文件
vim /etc/my.cnf
#错误日志
log-error=/usr/local/mysql/data/mysql_error.log
#通用查询日志
general_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
#二进制日志
log-bin=mysql-bin
#慢查询日志
slow_query_log=ON
slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log
long_query_time=5
#重新mysql服务
systemctl restart mysqld.service
?当我们重启了myslq服务之后，会在数据库目录下，生成以下日志文件
索引文件：记录更新语句
索引文件刷新方式：
1、重启mysql的时候会更新索引文件，用于记录新的更新语句
2、刷新二进制日志
?4、日志配置文件查询
#登入mysql
mysql -u root -p[密码]
#查看通用查询日志是否开启
show variables like 'general%';
#查看二进制日志是否开启
show variables like 'log_bin%';
#查看慢查询日功能是否开启
show variables like '%slow%';
#查看慢查询时间设置
show variables like 'long_query_time';
#在数据库中设置开启慢查询的方法
set global slow_query_log=ON;
?二、备份类型
数据库备份可以分为物理备份和逻辑备份
1、物理备份
物理备份是对数据操作系统的物理文件（如数据文件、日志文件等）的备份。这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据库。
物理备份又可以分成冷备份（脱机备份）、热备份（联机备份）和温备份。
- 冷备份（脱机备份）：是在关闭数据库的时候进行的（tar）
- 热备份（联机备份）：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopy mysqlbackup）
- 温备份：数据库锁定表格（不可写入但可读）的状态下进行备份操作（mysqldump）
1.1 冷备份（脱机备份）
是在关闭数据库的时候进行的备份，可以直接（tar）。当正常关闭时会提供给我们一个完整的数据库。对于备份Oracle信息而言，冷备份是最快和最安全的方法。
冷备份的优点：
- 使用tar命令直接打包数据库文件夹
- 直接替换现有mysql目录即可（/usr/local/mysql/data 数据目录）
- 是非常快速的备份方法（只需拷文件）
- 轻易归档（简单拷贝即可）
- 轻易恢复到某个时间点上（只需将文件再拷贝回去）
- 能与归档方法相结合，做数据库“最佳状态”的恢复。
- 低度维护，高度安全。
冷备份的不足：
- 单独使用时，只能提供到“某一时间点上”的恢复。
- 再实施备份的全过程中，数据库必须要作备份而不能作其他工作。也就是说，在冷备份过程中，数据库必须是关闭状态。
- 若磁盘空间有限，只能拷贝到磁带等其他外部存储设备上，速度会很慢。
- 不能按表或按用户恢复。
假如可能的话（主要看效率），应将信息备份到磁盘上，然后启动数据库（使用户可以工作）并将备份的信息拷贝到磁带上（拷贝的同时，数据库也可以工作）。冷备份中必须拷贝的文件包括：
- 所有数据文件
- 所有控制文件
- 所有联机REDO LOG文件
- Init.ora文件（可选）
值得注重的使冷备份必须在数据库关闭的情况下进行，当数据库处于打开状态时，执行数据库文件系统备份是无效的。
1.2 热备份
数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopy mysqlbackup）
1.3 温备份
数据库锁定表格(不可写入但可读)的状态下进行备份操作（mysqldump）
物理备份的优点及使用场景：
优点：速度快，效率高。
场景：可用于停机维护及数据库物理迁移场景中。
2、逻辑备份
逻辑备份是对数据库逻辑组件的备份，表示为逻辑数据库结构
这种类型的备份适用于可以编辑数据值或表结构
从数据库的备份策略角度来看，备份又可以分为完全备份、差异备份和增量备份
2.1 完全备份
每次对数据进行完整备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完成时刻的数据库，是差异备份与增量备份的基础完全备份的备份与恢复操作都非常简单方便，但是数据存在大量的重复并且会占用大量的磁盘空间，备份的时间也很长，操作简单
每次都进行完全备份，会导致备份文件占用空间巨大，并且有大量的重复数据，恢复时，直接使用完全备份的文件即可。
完全备份是对整个数据库、数据库结构和文件结构的备份。
保存的是备份完成时刻的数据库。
是差异备份与增量备份的基础。
相当于基石。优点：
备份与恢复操作简单方便
缺点：
数据存在大量的重复
占用大量的备份空间
备份与恢复时间长
2.2 差异备份
备份那些自从上次完全备份之后"被修改"过的所有文件，备份的时间节点是从上次完整备份起，备份数据量会越来越大。恢复数据时只需要恢复上次的完全备份与最佳的一次差异备份。备份有差异的数据
每次差异备份，都会备份上一次完全备份之后的数据，可能会出现重复数据。恢复时，先恢复完全备份的数据，再恢复差异备份的数据。
2.3 增量备份
只有那些在上次完全备份或者增量备份后被修改的文件才会被备份以上次完整备份或上次增量备份的时间为时间点，仅备份期间内的数据变化，因而备份的数据量小，占用空间小，备份速度快。但恢复时，需要从上一次的完整备份开始到最后一次增量备份之间的所有增量依次恢复，如中间某次的备份数据损坏，将导致数据的丢失
备份增、删、改的内容
每次增量备份都是在备份在上一次完全备份或者增量备份之后的数据，不会出现重复数据的情况，也不会占用额外的磁盘空间。
恢复数据，需要按照次序恢复完全备份和增量备份的数据
备份策略的比较
| 备份方式 | 完全备份 | 差异备份 | 增量备份 |
|---|---|---|---|
| 完全备份时的状态 | 表1、表2 | 表1、表2 | 表1、表2 |
| 第1次添加内容 | 创建表3 | 创建表3 | 创建表3 |
| 备份内容 | 表1、表2、表3 | 表3 | 表3 |
| 第2次添加内容 | 创建表4 | 创建表4 | 创建表4 |
| 备份内容 | 表1、表2、表3、表4 | 表3、表4 | 表4 |
3、逻辑备份的策略（增、全、差异）
如何选择逻辑备份策略（频率）
合理值区间
完全备份：3天一次的全备，全备的时间需要在不提供业务的时间区间进行 PM 10点 AM 5:00之间进行全备
增量备份：3天/2天/1天一次增量备份
差异备份：选择特定的场景进行备份
一个处理（NAS 就是采用nfs技术）提供额外空间给与mysql 服务器用
4、常见的备份方法
4.1 物理冷备
备份时数据库处于关闭状态，直接打包数据库文件
备份速度快，恢复时也是最简单的
关闭MySQL数据库
使用tar命令直接打包数据库文件夹
直接替换现有的MySQL目录即可
4.2 专用备份工具 mysqldump 或 mysqlhotcopy?
mysqldump 常用的逻辑备份工具
- MySQL自带的备份工具，可实现对MySQL的备份
- 可以将指定的库、表导出为SQL脚本
- 使用命令mysql导入备份的数据
mysqlhotcopy工具
- mysqlhotcopy 仅拥有备份 MyISAM 和 ARCHIVE 表
4.3 启用二进制日志进行增量备份
进行增量备份，需要刷新二进制日志
MySQL支持增量备份，进行增量备份时必须启用二进制日志，二进制日志文件为用户提供复制对执行备份点后进行的数据库更改所需的信息进行恢复，如果进行增量备份（包含自上次完全备份或增量备份以来发生的数据修改），需要刷新二进制日志。
4.4 第三方工具备份
免费的MySQL 热备份软件 Percona XtraBackup mysqlbackup
三、MySQL完全备份与恢复
是对整个数据库、数据库结构和文件结构的备份
保存的是备份完成时刻的数据库
是差异备份与增量备份的基础
优点：
备份与恢复操作简单方便缺点：
数据存在大量的重复
占用大量的备份空间
备份与恢复时间长
systemctl stop mysqld.service
yum -y install xz 下载更新压缩工具
xz是一个使用LZMA压缩算法的无损数据压缩文件格式。
和gzip与bzip2一样，同样支持多文件压缩，但是约定不能将多于一个的目标文件压缩进同一个档案文件。
相反，xz通常作为一种归档文件自身的压缩格式。但是其压缩比比gzip和bzip2高。
官网链接： https://tukaani.org/xz/
官网介绍到： 压缩后的文件大小 gzip 小30％，比bzip2小15％。
xz -z 文件名 不保留原文件压缩
xz -zk 文件名 保留原文件压缩
xz -d 文件名 不保留原文件解压
xz -dk 文件名 保留原文件解压
?压缩备份
tar jcvf /opt/mysql_all_$(date+%F).tar.xz /usr/local/mysql/data/
?解压恢复
tar Jxvf /opt/mysql_all_2022-06-21.tar.xz -C /usr/local/mysql/data
systemctl restart mysqld
?
2、mysqldump备份与恢复（温备份）
MySQL自带的备份工具，可方便实现对MySQL的备份
可以将指定的库、表导出为SQL 脚本
使用命令mysq|导入备份的数据
2.1 完全备份一个或多个完整的库（包含其中所有的表）
完全备份一个或多个完整的库 (包括其中所有的表)
mysqldump -u root -p[密码] --databases 库名1 [库名2] ... > /备份路径/备份文件名.sql???
#导出的就是数据库脚本文件
完全备份 MySQL 服务器中所有的库
mysqldump -u root -p[密码] --all-databases > /备份路径/备份文件名.sql
mysqldump -uroot -p123456 --databases jn > /mnt/gang1.sql
#备份一个数据库jn
mysqldump -uroot -p123456 --detabases jn ning > /mnt/gang-gang1.sql
#备份两个数据库jn ning
mysqldump -uroot -p123456 --all-databases >/mnt/all-database.sql
#备份所有的数据库
2.2 恢复一个库或多个库
如果是使用mysqldump备份的文件，那么可以使用mysql导入的方法恢复
还有一种方法就是使用source命令在数据库中加载备份的目录即可
使用mysql命令进行导入恢复
mysql -uroot -p123456 -e 'drop database jn';
#使用-e的方法进入数据库执行删除数据库的操作
mysql -uroot -p123456 -e 'show databases';
#使用-e的方法进行显示数据库的数量
mysql -uroot -p123456 </mnt/jn.sql
#使用mysql命令恢复数据库gang1
mysql -uroot -p123456 -p 'show databases';
#查看数据库中是否恢复成功
使用source进行恢复数据库?
mysql -uroot -p123456 -e 'drop database jn;'
mysql -uroot -p123456 -e 'drop database ning;'
#删除数据库gang gang1
mysql -uroot -p123456 -e 'show databases;'
#查看gang和 gang1 数据库是否被删除
mysql -uroot -p123456-e 'source /mnt/jn-ning.sql;'
#使用source进行恢复
2.3? 加-databases和不加的区别实验
mysqldump严格来说属于温备份，会需要对表进行写入锁定 在全量备份与恢复实验中
- 加上–databases表示指定备份的是这个数据库以及下面所有表
- 不加–database时，表示只备份这个数据库下面的表，并不备份数据库。
加–databases时实验
格式：mysqldump -uroot -p[密码] 库名 [表名1] [表名2] ... > /备份路径/备份文件名.sql
mysqldump -uroot -p123456 --databases jn pokemon> /mnt/jn_pokemon.sql
#备份jn数据库中的pokemon表（表的数据也会备份）
mysqldump -uroot -p123456 --databases -d jn pokemon> /mnt/jn_pokemon.sql
#备份ngs数据库中的info表（加了-d选项，表示只备份info表的表结构）
grep -v "^--" /opt/ngs_info.sql |grep -v "^/" |grep -v "^$"
#查看备份文件
2.5 恢复库中的部分表
第一种：使用命令mysql恢复
mysql -uroot -p123456 -e 'drop table jn pokemon'; 删除表
#删除ngs库中的info表
mysql -uroot -p123456 -e 'show tables from jn;' 查看表
#查看ngs库中的表
mysql -uroot -p123456 jn < /mnt/jn-pokemon.sql 恢复表
#查看ngs库中的表
mysql -uroot -p123456 -e 'show tables from jn;' 查看表
#再次查看
?使用source恢复
mysql -uroot -p123456
#登录数据库
use jn
show tables;
#查看ngs数据库中的所有表
drop table pokemon;
#删除info表
source /opt/jn_pokemon.sql
#使用source执行恢复
?
?
四、MySQL增量备份与恢复
mysql数据库增量恢复有，一般恢复、基于位置恢复、基于时间点恢复
一般恢复
- 将所有备份的二进制日志内容全部恢复
基于位置恢复
- 数据库在某一时间点可能既有错误的操作也有正确操作
- 可以基于精确的位置跳过错误的操作
- 发生错误节点之前的一个节点，上一次正确操作的位置点停止
基于时间点恢复
- 跳过某个发生错误的时间点实现数据恢复
- 在错误时间点停止，在下一个正确时间点开始
1、二进制文件介绍
1.1 二进制日志记录的格式
二进制文件有三种不同的记录格式
① STTATEMENT（基于sql语句）
- 每一条涉及到被修改的sql都会记录在binlog中
缺点：日志量过大、如sleep（）函数，last_insert_id()>（聚合函数）,以及user-definedfuctions(udf)、主从复制等架构记录日志时会出现问题
总结
增删改查通过sql语句来实现记录，如果用高并发可能会出错，可能时间差异或者延迟，可能不是我们想像的恢复可能你先删除或在修改，可能会倒过来。准确率低。
② ROW（基于行）
- 只记录变动的记录，不记录sql语句的上下文环境
缺点
如果遇到update…set…where true 那么binlog的数据量会越来越大
总结
update、delete多行数据其作用，来用行记录下来，值计量变动的记录，不记录sql的上下文环境，比如sql语句记录一行，但是ROW就可能记录10行，但是准确性高，高并发的时候由于操作量能变低，所以记录都记下来。
③ MIXED（混合模式）推荐使用
- 上面两种的版本混合，都进行记录
- 一般的语句使用statement，函数使用ROW方式存储
1.2 开启二进制功能
vim /etc/my.cnf
[mysqld]
log-bin=mysql-bin
binlog_format = MIXED
#二进制日志有三种不同的记录格式：STATEMENT（基于SQL语句）（默认）、ROW（基于行）、MIXED（混合模式），默认为STATEMENT
server-id = 1
#server-id 为服务的序号，在MySQL主备、高可用中需要指定服务的序号
systemctl resart mysqld
#改为配置文件需要重启服务
1.3 查看二进制文件的内容
开启了二进制文件，会在/data目录下生成二进制文件，但是直接使用cat查看的时候出现乱码，所以需要指定编码格式和解码进行查看
mysqlbinlog --no-defults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000001 >/opt/mysql-bin.000001
#可以将日志文件解码至/opt目录下导出为txt格式查看
或
cp /usr/local/mysql/data/mysql-bin.000001 /opt
#把日志文件复制到/mnt目录下慢慢看,可以直接使用cat查看
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000001
#--no-defaults：默认字符集（不加会报UTF-8错误）
#--base64-output=decode-rows：使用64位编码机制去解码（decode）并按行读取（rows）
-v：显示详细内容
mysqladmin -uroot -p123456 flush-logs
#刷新二进制日志文件（为了不重启，进行刷新，这样二进制文件会重新生成一个，相当于增量备份）
日志文件内容解析（需要关注的点）
at 8901
#220918? 1:30:43 server id 1? end_log_pos 9202 CRC32 0x77b8be71 ?? ?Query?? ?thread_id=29 exec_time=0?? ?error_code=0
SET TIMESTAMP=1663479043/*!*/;
CREATE TABLE `info` (
? `id` int(4) NOT NULL AUTO_INCREMENT,
? `name` varchar(10) NOT NULL,
? `age` char(10) NOT NULL,
? `hobby` varchar(50) DEFAULT NULL,
? PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8
# at 9202
#220918? 1:30:43 server id 1? end_log_pos 9267 CRC32 0xeb7e2383 ?? ?Anonymous_GTID?? ?last_committed=39?? ?sequence_number=40?? ?rbr_only=no解析
at 8901???? #开始的为支点
220918? 1:30:43???? #开始的时间点
end_log_pos 9202??? #结束的位置点
CREATE TABLE `info`????? #执行的具体操作
at 9202??????????? #结束的位置点以及下一次任务开始的位置点
220918? 1:30:43????? #结束的时间点以及下一次任务开始的时间点
2、增量备份（完备+增倍）
增量备份是基于完全备份或增量备份的，所以我们直接完全备份数据库
2.1 对表进行完全备份
mysqldump -uroot -p123456 jn pokemon > /opt/jn_pokemon-$(date +%F).sql
#使用mysqldump对ngs库中的info表进行完全备份数据库
mysqladmin -u root -p flush-logs
?2.2 在表中增加数据再进行增量备份
在表中插入新的数据
3、增量恢复
3.1 增量恢复之一般恢复
mysql -uroot -p123456 -e 'drop table jn.pokemon;'
#模拟ngs库中的info表中的数据全部丢失
mysql -uroot -p123456 -e 'use jn;show tables;'
现在需要还原info表，且还要恢复里面的两条数据
mysql -uroot -p123456 jn < /opt/jn_pokemon-2022-09-18.sql
#先进行完全恢复，（但完全恢复的文件中，info表中只有两条数据）
mysqlbinlog --no-defaults /usr/local/mysql/data/mysql-bin.000007 | mysql -uroot -p123456
#基于mysql-bin.000005日志文件恢复（恢复ngs.info表中的另一条数据）
3.2 增量恢复之断点恢复
mysqldump -uroot -p123456 ning food > /opt/ning_food.sql
#完全备份info表（表中有3条数据）
mysqladmin -uroot -p123456 flush-logs
#刷新二进制日志文件
?先进行完全备份当前jn库中的go表
?在food表中新插入3条数据（现有6条数据）
?现在进行增量备份新插入3条数据的日志文件
现在有人不小心删除了class表中相关的数据，但现在客户只想恢复前4条数据，最后一条数据不想要了
???? 3.2.1基于位置恢复-at
mysql -uroot -p123456 ning < /opt/ning_food.sql
#完全恢复前3条数据
mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000012 > /opt/mysql-bin.000222
#将日志文件重定向到/opt目录下，方便查看，查看到第5条数据的位置点
vim /opt/mysql-bin.000222
?
查找到第五条语句的结束为止为：718
先进行完全备份恢复到三条数据
?再基于位置节点进行恢复
???? 3.2.2基于位置跳点进行恢复
只想恢复前三条数据和第五条数据
mysql -uroot -p123456 school < /opt/ning_food.sql
#完全恢复前两条数据
mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000012 > /opt/mysql-bin.000223
#将日志文件重定向到/opt目录下，方便查看，查看到第5条数据的位置点
vim /opt/mysql-bin.000222
?首先完全恢复前三条数据
?查看第四条数据语句中的起始点（580）和结束点（718）
mysqlbinlog --no-defaults --start-position='580' --stop-position='718' /usr/local/mysql/data/mysql-bin.000012 | mysql -uroot -p123456
mysql -uroot -p123456 -e 'use ning;select * from food'
???? 3.2.3基于时间恢复
基于时间恢复和基于位置恢复时基本类似，现在基于时间节点来恢复第六条数据
mysql -uroot -p123456 -e 'drop table ning.food;'
#模拟数据丢失
mysql -uroot -p123456 ning < /opt/ning food.sql
#先进行完全恢复，恢复完全备份中的两条数据
vim /opt/mysql-bin.000222
#查看第六条数据执行结束的时间节点
?完全恢复前三条语句
基于时间节点进行恢复，查看第三条数据执行结束的时间节点（22-09-19 14:39:02）
mysqlbinlog --no-defaults --stop-datetime='22-09-19 14:39:02' /usr/local/mysql/data/mysql-bin.000012 | mysql -uroot -p123456
#进恢复到第六条数据执行的结束时间
mysql -uroot -p123456 -e 'use ning;select * from food;'
总结
1、备份的类型
物理备份、逻辑备份
2、物理备份：冷备、温备、热备
①冷备： 需要关闭mysql服务，或者确保mysql服务在进行tar备份时，没有客户端的写入操作
②温备： mysqldump，这个是mysql自带的备份工具
特性： 逐表备份，每备份一张表时，会先drop删除，然后重新create创建表结构，然后再解锁表
（仅锁定写的操作，但可读），进行insert语句的备份，备份完成后，进行unlock解锁，然后继续备份下一个。
③热备： xtrabackup或mysqlhotcopy等热备工具（第三方），在mysql正常运行时，进行备份。
3、逻辑备份：全量备份、增量备份、差异备份
①全量备份： tar压缩、mysqldump -u -p --all-databases
②增量备份： 主要使用bin-log，来舒心生成新的增备的日志文件，可以通过：mysqladmin -u -p fiush-logs 来刷新生成新的增备的日志文件，同时可以结合crontan，完成自动刷新。
注意： 再进行基于二进制文件的备份恢复时，有必要的话，需要先回复完备的数据，再逐个恢复增备的数据，直到恢复至我们需要恢复的数据为止。
③差异备份： 主要备份一次完备，后面修改的数据全部基于完备进行恢复。（相当于快照）
4、日志的保存类型
①混合模式Mixed（建议使用）： 记录行和sql
②基于行ROWS： 只记录被修改的行的记录
③基于sql（默认）： 记录修改内容的执行语句
5、mysql恢复的方式
①基于冷备（tar）形式：t ar zxvf解压打包的/usr/local/mysql/data数据下的内容
②基于自带的温备工具： 使用mysqldump进行备份后，可使用两种方式进行恢复
mysql -u -p 库名 </opt/mysql_all.sql（备份文件的路径）
mysql -u -p -e ’ source /opt/mysql_all.sql’ 直接使用source进行恢复
③基于日志：bin-log
首先开启二进制日志的配置log-bin=mysql-bin ；log_format=MIXED
然后再/usr/local/mysql/data 目录下，会生成mysql-bin.00000x的二进制文件进行恢复
接着使用mysqlbinlog --no-defaults 二进制日志路径|mysql -u -p 基于完整的二进制日志文件进行恢复。
基于位置点和时间点进行恢复
使用mysqlbinlog --no-defaults --base64-output-decode-rows -v 二进制日志文件路径，查看正确和需要跳过的错误操作的at（position位置带点）和datetime（时间点）来进行恢复
?