mysql日志备份、管理与恢复

1、mysql日志管理

 日志文件在数据库进行备份和恢复时起到了很重要的作用

常用的日志文件默认保存在 /usr/local/mysql/data 目录下

可在 /etc/my.cnf 配置文件中的 [mysqld] 中进行日志的路径修改、开启、关闭等操作

日志类型与作用：

1、redo 重做日志：达到事务一致性（每次重启会重做）

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

2、undo 回滚日志

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

3、errorlog 错误日志

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

4、slow query log 慢查询日志

作用：记录执行时间过长的sql，时间阈值（10s）可以配置，只记录执行成功
另一个作用：在于提醒优化
慢查询日志mst：

① 慢查询日志 记录的数据是什么数据，你们给的阈值是多少？

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

5、bin log 二进制日志

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

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

6、relay log 中继日志

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

7、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秒

 进入maysql输入

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;      

show variables like '%slow%' 

#在数据库中设置开启慢查询的方法

 二进制日志开启后，重启mysql服务，可以在mysql安装目录下data目录看见二进制日志文件

 

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

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

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

2、mysql备份

概述

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

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

备份的重要性

 在企业中，数据的价值至关重要，数据保障了企业业务的正常运行。

因此，数据的安全性及数据的可靠性是运维的重中之重，任何数据的吊事都可能对企业产生严重的后果。 通常情况下，造成数据丢失的原因有一下几种：

程序错误

人为操作错误

运算错误

磁盘故障

灾难（火灾、地震、盗窃等）

备份类型

物理备份

数据库备份可以分为物理备份和逻辑备份。物理备份是对数据库操作系统的物理文件（如数据文

件、日志文件等）的备份。这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据

库。

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

冷备份 (脱机备份) ：是在关闭数据库的时候进行的（tar）

热备份 (联机备份) ：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopymysqlbackup 第三方工具）

温备份 ：数据库锁定表格(不可写入但可读)的状态下进行备份操作（mysqldump）

逻辑备份

逻辑备份是对数据库逻辑组件的备份.表示为逻辑数据库结构

这种类型的备份适用于可以编辑数据值或表结构

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

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

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

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

常见的备份方法

物理冷备

备份时数据库处于关闭状态，直接打包数据库文件（tar）

备份速度快，恢复时也是最简单的

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

数据丢失的情况)

专用备份工具 mysqldump 或 mysqlhotcopy

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

mysqlhotcopy 仅拥有备份 MyISAM 和 ARCHIVE 表

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

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

第三方工具备份

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

mysql完全备份

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

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

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

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

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

数据库完全备份分类

1、物理冷备份与恢复

关闭MySQL数据库

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

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

2、mysqldump备份与恢复

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

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

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

3、实操

冷备份

原有哭

 

在执行压缩备份之前需关闭MySQL服务

systemctl stop mysqld

yum -y install xz

#压缩备份

tar Jcvf /opt/mysql_all_$(date +%F).tar.xz /usr/local/mysql/data/

mv /usr/local/mysql/data/ /opt/

 

 启动mysql服务进入mysql删除操作

 

 

 

重启服务

 在进入mysql

 

mysqldump 温备份

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

mysqldump -u root -p[密码] --databases 库名1 [库名2] ... > /备份路径/备份文件名.sql    #导出的就是数据库脚本文件

利用mysqldump进行一个备份 存放地址为home下 

 

 mysqldump

首先备份对象是数据库

备份过程：

①先create数据库

②use数据库

③开始备份数据表

④在此之前，需要做环境清理

⑤locak锁定将要备份的数据表的写入操作

⑥然后只需insert语句进行插入操作

⑦完成备份、解锁

⑧继续进行下一章表的环境清理和准备

mysqldump完全备份

 完全备份某个库某个表

 #使用“-d”选项，说明只保存数据库的表结构 
#不使用“-d"选项，说明表数据也进行备份
#做为一个表结构模板

查看备份文件

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

在mysql内进行恢复

 

 

 

在linux环境下恢复

 

 

4、mysql增量备份与恢复

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

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

2.基于位置恢复

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

3.基于时间点恢复

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

 

增量备份实操

在/etc/my.cnf中加入

 

二进制日志(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的数据量会越来越大
create table info 
insert into info values(1,'zhangsan');
insert into info values(2,'lisi');
delete id=zhangsan

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

 

重启服务

查看二进制文件

 进入服务，新建库和表

 解码查看二进制文件

 

 刷新重新生成新的二进制日志文件

 再次进入mysql操作，操作将会记录在新的二进制日志中

删除新建的表

然后我们可以基于二进制文件恢复

 进入mysql查看

 断点恢复

创建一个表

 将打错的最后一行进行断点恢复  此时数据备份存储位置是在mysql-bin.000003中

 

 按位置点恢复

先将此二进制文件转义  并查看 

 开始时间是373

 删除库

 mysqlbinlog --no-defaults --start-position='373' /data/mysql-bin.000003 | mysql -uroot -p

在进入mysql查询

 基于时间点恢复

在二进制文件中查看到373位置点的开始时间是220408 22：10：31

再次进入删除uuu库

然后基于时间点恢复

mysqlbinlog --no-defaults --start-datetime='2022-04-08 22:10:31' /opt/mysql-bin.000003 | mysql -uroot -p 
再次进入数据库查看