引言：

在生产环境中，数据的安全性至关重要，任何数据的丢失都可能产生严重的后果，那么对于数据的备份就将显的十分重要。对于MySQL而言，在其备份中，日志起到了很重要的作用

一、MySQL日志管理

MySQL的日志默认保存位置为：/usr/local/mysql/data下
配置文件位于：/etc/my.cnf文件中的[mysqld]内

1.1 日志分类

1.1.1 错误日志
用来记录当MySQL启动、停止或运行时发生的错误信息，默认开启

general_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
1
2

1.1.2 通用查询日志
用来记录MySQL的所有连接和语句，默认是关闭的

general_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
1
2

1.1.3 二进制日志
用来记录所有更新了数据或者已经潜在更新了数据的语句，记录了数据的更改，可用于数据恢复，默认已开启

log_bin=mysql-bin
或 log-bin=mysql-bin
1
2

1.1.4 慢查询日志
用来记录所有执行时间超过long_query_time秒的语句，可以找到哪些查询语句执行时间长，以便于优化，默认是关闭的

slow_query_log=ON
slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log
long_query_time=5 单位时间为s，缺省时为10s
1
2
3

1.1.3 二进制日志
用来记录所有更新了数据或者已经潜在更新了数据的语句，记录了数据的更改，可用于数据恢复，默认已开启

log_bin=mysql-bin
或 log-bin=mysql-bin
1
2

1.1.4 慢查询日志
用来记录所有执行时间超过long_query_time秒的语句，可以找到哪些查询语句执行时间长，以便于优化，默认是关闭的

slow_query_log=ON
slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log
long_query_time=5 单位时间为s，缺省时为10s
1
2
3

慢查询日志也可用来查询哪些搜索的字段超时，可以选择是否需要增加索引，加快查询速度

1.1.5 中继日志
一般情况下，它在MySQL主从同步（复制）、读写分离集群的从节点开启，主节点一般不需要这个日志

1.2 日志配置

修改配置文件
vim /etc/my.conf

#错误日志
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 mysql
1
2
3
4
5
6
7
8
9
10
11
12
13

修改my.cnf配置文件，在[mysqld]中添加如下内容

重启服务

1.3日志查询
登入MySQL数据库，查询日志是否开启

#variables 表示变量
#like 表示模糊查询
#%xxx，以什么结尾，xxx%以什么开头，%xxx%包含
#查看通用查询日志是否开启
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
2
3
4
5
6
7
8
9
10
11
12
13

1.3.1 查询通用日志是否开启

show variables like ‘general%’; 
1

1.3.2 查询二进制日志是否开启

show variables like ‘log_bin%’;
1

1.3.3 查看慢查询日志是否开启

show variables like ‘long_query_time’;
1

1.3.4 查询慢查询日志超时时间

show variables like ‘long%’;
1

二、数据备份

2.1 概述

备份的主要目的是灾难恢复

还可以用来测试应用、回滚数据修改、查询历史数据、审计等

2.2 数据备份的重要性

在企业中，数据的价值至关重要，数据保障了企业业务的正常运行。因此，数据的安全性及数据的可靠性是运维的重中之重，任何数据的吊事都可能对企业产生严重的后果。

通常情况下，造成数据丢失的原因有一下几种：

程序错误
人为操作错误
运算错误
磁盘故障
灾难（火灾、地震、盗窃等）

2.3 备份类型

2.3.1 从物理与逻辑的角度分类（逻辑备份、物理备份）
数据库备份可以分为物理备份和逻辑备份。

逻辑备份是对数据库逻辑组件(如表等数据库对象)的备份,表及数据库结构(CREATE DATABASE, CREATETABLEia)和内容(INSERT语句或分隔文本文件)的信息。
逻辑备份适用于可以编辑数据值或表结构较小的数据量,或者在不同的机器体系结构上重新创建数据
物理备份是对数据库操作系统的物理文件(如数据文件、日志文件等)的备份。
物理备份适用于在出现问题时需要快速恢复的大型重要数据库。
物理备份又可以分为冷备份(脱机备份)、热备份(联机备份)和温备份。
冷备份:在数据库关闭状态下进行备份操作。（tar）
热备份:在数据库处于运行状态时进行备份操作,该备份方法依赖数据库的日志文件。（mysqldump）
温备份:数据库锁定表格(不可写入但可读)的状态下进行备份操作。
2.3.2 从数据库的备份策略角度分类（完全备份、差异备份、增量备份）
从数据库的备份策略角度，数据库的备份可分为完全备份、差异备份和增量备份(面试点)。

