mysql日志管理 、备份与恢复

mysql日志管理 、备份与恢复

一、mysql常用日志

1、概述

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

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

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

①、错误日志

用于记录 mysql 启动、停止或运行时产生的错误信息

可通过一下字段进行更新

log-error=/usr/local/mysql/data/mysql_error.log （指定日志的保存位置和文件名）

②、二进制日志

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

开启方式：

log-bin=mysql-bin 或者 log_bin=mysql-bin

③、中继日志

一般情况下，它在 mysql 主从同步（复制）、读写分离集群的从节点上才开启。

主节点一般不需要这个日志。

④、慢查询日志

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

开启方式：

slow_query_log=ON

slow_query_log_file=/usr/local/mysql/data/mysql_slow_query.log （指定文件路径和名称）

long_query_time=5 （设置执行超过5秒的语句会被记录，缺省时默认为10秒）

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

general_log=ON

general_log_file=/usr/local/mysql/data/mysql_general.log

2、数据库中查询日志状态

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;         #在数据库中临时设置开启慢查询的方法

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

xxx% 以xxx为开头的字段

%xxx 以xxx为结尾的字段

%xxx% 只要出现xxx字段的都会显示出来

xxx   精准查询

①、查看二进制日志开启状态

二进制日志开启后，重启mysql 会在目录中查看到二进制日志，同时会产生一个索引文件及一个索引列表

索引文件：记录更新语句，mysql-bin.index：

索引文件刷新方式：

1、重启mysql的时候会更新索引文件，用于记录新的更新语句

2、刷新二进制日志

①、查看慢查询日志功能是否开启

①、查看慢查询时间设置

二、备份

1、概述

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

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

2、备份的重要性

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

因此，数据的安全性及数据的可靠性是运维的重中之重，任何数据的吊事都可能对企业产生严重的后果。

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

程序错误

人为操作错误

运算错误

磁盘故障

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

3、备份类型

①、从物理与逻辑的角度分类（逻辑备份、物理备份）

数据库备份可以分为物理备份和逻辑备份。

逻辑备份是对数据库逻辑组件(如表等数据库对象)的备份,表及数据库结构(CREATE DATABASE, CREATETABLEia)和内容(INSERT语句或分隔文本文件)的信息。

逻辑备份适用于可以编辑数据值或表结构较小的数据量,或者在不同的机器体系结构上重新创建数据

物理备份是对数据库操作系统的物理文件(如数据文件、日志文件等)的备份。

物理备份适用于在出现问题时需要快速恢复的大型重要数据库。

物理备份又可以分为冷备份(脱机备份)、热备份(联机备份)和温备份。

冷备份:在数据库关闭状态下进行备份操作。（tar）

热备份:在数据库处于运行状态时进行备份操作,该备份方法依赖数据库的日志文件。（mysqldump）

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

②、从数据库的备份策略角度分类（完全备份、差异备份、增量备份）

从数据库的备份策略角度，数据库的备份可分为完全备份、差异备份和增量备份(面试点)。

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

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

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

4、备份方法

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

①、物理冷备份

物理冷备份时需要在数据库处于关闭状态下，能够较好地保证数据库的完整性。

物理冷备份一般用于非核心业务，这类业务一般都允许中断。

物理冷备份的特点就是速度快，恢复时也是最为简单的。

通常通过直接打包数据库文件夹(/usr/local/mysql/data)来实现备份。

②、专用备份工具 mysqldump 或 mysqlhotcopy

mysqldump程序和mysqlhotcopy都可以做备份。

mysqldump是客户端常用逻辑备份程序，能够产生一组被执行以后再现原始数据库对象定义和表数据的SQL语句。它可以转储一个到多个MySQL数据库，对其进行备份或传输到远程SQL服务器。mysqldump更为通用，因为它可以备份各种表。

mysqlhotcopy仅适用于某些存储引擎（MyISAM和ARCHIVE）。

③、通过启用二进制日志进行增量备份

支持增量备份，进行增量备份时必须启用二进制日志。

二进制日志文件为用户提供复制，对执行备份点后进行的数据库更改所需的信息进行恢复。

如果进行增量备份(包含自上次完全备份或增量备份以来发生的数据修改) ，需要刷新二进制日志。

④、通过第三方工具备份

第三方工具Percona xtraBackup是一个免费的MysQL热备份软件，支持在线热备份Innodb和xtraDB，也可以支持MySQL表备份，不过MyISAM表的备份要在表锁的情况下进行。

5、MySQL完全备份

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

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

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

优点：

备份与恢复操作简单方便

缺点：

数据存在大量的重复

占用大量的备份空间

备份与恢复时间长

数据库完全备份分类

1、物理冷备份与恢复

