MySQL day6 备份恢复

按照这个顺序去读取
在这里插入图片描述

一、备份工具

设计备份、容灾策略

  • 备份策略:备份工具选择、备份周期设计、备份监控方法

5.1 mysqldump (MDP)

优点:
1.不需要下载安装
2.备份出来的是SQL,文本格式,可读性高,便于备份处理
3.压缩比较高,节省备份的磁盘空间

缺点:
4.依赖于数据库引擎,需要从磁盘把数据读出
然后转换成SQL进行转储,比较耗费资源,数据量大的话效率较低
建议:
100G以内的数据量级,可以使用mysqldump
超过TB以上,我们也可能选择的是mysqldump,配合分布式的系统
1EB  =1024 PB =1000000 TB

5.2 xtrabackup(XBK)

优点:
1.类似于直接cp数据文件,不需要管逻辑结构,相对来说性能较高
缺点:
2.可读性差
3.压缩比低,需要更多磁盘空间
建议:
>100G<TB

5.3 备份策略

备份方式:
全备:全库备份,备份所有数据
增量:备份变化的数据
逻辑备份=mysqldump+mysqlbinlog
物理备份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog
备份周期:
根据数据量设计备份周期
比如:周日全备,周1-6增量

二、mysqldump

mysqldump (逻辑备份的客户端工具)
mysqldump --help

逻辑备份工具。备份的是SQL语句

InnoDB可以采取快照备份的方式。
备份方式:开启一个独立的事务,获取当前最新的一致性快照
将快照数据,放在临时表中,转换成SQL(Create database,Create table,insert),保存到sql文件中。

非InnoDB表
需要锁表备份、触发FTWRL,全局锁表。转换成SQL(Create database,Create table,insert),保存到sql文件中。

2.1 客户端通用参数

连接参数:
-u  -p   -S   -h  -P    
本地备份:
mysqldump -uroot -p  -S /tmp/mysql.sock      这个 -S 不写就默认在tmp位置
远程备份:
mysqldump -uroot -p  -h 10.0.0.51 -P3306

2.2 备份专用基本参数
-A 全备参数,整个备份

例子1:
[root@db01 ~]# mkdir -p /data/backup
mysqldump -uroot -p -A >/data/backup/full.sql
Enter password: 

mysqldump: [Warning] Using a password on the command line interface can be insecure.
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events. 

# 补充:
# 1.常规备份是要加 --set-gtid-purged=OFF,解决备份时的警告
# [[email protected] ~]# mysqldump -uroot -p123 -A  --set-gtid-purged=OFF  >/backup/full.sql
# 2.构建主从时,做的备份,不需要加这个参数
# [[email protected] ~]# mysqldump -uroot -p123 -A    --set-gtid-purged=ON >/backup/full.sql

-B db1 db2 db3 备份多个单库

说明:生产中需要备份,生产相关的库和MySQL库
例子2 :
mysqldump -B mysql gtid --set-gtid-purged=OFF >/data/backup/b.sql 

不加参数,备份单个或多个表

例子3 world数据库下的city,country表
mysqldump -uroot -p world city country >/backup/bak1.sql
以上备份恢复时:必须库事先存在,并且ues才能source恢复

在这里插入图片描述

三、高级参数

每周日 23:00全备,周1-6 binlog备份。所有备份是完整的。
周三时,有一个核心运维人员进行了删库操作。
思路:恢复全备 + 所有需要binlog恢复
痛点:binlog的截取
起点:起点查找比较困难
方法一:备份开始时,切割日志。 -F
方法二:备份开始时,自动记录日志文件信息 --master-data=2
终点:drop之前的位置点

–master-data=2

以注释的形式,保存备份开始时间点的binlog的状态信息

mysqldump -uroot -p  -A  -R --triggers --master-data=2   >/back/world.sql
[root@db01 ~]# grep 'CHANGE' /backup/world.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=194;

功能:
(1)在备份时,会自动记录,二进制日志文件名和位置号
0  默认值
1  以change master to命令形式,可以用作主从复制
2  以注释的形式记录,备份时刻的文件名+postion号
(2)自动锁表
(3)如果配合--single-transaction,只对非InnoDB表进行锁表备份,InnoDB表进行“热“”备,实际上是实现快照备份。

–single-transaction

对于innodb 存储引擎开启热备(快照备份)功能  ———— 开启一个独立事务,获取一致性快照,进行备份     
master-data可以自动加锁
(1)在不加--single-transaction ,启动所有表的温备份,所有表都锁定1)加上--single-transaction ,对innodb进行快照备份,对非innodb表可以实现自动锁表功能

❤例子6: 备份必加参数
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

–set-gtid-purged=auto

auto , on
off 
使用场景:
1. --set-gtid-purged=OFF,可以使用在日常备份参数中.
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. auto , on:在构建主从复制环境时需要的参数配置
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

–max-allowed-packet=#

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF --max-allowed-packet=256M >/data/backup/full.sql

 --max-allowed-packet=# 
The maximum packet length to send to or receive from server.

在这里插入图片描述数据包大小默认是4M。超过4M就会拒绝。因此要利用参数 --max-allowed-packet=#

补充(了解):

-R            备份存储过程及函数
--triggers    备份触发器
-E            备份事件

例子4:
[root@db01 backup]# mysqldump -uroot -p -A -R -E --triggers >/data/backup/full.sql
(5) 特殊参数2使用

-F 在备份开始时,刷新一个新binlog日志

例子5:
mysqldump -uroot -p  -A  -R --triggers -F >/bak/full.sql

 

mysqldump + binlog 故障恢复案例