完全备份：每次对数据进行完整的备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完成时刻的数据库，是差异备份与增量备份的基础。完全备份的备份与恢复操作都非常简单方便，但是数据存在大量的重复，并且会占用大量的磁盘空间，备份的时间也很长。

差异备份：备份那些自从上次完全备份之后被修改过的所有文件，备份的时间节点是从上次完整备份起，备份数据量会越来越大。恢复数据时，只需恢复上次的完全备份与最近的一次差异备份。

增量备份：只有那些在上次完全备份或者增量备份后被修改的文件才会被备份。以上次完整备份或上次增量备份的时间为时间点，仅备份这之间的数据变化，因而备份的数据量小，占用空间小，备份速度快。但恢复时，需要从上一次的完整备份开始到最后一次增量备份之的所有增量依次恢复，如中间某次的备份数据损坏，将导致数据的丢失。

2.4 备份方法

数据库的备份可以采用很多种方式，如直接打包数据库文件（物理冷备份）、专用备份工具(mysqldump)、二进制日志增量备份、第三方工具备份等。

2.4.1 物理冷备份

物理冷备份时需要在数据库处于关闭状态下，能够较好地保证数据库的完整性。
物理冷备份一般用于非核心业务，这类业务一般都允许中断。
物理冷备份的特点就是速度快，恢复时也是最为简单的。
通常通过直接打包数据库文件夹(/usr/local/mysql/data)来实现备份。
2.4.2 专用备份工具 mysqldump 或 mysqlhotcopy
mysqldump程序和mysqlhotcopy都可以做备份。
mysqldump是客户端常用逻辑备份程序，能够产生一组被执行以后再现原始数据库对象定义和表数据的SQL语句。它可以转储一个到多个MySQL数据库，对其进行备份或传输到远程SQL服务器。mysqldump更为通用，因为它可以备份各种表。
mysqlhotcopy仅适用于某些存储引擎（MyISAM和ARCHIVE）。
2.4.3 通过启用二进制日志进行增量备份
支持增量备份，进行增量备份时必须启用二进制日志。
二进制日志文件为用户提供复制，对执行备份点后进行的数据库更改所需的信息进行恢复。
如果进行增量备份(包含自上次完全备份或增量备份以来发生的数据修改) ，需要刷新二进制日志。
2.4.4 通过第三方工具备份
第三方工具Percona xtraBackup是一个免费的MysQL热备份软件，支持在线热备份Innodb和xtraDB，也可以支持MySQL表备份，不过MyISAM表的备份要在表锁的情况下进行。

三、MySQL完全备份

是对整个数据库、数据库结构和文件结构的备份

保存的是备份完成时刻的数据库

是差异备份与增量备份的基础

优点：备份与恢复操作简单方便

缺点：数据存在大量的重复、占用大量的备份空间、备份与恢复时间长

3.1 数据库完全备份分类

3.1.1 物理冷备份与恢复
关闭MySQL数据库

使用tar命令直接打包数据库文件夹

直接替换现有MySQL目录即可

3.1.2 mysqldump备份与恢复
MySQL自带的备份工具，可方便实现对MySQL的备份

可以将指定的库、表导出为SQL 脚本

使用命令mysq|导入备份的数据

四、MySQL完全备份与恢复

4.1 物理冷备份与恢复

systemctl stop mysqld
yum -y install xz
 
#压缩备份
cd /usr/local/mysql/data
tar jcvf mysql_all_$(date +%F).tar.xz /usr/local/mysql/data
systemctl start mysqld
 
#模拟故障，删除数据库
drop database njzb;
 
