文章目录

• 前言
• mysql日志
• • 日志的类型
  • redo 重做日志
  • undo 回滚日志
  • errorlog 错误日志
  • slow query log 慢查询日志
  • bin log 二进制日志
  • relay log 中继日志
  • general log 普通日志
• MySQL日志相关配置文件
• mysql备份
• • 备份类型
  • • 物理备份
    • 逻辑备份
    • • 完全备份
      • 差异备份
      • 增量备份
      • 备份方式比较
  • 常见的备份方法
  • • 物理冷备
    • 专用备份工具
    • 启用二进制日志进行增量备份
    • 第三方工具备份
• MySQL完全备份
• • 优点：
  • 缺点：
  • 数据库完全备份分类
  • • 物理冷备份与恢复
    • mysqldump备份与恢复
• 实验
• 冷备份
• 温备份
• MySQL增量备份与恢复
• • 一般恢复
  • 基于位置恢复
  • 基于时间点恢复
  • MySQL增量备份实验脚本
  • 增量备份实验
  • • 一般恢复
    • 模拟丢失所有数据的恢复步骤
    • 基于位置恢复

前言

mysql日志

备份的主要目的是灾难恢复，备份还可以测试应用、回滚数据修改、查询历史数据、审计等。

MySQL 的日志默认保存位置为： /usr/local/mysql/data

日志的类型

redo 重做日志

达到事务一致性（每次重启会重做）
确保日志的持久性，防止在发生故障，脏页未写入磁盘。重启数据库会进行redo log执行重做，达到事务一致性

undo 回滚日志

保证数据的原子性，记录事务发生之前的一个版本，用于回滚，innodb事务可重复读和读取已提交 隔离级别就是通过mvcc+undo实现

errorlog 错误日志

Mysql本身启动，停止，运行期间发生的错误信息

slow query log 慢查询日志

记录执行时间过长的sql，时间阈值（10s）可以配置，只记录执行成功

另一个作用：在于提醒优化

慢查询日志会问的面试题：

1. 慢查询日志记录的数据是什么数据，你们给的阈值是多少？
2. 体现在mysql优化这里，开启慢查询日志，然后根据慢查询日志种记录的语句，来排查定位
   查询时间过长的语句，从而找到对应的表，考虑，是否需要对此表进行优化（索引、分库、分表优化、主外键关联、存储过程）

bin log 二进制日志

用于基于日志形式的数据恢复，用于主从复制，实现主从同步

记录的内容是：数据库中执行的sql语句

relay log 中继日志

用于数据库主从同步，将主库发来的bin log保存在本地，然后从库进行回放

general log 普通日志

记录数据库的操作明细，默认关闭，开启后会降低数据库性能

MySQL日志相关配置文件

vim /etc/my.cnf
 
[mysqld]
 
##错误日志，用来记录当MySQL启动、停止或运行时发生的错误信息，默认已开启
 
log-error=/usr/local/mysql/data/mysql_error.log     
##指定日志的保存位置和文件名
 
##通用查询日志，用来记录MySQL的所有连接和语句，默认是关闭的
 
general_log=ON
 
general_log_file=/usr/local/mysql/data/mysql_general.log
 
##二进制日志(binlog)，用来记录所有更新了数据或者已经潜在更新了数据的语句，记录了数据的更改，可用于数据恢复，默认已开启
 
log-bin=mysql-bin      
或
log_bin=mysql-bin
 
##中继日志
一般情况下它在Mysql主从同步（复制）、读写分离集群的从节点开启。主节点一般不需要这个日志
 
 
##慢查询日志，用来记录所有执行时间超过long_query_time秒的语句，可以找到哪些查询语句执行时间长，以便提醒优化，默认是关闭的
 
s1ow_query_log=ON
 
slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log
 
long_query_time=5        #设置超过5秒执行的语句被记录，缺省时为10秒

show variables like 'general%';      
 #查看通用查询日志是否开启

 show variables like 'log_bin%';       
 #查看二进制日志是否开启