案例场景:

  • 基础环境:Centos 7.6 + MySQL 5.7.28,LNMT 网站业务,数据量100G,每天5-10M数据增长。
  • 备份策略:mysqldump 每天全备,binlog定时备份。
  • 故障说明:周三上午10点数据故障,例如:核心业务库被误删除

恢复思路:

  • 1.挂维护页。
  • 2.找测试库。
  • 3.恢复周二全备。
  • 4.截取周二全备——》周三上午10点误删除之前的binlog,并恢复
  • 5.测试业务功能正常
  • 6.恢复业务:
    方案1:故障库导回到原生产
    方案2:直接用测试库称当生产,先跑着。

模拟数据损坏及恢复:
1.模拟原始数据

create database mdp charset utf8mb4;
use mdp;
create table t1(id int);
begin;
insert into t1 values(1),(2),(3);
commit;

在这里插入图片描述
2.模拟周二晚上全备

mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /data/back/full_`date +%F`.sql

在这里插入图片描述
出现错误Binlogging on server not active

vim /etc/my.cnf 
去掉mysqld下的log_bin前面的注释 并且改成
log_bin=mysql-bin

3.模拟周三白天的数据变化

use mdp;
create table t2(id int);
insert into t2 values(1),(2),(3);
commit;

4.搞破坏

drop database mdp;

5.开始恢复

5.1 检查全备
在备份好的sql文件找到这句话
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

5.2 恢复全备
在5.7之后,默认备份的sql文件就已经包含sql_log_bin=0,这里只是为了严谨

mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

mysql> source /data/back/full_2020-06-03.sql

5.3 截取binlog
起点:grep “-- CHANGE MASTER TO” /data/back/full_2020-06-03.sql

– CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000001’, MASTER_LOG_POS=154;

在这里插入图片描述终点:
show master status;
show binlog events in ‘musql-bin.000001’;
在这里插入图片描述
position截取

mysqlbinlog --skip-gtids --start-position=648 --stop-position=729 /data/binlog/mysql-bin.000001 > /tmp/binlog.sql

GTID截取:
在这里插入图片描述

5.4 恢复binlog

mysql> set sql_log_bin=0;
mysql> source /tmp/binlog.sql
mysql> set sql_log_bin=1;

mysqldump小结:

参数:-u -p -S -h -p
     -A -B --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64
选择场景: 数据流较少

 

四、小练习

1.实现所有表的单独备份

提示:
information_schema.tables
mysqldump -uroot -p123 world city >/backup/world_city.sql

select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," --master-data=2 --single-transaction --set-gtid-purged=0  -R -E --triggers>/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema');

2.模拟故障案例并恢复

1)每天全备
(2)binlog日志是完整
(3)模拟白天的数据变化
(4)模拟下午两点误删除数据库

需求: 利用全备+binlog回复数据库误删除之前。
故障模拟及恢复:
1. 模拟周一23:00的全备
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. 模拟白天的数据变化
Master [(none)]>create database day1 charset utf8;
Master [(none)]>use day1
Master [day1]>create table t1(id int);
Master [day1]>insert into t1 values(1),(2),(3);
Master [day1]>commit;
Master [world]>update city set countrycode='CHN';
Master [world]>commit;
模拟磁盘损坏:
[root@db01 data]# \rm -rf /data/mysql/data/*
3. 恢复故障
[root@db01 data]# pkill mysqld
[root@db01 data]# \rm -rf /data/mysql/data/*

4. 恢复思路
1.检查备份可用性
2.从备份中获取二进制日志位置
3.根据日志位置截取需要的二进制日志
4.初始化数据库,并启动
5.恢复全备
6.恢复二进制日志

3.压缩备份并添加时间戳

例子:
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F-%T).sql.gz

mysqldump备份的恢复方式(在生产中恢复要谨慎,恢复会删除重复的表)
set sql_log_bin=0;
source /backup/full_2018-06-28.sql

注意:
1、mysqldump在备份和恢复时都需要mysql实例启动为前提。
2、一般数据量级100G以内,大约15-45分钟可以恢复,数据量级很大很大的时候(PB、EB)
3、mysqldump是覆盖形式恢复的方法。

一般我们认为,在同数据量级,物理备份要比逻辑备份速度快.
逻辑备份的优势:
1、可读性强
2、压缩比很高

4.从mysqldump 全备中获取库和表的备份

1、获得表结构
# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q'  full.sql>createtable.sql

2、获得INSERT INTO 语句,用于数据的恢复
# grep -i 'INSERT INTO `city`'  full.sqll >data.sql &

3.获取单库的备份
# sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

五、MySQL物理备份工具-xtrabackup(XBK、Xbackup)

安装依赖包

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev

下载软件并安装

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm

https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

备份方式——物理备份

1)对于非Innodb表(比如 myisam)是,锁表cp数据文件,属于一种温备份。
(2)对于Innodb的表(支持事务的),不锁表,拷贝数据页,最终以数据文件的方式保存下来,把一部分redo和undo一并备走,属于热备方式。

面试题: xbk 在innodb表备份恢复的流程

  0、xbk备份执行的瞬间,立即触发ckpt,已提交的数据脏页,从内存刷写到磁盘,并记录此时的LSN号
  1、备份时,拷贝磁盘数据页,并且记录备份过程中产生的redo和undo一起拷贝走,也就是checkpoint LSN之后的日志
  2、在恢复之前,模拟Innodb“自动故障恢复”的过程,将redo(前滚)与undo(回滚)进行应用
  3、恢复过程是cp 备份到原来数据目录下

猜你喜欢

转载自blog.csdn.net/qq_39578545/article/details/106528960