#解压恢复
tar jxvf /opt/mysql_all_2022-06-22.tar.xz -C /usr/local/mysql/data
cd /usr/local/mysql/data
mv usr/local/mysql/data/* ./
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

模拟故障，删除库njzb

恢复故障

4.2 mysqldump 完全备份与恢复（温备份）

4.2.1 完全备份一个或多个完整的库 (包括其中所有的表)

mysqldump -u root -p[密码] --databases 库名1 [库名2] ... > /备份路径/备份文件名.sql   
#导出的就是数据库脚本文件
 
例:
 
mysqldump -u root -p --databases ky17 > /opt/hobby.sql       #备份一个kgc库
mysqldump -u root -p --databases mysql hobby > /opt/mysql-hobby.sql    #备份mysql与 hobby两个库

1
2
3
4
5
6
7
8

备份hobby库

备份hobby库中的test01表

备份hobby库中test02表的数据结构

4.2.2 完全备份 MySQL 服务器中所有的库

mysqldump -u root -p[密码] --all-databases > /备份路径/备份文件名.sql
 
例:
 
mysqldump -u root -p --all-databases > /opt/all.sql
1
2
3
4
5

4.2.3 完全备份指定库中的部分表

mysqldump -u root -p[密码] 库名 [表名1] [表名2] ... > /备份路径/备份文件名.sql
 
例:
 
mysqldump -u root -p [-d] kgc info1 info2 > /opt/kgc_info1.sql
 
#使用“-d”选项，说明只保存数据库的表结构
 
#不使用“-d"选项，说明表数据也进行备份
 
#做为一个表结构模板
1
2
3
4
5
6
7
8
9
10
11

4.2.4 查看备份文件

grep -v "^--" /opt/kgc_info1.sql | grep -v "^/" | grep -v "^$"
1

4.3 恢复数据库

方法一：source恢复

使用mysqldump导出的文件，可使用导入的方法
 
source命令  进入数据库  
 
mysql> source  /opt/kgc.sql ------>备份文件路径
 
登录到MySQL数据库，执行source备份sql脚本的路径
1
2
3
4
5
6
7

方法二：mysql恢复

mysql -uroot -p123456 < /opt/hobby.sql
1

4.4 恢复表（依据上面备份的test01表进行）

方法一：source恢复



方法二：mysql恢复

PS:mysqldump 严格来说属于温备份，会需要对表进行写入的锁定

在全量备份与恢复实验中，假设现有school库，school库中有一个class表，需要注意的一点为：

① 当备份时加 --databases ,表示针对于school库
#备份命令
mysqldump -uroot -p123456 --databases school > /opt/school_01.sql 备份库后
 
#恢复命令过程为：
mysql -uroot -p123456
drop database school;
exit
mysql -uroot -p123456 < /opt/school_01.sql
1
2
3
4
5
6
7
8
9
10
11
12
13

② 当备份时不加 --databases，表示针对school库下的所有表

当备份时不加 --databases，表示针对school库下的所有表
 
#备份命令
mysqldump -uroot -p123456 hobby > /opt/hobby_02.sql
 
#恢复过程：
mysql -uroot -p123456
drop database hobby;
create database hobby;
exit
mysql -uroot -p123456 school < /opt/hobby_02.sql
1
2
3
4
5
6
7
8
9
10
11

查看school_01.sql 和school_02.sql

主要原因在于两种方式的备份（前者会从"create databases"开始,而后者则全是针对表格进行操作）

③在生产环境中，可以使用Shell脚本自动实现定时备份（时间频率需要确认）

0 1* * 7 /usr/local/mysql/bin/mysqldump -uroot -p123456 kgc info1 > ./kgc_infol_$(date +%Y%m%d).sql ;
/usr/local/mysql/bin/mysqladmin -u root -p flush-logs
1
2

五、MySQL 增量备份与恢复

5.1 恢复的方式

5.1.1 一般恢复
将所有备份的二进制日志内容全部恢复

5.1.2 基于位置恢复
数据库在某一时间点可能既有错误的操作也有正确的操作

可以基于精准的位置跳过错误的操作

发生错误节点之前的一个节点，上一次正确操作的位置点停止

5.1.3 基于时间点恢复
跳过某个发生错误的时间点实现数据恢复

在错误时间点停止，在下一个正确时间点开始

5.2 二进制文件介绍

5.2.1 开启二进制日志功能

5.2.2 二进制日志(binlog)的3种不同的记录格式
STATEMENT (基于SQL语句)、ROW(基于行)、MIXED(混合模式)，默认格式是STATEMENT

① STATEMENT（基于SQL语句）

每一条涉及到被修改的sql 都会记录在binlog中

缺点：日志量过大，如sleep()函数，last_insert_id()>，以及user-defined fuctions（udf）、主从复制等架构记录日志时会出现问题

② ROW(基于行)

只记录变动的记录，不记录sql的上下文环境

缺点:如果遇到update…set…where true 那么binlog的数据量会越来越大

③ MIXED 推荐使用

一般的语句使用statement，函数使用ROW方式存储。

5.2.3 查看二进制日志文件的内容

cp /usr/local/mysql/data/mysql-bin.000002 /opt/
 
mysqlbinlog --no-defaults  /opt/mysql-bin.000002
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
 
#--base64-output=decode-rows：使用64位编码机制去解码（decode）并按行读取（rows）
#-v: 显示详细内容
#--no-defaults : 默认字符集（不加会报UTF-8的错误）
PS: 可以将解码后的文件导出为txt格式，方便查阅
 
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002 > /opt/mysql-bin.000002
1
2
3
4
5
6
7
8
9
10
11

5.2.4 二进制日志中需要关注的部分

1、at ：开始的位置点

2、end_log_pos：结束的位置

3、时间戳： 210712 11:50:30

4、SQL语句

5.3 增量备份过程（全备+增备）

使用mysqldump

可每天进行增量备份操作，生成新的二进制日志文件(例如:mysql-bin.000006)
 
mysqladmin -u root -p flush-logs
1
2
3

新生成一个二进制备份文件

插入新数据，以模拟数据的增加或变更

PS:在第一次完全备份之后刷新二进制文件，在第二个二进制文件中记载着"增量备份的数据

在kgc库中创建表sss,并插入数据

创建NJ库，并复制kgc库中的sss表，命名为ZB表

再次生成新的二进制日志文件(例如:mysql-bin.000007)
 
mysqladmin -u root -p flush-logs
 
#之前的步骤创建kgck库中的sss表和创建NJ库以及库中的ZB表的操作会保存到mysql-bin.000006文件中
1
2
3
4
5

5.4 增量恢复

全部恢复

模拟所有数据丢失，直接删除kgc和NJ两个库

先恢复完全备份

基于mysql-bin.000006恢复增量，恢复所有
 
mysqlbinlog --no-defaults / usr/local/mysql/data/mysql-bin.000006 | mysql -uroot -p123456
1
2
3

5.5 断点恢复

#查看日志
mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000006
1
2

基于位置点恢复
#仅恢复到操作 ID 为“623"之前的数据，即不恢复"user4"的数据
 
mysqlbinlog --no-defaults --stop-position='1793' /opt/mysql-bin.000002 | mysql -uroot -p密码
#仅恢复"user4"的数据，跳过"user3"的数据恢复
 
mysqlbinlog --no-defaults --stop-position='623' /opt/mysql-bin.000002 | mysql -uroot -p
mysqlbinlog --no-defaults --start-position='400' --stop-position='623' /opt/mysql-bin.000002 | mysql -uroot -p      
#恢复从位置为400开始到位置为623为止
1
2
3
4
5
6
7
8
9

5.6 基于时间点恢复

#仅恢复到16:41:24 之前的数据，即不恢复"user4"的数据
mysqlbinlog --no-defaults --stop-datetime='2020-11-22 16:41:24' /opt/mysql-bin.000002 | mysql -uroot -p
 
#仅恢复"user4"的数据，跳过"user3"的数据恢复
mysqlbinlog --no-defaults --start-datetime='2020-11-2216:41:24' /opt/mysql-bin.000002 | mysql -uroot -p
 
如果恢复某条SQL语之前的所有数据，就stop在这个语句的位置节点或者时间点
如果恢复某条SQL语句以及之后的所有数据，就从这个语句的位置节点或者时间点start
1
2
3
4
5
6
7
8

5.7 实验

只恢复到SSS表的第一条数据，不恢复NJ库的创建

5.7.1 基于节点

mysqlbinlog --no-defaults --stop-position='855' /usr/local/mysql/data/mysql-bin.000006 | mysql -uroot -p123456
1

5.7.2 基于时间节点

六、总结

1.在增量备份恢复时，要先从完全备份恢复，再到二进制日志1、日志2…逐一恢复
2.如果恢复某条SQL语句之前的所有数据，就stop在这个语句的位置节点或者时间点
3.如果恢复某条SQL语句以及之后的所有数据，就从这个语句的位置节点或者时间点start
4.全备库中source针对库mysql针对库中的表，备份时使用–database或者-B使恢复时source和mysql效果一致。