``c
show variables like ‘%slow%’;
#查看慢查询日功能是否开启

![在这里插入图片描述](https://img-blog.csdnimg.cn/dad4bf547d014f41b64777d70d7ee8ea.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LiA6Imy6IKh5aSn6LeM,size_20,color_FFFFFF,t_70,g_se,x_16)


```c
show variables like 'long_query_time';    
#查看慢查询时间设置

set global slow_query_log=ON;         
#在数据库中设置开启慢查询的方法

注：variables 表示变量 like 表示模糊查询

二进制日志开启后，重启mysql 会在目录中查看到二进制日志

#开启二进制日志时会产生一个索引文件及一个索引列表

索引文件：记录更新语句
索引文件刷新方式：
1、重启mysql的时候会更新索引文件，用于记录新的更新语句
2、刷新二进制日志

mysql-bin.index：·二进制日志文件的索引

mysql备份

前言：
备份的主要目的是灾难恢复
在生产环境中，数据的安全性至关重要
任何数据的丢失都可能产生严重的后果
造成数据丢失的原因

备份类型

物理备份

数据库备份可以分为物理备份和逻辑备份。物理备份是对数据库操作系统的物理文件（如数据文件、日志文件等）的备份。
这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据库。

**物理备份又可以成为冷备份（脱机备份）、热备份（连接备份）和温备份 **

1. 冷备份 (脱机备份) ：是在关闭数据库的时候进行的（tar）
2. 热备份 (联机备份) ：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopy mysqlbackup 第三方工具）
3. 温备份 ：数据库锁定表格(不可写入但可读)的状态下进行备份操作（mysqldump）

逻辑备份

逻辑备份是对数据库逻辑组件的备份.表示为逻辑数据库结构
这种类型的备份适用于可以编辑数据值或表结构

从数据库的备份策略角度来看，备份又可分为完全备份、差异备份和增量备份

完全备份

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

差异备份

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

增量备份

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

备份方式比较

逻辑备份的策略：增、全、差异
合理值区间

常见的备份方法

物理冷备

备份时数据库处于关闭状态，直接打包数据库文件（tar）
备份速度快，恢复时也是最简单的

缺陷：数据的实时性较差，不能在业务正常运行时进行tar备份 -》服务停止的时候(否则可能产生数据丢失的情况)

专用备份工具

mysqldump 或 mysqlhotcopy
mysqldump 常用的逻辑备份工具（mysql自带）

mysqlhotcopy 仅拥有备份 MyISAM 和 ARCHIVE 表

启用二进制日志进行增量备份

进行增量备份，需要刷新二进制日志

第三方工具备份

免费的MySQL 热备份软件 Percona XtraBackup mysqlbackup

MySQL完全备份

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

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

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

优点：

备份与恢复操作简单方便

缺点：

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

数据库完全备份分类

物理冷备份与恢复

关闭MySQL数据库

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

直接替换现有MySQL目录即可（/usr/local/mysql/data 数据目录）

mysqldump备份与恢复

MySQL自带的备份工具，可方便实现对MySQL的备份

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

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

实验

冷备份

温备份

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

mysqldump -u root -p[密码] --databases 库名1 [库名2] … > /备份路径/备份文件名.sql	

mysqldump -uroot -p123456 --databases boke > /opt/mysql_bak/boke.sql

mysqldump -uroot -p123456 --databases boke school > /opt/mysql_bak/boke_school

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

格式：
mysqldump -u root -p[密码] --all-databases > /备份路径/备份文件名.sql

mysqldump -uroot -p123456 --all-databases > /opt/mysql_bak/all.sql

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

格式；
mysqldump -u root -p[密码] 库名 [表名1] [表名2] … > /备份路径/备份文件名.sql

mysqldump -uroot -p boke xues kkk > /opt/mysql_bak/boke_xues_kkk.sql

查看备份文件

cat boke_xues_kkk.sql | grep -v '^/' | grep -v '^$' | grep -v '^-'

MySQL增量备份与恢复

MySQL数据库增量恢复（基于日志文件）

一般恢复

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

基于位置恢复

数据库在某一时间点可能既有错误的操作也有正确的操作
可以基于精准的位置跳过错误的操作发生错误节点之前的一个节点，上一次正确操作的位置点停止

基于时间点恢复

跳过某个发生错误的时间点实现数据恢复
在错误时间点停止，在下一个正确时间点开始

MySQL增量备份实验脚本

1.开启二进制日志功能

 vim /etc/my.cnf
[mysqld]
log-bin=mysql-bin
binlog_format = MIXED      #可选，指定二进制日志(binlog)的记录格式为MIXED（混合输入）
server-id = 1                        #可加可不加该命令

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

1. STATEMENT（基于SQL语句）:

每一条涉及到被修改的sql 都会记录在binlog中
缺点：日志量过大，如sleep()函数，last_insert_id()>，以及user-defined fuctions（udf）、主从复制等架构记录日志时会出现问题

2. ROW(基于行)

只记录变动的记录，不记录sql的上下文环境
缺点:如果遇到update…set…where true 那么binlog的数据量会越来越大
create table info
insert into info values(1,‘zhangsan’);
insert into info values(2,‘lisi’);
delete id=zhangsan

3. MIXED (推荐使用)

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

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

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. at ：开始的位置点
2. end_log_pos：结束的位置
3. 时间戳： 210712 11:50:30
4. SQL语句

增量备份实验

一般恢复

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

模拟丢失更改的数据的恢复步骤：

use boke;
delete from kaka where id=8;
delete from kaka where id=9;
 
mysqlbinlog --no-defaults /usr/local/mysql/data/mysql-bin.000004 | mysql -u root -p

模拟丢失所有数据的恢复步骤

 use boke
drop table kaka;
 
mysql -uroot -p boke < /opt/boke_kaka.sql

mysqlbinlog --no-defaults /usr/local/mysql/data/mysql-bin.000007  | mysql -u root -p 

基于位置恢复

1. 数据库在某一时间点可能既有错误的操作也有正确的操作
2. 可以基于精准的位置跳过错误的操作
3. 发生错误节点之前的一个节点，上一次正确操作的位置点停止

insert into kaka values(8,'kuaile',80,'nanjing',6)


mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.0000008

# at 298
#220409 11:47:21 server id 1  
insert into kaka values(8,'kuaile',80,'nanjing',6)

再插入一条数据

insert into kaka values(9,'wushu',80,'shanghai',4)

以上插入的数据都存放在mysql-bin.00008

测试恢复到ID为 597 之前的数据， 不恢复“后面一条”的数据

#删除数据之前必须先刷新一下日志文件
mysqladmin -u root -p flush-logs 

对数据进行恢复

mysqlbinlog --no-defaults --stop-position='597' mysql-bin.000008 | mysql -u root -p

仅恢复“最后一条”的数据，跳过“前面多条”的数据恢复
删除表中所有数据


基于时间恢复

#提前创建好库和表格后 刷新（mysqladmin -uroot -p123456 flush-logs）
#然后在表格中添加两条数据
 use kkk
insert into kkkk values(1,18);
insert into kkkk values(2,58);

#退出数据库 刷新（生成mysql-bin.000008）
mysqladmin -uroot -p123456 flush-logs

#查看二进制日志   （mysql-bin.000007） 
#日志中会有插入语句的时间点
 mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000007
 
 #进入数据库，删除数据
 mysql -uroot -p123456
use kkk
delete from kkkk;

#基于时间点 恢复表格到删除第二条数据之前  #进入数据库查看表格
mysqlbinlog --no-defaults --stop-datetime='2022-04-09 21:15:00' /usr/local/mysql/data/mysql-bin.000007 | mysql -uroot -p123456

#基于时间点 恢复表格到删除第二条数据之后  #进入数据库查看表格
mysqlbinlog --no-defaults --start-datetime='2022-04-09 21:15:00' /usr/local/mysql/data/mysql-bin.000007 | mysql -uroot -p123456