MySQL日治管理、数据库备份与恢复
备份的主要目的是灾难恢复，备份还可以测试应用、回滚数据修改、查询历史数据、审计等。而备份、恢复中，日志起到了很重要的作用
一、日志
MySQL的日志默认保存位置为 /usr/local/mysql/data
1.日志类型与作用
①redo重做日志：达到事务一致性（每次重启会重做）
作用：确保日志的持久性，防止发生故障，脏页为写入磁盘。重启数据库会进行redo log执行重做，达到事务 一致性。
②undo回滚日志
作用：保证数据的原子性，记录事务发生之前的一个版本，用于回滚，innodb事务可重复读和读取已提交隔离级别就是通过mvcc+undo实现
③.error log错误日志
作用：MySQL本身启动，停止，运行期间发生的错误信息
④.slow query log 慢查询日志
作用：记录执行时间过长的sql，时间阈值（10s）可以配置，只记录执行成功
另一个作用：相当于提醒你是否优化此项
⑤.bin log二进制日志
作用：用于主从复制，实现主从同步；主从复制是另外两种核心架构的基础：读写分离和MHA高可用记录的内容是数据库中执行的sql语句
⑥.relay log中继日志
作用：一般情况下它在Mysql主从同步（复制）、读写分离集群的从节点开启。主节点一般不需要这个日志，将主库发来的bin/log保存在本地，然后从库进行回放
⑦.general log普通日志
作用：记录数据库的操作明细，默认关闭，开启后会降低数据库性能
2.MySQL-日志配置文件
[mysqld]
##错误日志，用来记录当MySQL启动、 停止或运行时发生的错误信息，默认已开启
log-error=/usr/local/mysql/data/mysql_error.log #指定错误日志的保存位置和文件名
general_log=ON ##通用查询日志，用来记录MySQL的所有连接和语句，默认是关闭的
general_log_file=/usr/local/mysql/data/mysql_general.log
##二进制日志(binlog)，用来记录所有更新了数据或者已经潜在更新了数据的语句，记录了数据的更改，可用于数据恢复，默认已开启
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秒
3.查询日志
xx% 以xx为开头的字段
%xx 以xx为结尾的字段
%xx% 只要出现xx字段的都会显示出来
xx 精准查询
variables 表示变量
like 表示模糊查询
查看通用日志是否开启
show variables like ‘general%’;
查看二进制日志是否开启
show variables like ‘log_bin%’;
查看慢查询日志功能是否开启
show variables like '%slow%';
开启慢查询日志功能
set global slow_query_log=on;
查看慢查询时间设置；默认10s
show variables like 'long_query_time';
刷新二进制日志有助于进行增量备份
mysql-bin.index #二进制日志文件的索引
重启mysql的时候会更新索引文件，用于记录新的更新语句
二、MySQL备份
1.物理备份
物理备份是对数据库操作系统的物理文件（如数据文件、日志文件等）的备份。这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据库。
物理备份又可以成为冷备份（脱机备份）、热备份（连接备份）和温备份
冷备份（脱机备份）：关闭数据库的时候进行（tar）
热备份（联机备份）：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopy mysqlbackup）
温备份：数据库锁定表格（不可写入但可读）的状态下进行备份操作（mysqldump）
2.逻辑备份
逻辑备份是对数据库逻辑组件的备份.表示为逻辑数据库结构
这种类型的备份适用于可以编辑数据值或表结构
从数据库的备份策略角度来看，备份又可分为完全备份、差异备份和增量备份
①完全备份
每次对数据进行完整备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完成时刻的数据库，是差异备份与增量备份的基础完全备份的备份与恢复操作都非常简单方便，但是数据存在大量的重复并且会占用大量的磁盘空间，备份的时间也很长
每次都进行完全备份，会导致备份文件占用空间巨大，并且有大量的重复数据，恢复时，直接使用完全备份的文件即可
②差异备份
备份那些自从上次完全备份之后被修改过的所有文件，备份的时间节点是从上次完整备份起，备份数据量会越来越大。恢复数据时只需要恢复上次的完全备份与最佳的一次差异备份
每次差异备份，都会备份上一次完全备份之后的数据，可能会出现重复数据。恢复时，先恢复完全备份的数据，再恢复差异备份的数据
③增量备份
只有那些在上次完全备份或者增量备份后被修改的文件才会被备份以上次完整备份或上次增量备份的时间为时间点，仅备份期间内的数据变化，因而备份的数据量小，占用空间小，备份速度快。但恢复时，需要从上一次的完整备份开始到最后一次增量备份之间的所有增量依次恢复，如中间某次的备份数据损坏，将导致数据的丢失
每次增量备份都是在备份在上一次完成全备份
每次增量备份都是备份在上一次完全备份或者增量备份之后的数据，不会出现重复数据的情况，也不会占用额外的磁盘空间
恢复数据，需要按照次序恢复完全备份和增量备份的数据
④备份方式比较
备份方式 完全备份 差异备份 增量备份
完全备份时的状态 表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.常见的备份方法
①物理冷备
备份时数据库处于关闭状态，直接打包数据库文件（tar）
备份速度快，恢复时也是最简单的
物理冷备关闭数据库的原因：因为数据库是由持续性的数据交互和数据频繁更新的特性，若是不关闭数据库，tar就无法保证数据的更新与一致性。
②专用备份工具mysqldump或mysqlhotcopy
mysqldump 常用的逻辑备份工具
mysqlhotcopy 仅拥有备份MyISAM和ARCHIVE表（Myisam、ARCHIVE指的时引擎表）
③启用二进制日志进行增量备份
进行增量备份，需要刷新二进制日志
MySQL支持增量备份，进行增量备份时必须启用二进制日志。二进制日志文件为用户提供复制，对执行备份点后进行的数据库更改所需的信息进行恢复。如果进行增量备份（包含自上次完全备份或增量备份以来发生的数据修改），需要刷新二进制日志。
④第三方工具备份
免费的MySQL 热备份软件 Percona XtraBackup mysqlbackup
三、MySQL备份与恢复
1.完全备份
是对整个数据库、数据库结构和文件结构的备份
保存的是备份完成时刻的数据库
是差异备份与增量备份的基础
①优点
备份与恢复操作简单方便
②缺点
数据存在大量的重复
占用大量的备份空间
备份与恢复时间长
2.数据库完全备份分类
①物理冷备份与恢复
关闭MySQL数据库
使用tar命令直接打包数据库文件夹
直接替换现有MySQL目录即可
②mysqldump备份与恢复
MySQL自带的备份工具，可方便实现对MySQL的备份
可以将指定的库、表导出为SQL 脚本
使用命令mysq|导入备份的数据
四、完全备份操作
1.准备
create database zbc;
use zbc;
create table y1(id int(4) not null,name varchar(10) not null,age char(10) not null,address varchar(50) default ‘’,primary key(id));
insert into y1 values(1,’zhangsan’,1,’abc123’);
insert into y1 values(2,’lisi’,2,’def456’);
insert into y1 values(3,’wangwu’,’ghi789’);
2.备份
systemctl stop mysqld #关闭数据库
tar Jcvf /opt/mysql_all_$(date +%F).tar.gz /usr/local/mysql/data #数据备份打包；date +%F：当前时间
cd /opt
ll
mv /usr/local/mysql/data/ /opt/ #移走data，模拟数据库损坏
systemctl start mysqld #开启数据库
mysql -u root -p #数据库损坏，进入不了数据库
tar Jxvf /opt/mysql_all_2021-10-26.tar.gz /usr/local/mysql/data/
3. mysqldump 备份与恢复（温备份）
mysql -u root -p123456 -e 'show databases;'
①完全备份一个或多个完整的库（包括其中所有的表）
mysqldump -u root -p123456 --databases zbc > /opt/zbc.sql
mysqldump -u root -p123456 --databases zbc mysql> /opt/zbc-mysql.sql
②完全备份MySQL服务器中所有的库
mysqldump -u root -p123456 --all-databases > /opt/all.sql
③完全备份指定库中的部分表
mysqldump -uroot -p123456 [-d] zbc y1 > /opt/zbc_y1.sql
#使用“-d”选项，说明只保存数据库的表结构
#不使用“-d"选项，说明表数据也进行备份
#做为一个表结构模板
这里也不难看出，热备份不需要关闭数据库是因为可以锁表，写完数据会解锁
④查看备份文件
grep -v "^--" /opt/zbc_y1.sql | grep -v "^/" | grep -v "^$"
4.MySQL完全备份恢复
①使用source命令恢复数据
登录数据库，删除数据库
source /opt/zbc.sql;
②使用mysql命令恢复
mysql -uroot -p123456 -e ‘drop table zbc.y1;’
mysql -uroot -p123456 -e 'show tables from zbc;'
进入zbc库
source /opt/zbc_y1.sql
mysql -uroot -p123456 zbc < /opt/zbc_y1.sql
5.mysql、mysqldump
mysqldump 严格来说属于温备份，会需要对表进行写入的锁定
在全量备份与恢复实验中，假设现有zbc库，zbc库中有一个test表，需要注意的一点为：
① 当备份时加 --databases ,表示针对于ky11库
#备份命令
mysqldump -uroot -p123456 --databases zbc > /opt/zbc_y1.sql 备份库后
#恢复命令过程为：
mysql -uroot -p123456
drop database zbc;
exit
mysql -uroot -p123456 < /opt/zbc_y1.sql
② 当备份时不加 --databases，表示针对zbc库下的所有表
#备份命令
mysqldump -uroot -p123456 zbc > /opt/zbc_all.sql
#恢复过程：
mysql -uroot -p123456
drop database zbc;
create database zbc;
exit
mysql -uroot -p123456 zbc < /opt/zbc_y2.sql
#查看zbc_y1.sql 和zbc_y2.sql
主要原因在于两种方式的备份（前者会从"create databases"开始,而后者则全是针对表格进行操作）
6.使用脚本定时备份
在生产环境中，可以使用Shell脚本自动实现定时备份（时间频率需要确认）
0 1* * 6 /usr/local/mysql/bin/ mysqldump -uroot -pabc123 zbc info1 > ./kgc_infol_$(date +%Y%m%d).sql ;/usr/local/mysql/bin/mysqladmin -u root -p flush-logs
五、MySQL增量备份与恢复
1.一般恢复
将所有备份的二进制日志内容全部恢复
2. 基于位置恢复
数据库在某一时间点可能既有错误的操作也有正确的操作
可以基于精准的位置跳过错误的操作
发生错误节点之前的一个节点，上一次正确操作的位置点停止
3. 基于时间点恢复
跳过某个发生错误的时间点实现数据恢复
在错误时间点停止，在下一个正确时间点开始
六、MySQL增备操作
1.开启二进制日志功能
vim /etc/my.cnf #开启二进制日志功能
log-bin=mysql-bin #开启二进制
binlog_format=MIXED #指定二进制日志记录格式：混合输入
server-id = 1 #标识该语句最初从哪个server写入的
systemctl restart mysqld #重启Mysql
2.二进制三种记录格式/模式(默认STATEMENT)
①STATEMENT（基于SQL语句）:
每一条涉及到被修改的sql 都会记录在binlog中
缺点：日志量过大，如sleep()函数，last_insert_id()>，以及user-defined fuctions（udf）、主从复制等架构记录日志时会出现问题
增删改查通过sql语句来实现记录，如果用高并发可能会出错，可能时间差异或者延迟，可能不是我们想想的恢复可能你先删除或者在修改，可能会倒过来。准确率底
②ROW(基于行)
只记录变动的记录，不记录sql的上下文环境
缺点:如果遇到update......set....where true 那么binlog的数据量会越来越大
date、delete以多行数据起作用，来用行记录下来，只记录变动的记录，不记录sql的上下文环境
比如sql语句记录一行，但是ROW就可能记录10行，但是准确性高，高并发的时候由于操作量，性能变低 比较大所以记录都记下来。
③MIXED 推荐使用
一般的语句使用statement，函数使用ROW方式存储。
3.查看二进制文件内容
cp /usr/local/mysql/data/mysql-bin.000001 /opt/
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000001
# mysqlbinlog：基于日志管理操作的命令
#--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.txt
4.二进制日日志内容
①at：开始的位置点
②end_log_pos：结束的位置
③时间戳：210712 11:50:30
④SQL语句：insert、select等
5.进行完全备份
增量备份时基于完全备份的，所以我们直接完全备份数据库
mysqldump -uroot -p123456 zbc y1 > /opt/zbc_y1_$(date +%F).sql
mysqldump -uroot -p123456 zbc > /opt/zbc_all_$(date +%F).sql
6. 可每天进行增量备份操作，生成新的二进制日志文件(例如:mysql-bin.000002)
mysqladmin -u root -p flush-logs
增量备份：基于上一次完全或者增量备份的备份
保留之前的完整操作00001去作为完全备份的操作即00002
4.插入新数据，以模拟数据的增加或变更
在第一次完全备份之后刷新二进制文件，在第二个二进制文件中记载着"增量备份的数据"
create table y2(id int(4),name varchar(4));
insert into y2 values(1,'fir');
insert into y2 values(2,'sec');
5. 再次生成新的二进制日志文件(例如:mysql-bin.000003)
mysqladmin -u root -p flush-logs
#之前的步骤中的数据库操作会保存到mysql-bin.000002文件中，之后我们测试删除zbc库的操作会保存在mysql-bin.000003文件中 （以免当我们基于mysql-bin.000002日志进行恢复时，依然会删除库）
6.增量回复
①一般回复
模拟丢失更改的数据恢复步骤（直接使用恢复即可）
备份zbc库中y1表
mysqldump -uroot -p123456 zbc y1 > /opt/zbc_y1.sql
删除zbc库中y1表
drop table zbc.y1;
恢复zbc表
mysql -uroot -p zbc < y1-2021-10-26.sql
#查看日志文件
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002
②模拟丢失所有数据的恢复步骤
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
#操作一下备份000002； 为了方便文本查看
删除y2表
mysql -uroot -p123456 -e 'drop table zbc.y2;'
基于mysql-bin.000002恢复
mysqlbinlog –no-defaults /opt/mysql-bin.000002 | mysql -u root -p
③断点恢复
基于位置恢复
删除表
mysql -uroot -p123456 -e 'drop table zbc.y2;'
查看位置，操作到ID为475之前的数据，at 475
mysqlbinlog --no-defaults --start-position='577' /opt/mysql-bin.000002 | mysql -uroot -p123456
因为在添加数据之前，所以之有表并没有数据
mysqlbinlog --no-defaults --stop-position='577' /opt/mysql-bin.000002 | mysql -uroot -p123456
因为从577开始，577是第一条数据结束，所以只有第二条数据
④基于时间点恢复
基于错误的时间点停止，正确的时间点恢复数据
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时:分钟:秒' --stop-datetime='年-月-日小时:分钟:秒' 二进制日志 | mysql -u 用户名 -p 密码
删除数据表
mysql -uroot -p123456 -e 'drop table zbc.y2;'
仅恢复添加完第一条数据的时间之后的下一个时间，恢复第一条数据和表，恢复到211026 17：32：57
mysqlbinlog –no-defaults –stop-datetime=’2021-10-26 17:32:51’ /opt/mysql-bin.000002 | mysql -uroot -p123456
mysql -uroot -p123456 -e 'select * from zbc.y2;'
恢复第二条数据，只用恢复从第一条数据添加结束的时间开始，恢复到2021-10-26 17：32：57
mysqlbinlog --no-defaults --start-datetime='2021-10-26 17:32:57' /opt/mysql-bin.000002 | mysql -uroot -p123456
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时:分钟:秒' --stop-datetime='年-月-日小时:分钟:秒' 二进制日志 | mysql -u 用户名 -p 密码
本身就有y2表，只想恢复两条数据，就要在创建第一条数据的时间开始，第二条数据创建完成后的一个时间结束
mysqlbinlog --no-defaults --start-datetime=‘2021-10-26 17:32:51’--stop-datetime=’2021-10-26 17:35:47’ /opt.mysql-bin.000002
如果恢复某条SQL语之前的所有数据，就stop在这个语句的位置节点或者时间点
如果恢复某条SQL语句以及之后的所有数据，就从这个语句的位置节点或者时间点start
位置区间也是跟时间区间一样
1、 备份的分类
物理备份
冷备份 (脱机备份) ：是在关闭数据库的时候进行的（tar）
热备份 (联机备份)：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopy/mysqlbackup等第三方热备工具，缺点是会对引擎有所限制）
温备份 ：数据库锁定表格(不可写入但可读)的状态下进行备份操作（mysqldump）
逻辑备份
完全备份：每次对数据进行完整备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完成时的数据库
差异备份：备份的时间节点是从上次完整备份起，**备份数据量会越来越大
增量备份**：**仅记录基于原表内容变化的一条记录
2、 常见的备份方法
物理冷备：
关闭MySQL数据库
使用tar命令直接打包数据库文件夹
直接替换现有MySQL目录即可
专用备份工具 mysqldump 或 mysqlhotcopy
mysqldump 常用的逻辑备份工具
mysqlhotcopy 仅拥有备份 MyISAM 和 ARCHIVE 表（MyISAM、ARCHIVE指的是引擎表）
启用二进制日志进行增量备份
进行增量备份，需要刷新二进制日志
第三方工具备份
免费的MySQL 热备份软件 Percona、XtraBackup、mysqlbackup
3、恢复数据库
方式一：交互式–使用source命令
登录到MySQL数据库
执行source备份sql脚本的路径
方式二：无交互式–使用musql命令
无须登录MySQL数据库
使用-e删除数据表
执行mysql备份sql脚本的路径
410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