关闭MySQL数据库

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

直接替换现有MySQL目录即可

2、mysqldump备份与恢复

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

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

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

三、MySQL完全备份与恢复

1.物理冷备份与恢复

systemctl stop mysqld

yum -y install xz

#压缩备份

cd /usr/local/mysql/data

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

systemctl start mysqld

模拟故障。删除数据库

drop database kgc;

#解压恢复

tar jxvf /opt/mysql_all_2020-11-22.tar.xz -C /usr/local/mysql/data

模拟故障，删除库kgc

恢复故障

2、mysqldump 完全备份与恢复（温备份）

备份

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

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

#导出的就是数据库脚本文件

例:

mysqldump -u root -p --databases ky17 > /opt/ky17.sql       #备份一个ky17库

mysqldump -u root -p --databases mysql kgc > /opt/mysql-kgc.sql    #备份mysql与 kgc两个库

(2)、完全备份 MySQL 服务器中所有的库

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

例:

mysqldump -u root -p --all-databases > /opt/all.sql

(3)、完全备份指定库中的部分表

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

例:

mysqldump -u root -p [-d] kgc info1 info2 > /opt/kgc_info1.sql

#使用“-d”选项，说明只保存数据库的表结构

#不使用“-d"选项，说明表数据也进行备份

#做为一个表结构模板

备份kgc库

备份kgc库中的BOOS表

备份kgc库中ky17表的数据结构

(4)查看备份文件

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

恢复数据库

1.使用mysqldump导出的文件，可使用导入的方法

source命令  进入数据库

mysql> source  /opt/kgc.sql ------>备份文件路径

登录到MySQL数据库，执行source备份sql脚本的路径

mysql命令

[root@localhost mysql]# mysql -uroot -p123456 < /opt/kgc.sql

不用进入数据库

示例

恢复库（根据前期已备份的kgc库进行）

方法一：source恢复

方式二：mysql恢复

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

方法一：source恢复

先删除BOSS表

方法二：mysql恢复

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

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

① 当备份时加 --databases ,表示针对于ky11库

#备份命令

mysqldump -uroot -p123123 --databases school > /opt/school_01.sql 备份库后

#恢复命令过程为：

mysql -uroot -p123123

drop database ky11;

exit

mysql -uroot -p123123 < /opt/ky11_01.sql

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

#备份命令

mysqldump -uroot -p123123 ky11 > /opt/ky11_all.sql

#恢复过程：

mysql -uroot -p123123

drop database ky11;

create database ky11;

exit

mysql -uroot -p123123 ky11 < /opt/ky11_02.sql

#查看ky11_01.sql 和ky11_02.sql

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

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

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

四、MySQL 增量备份与恢复

1.恢复的方式

一般恢复

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

基于位置恢复

数据库在某一时间点可能既有错误的操作也有正确的操作

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

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

基于时间点恢复

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

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

2，增量备份实验

开启二进制日志功能

vim /etc/my.cnf

[mysqld]

log-bin=mysql-bin

binlog_format = MIXED

#可选，指定二进制日志(binlog)的记录格式为MIXED（混合输入）

server-id = 1

#可加可不加该命令

#二进制日志(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方式存储。

systemctl restart mysqld

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

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语句

进行完全备份(增量备份时基于完全备份的，所以我们直接完全备份数据库)

使用mysqldump

可每天进行增量备份操作，生成新的二进制日志文件(例如:mysql-bin.000006)

mysqladmin -u root -p flush-logs

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

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

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

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

再次生成新的二进制日志文件(例如:mysql-bin.000007)

mysqladmin -u root -p flush-logs

#之前的步骤创建kgck库中的sss表和创建NJ库以及库中的ZB表的操作会保存到mysql-bin.000006文件中，

3. 增量恢复实验

全部恢复

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

先恢复完全备份

基于mysql-bin.000006恢复增量，恢复所有

mysqlbinlog --no-defaults / usr/local/mysql/data/mysql-bin.000006 | mysql -uroot -p123456

断点恢复

查看日志

mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000006

基于位置点恢复

#仅恢复到操作 ID 为“623"之前的数据，即不恢复"user4"的数据

mysqlbinlog --no-defaults --stop-position='1793' /opt/mysql-bin.000002 | mysql -uroot -p密码

#仅恢复"user4"的数据，跳过"user3"的数据恢复

mysqlbinlog --no-defaults --start-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为止

基于时间点恢复

mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时:分钟:秒' --stop-datetime='年-月-日小时:分钟:秒' 二进制日志 | mysql -u 用户名 -p 密码

#仅恢复到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

实验

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

基于节点

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

基于时间节点

恢复到SSS表的数据，不恢复NJ库的创建

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。