MySQL备份和恢复（参数讲解）

目录

• 备份恢复
• 物理备份-XBK
  • innobackuppex使用

# innodb核心参数
innodb_flush_log_at_trx_commit=1
innodb_flush_method=o_direct

innodb_flush_log_at_trx_commit=0
innodb_flush_method=fsync

备份恢复

1.在备份恢复中的职责
1.1 备份策略的设计
（1）备份周期：根据数据量
（2）备份工具：mysqldump(MDP)  XBK(PBK) percona Xtrabackup, MEB(MySQL Enterprise BACKUP MEB),mysqlbinlog
（3）备份的方式:
逻辑：
全备：mysqldump
增量：binlig(flush logs,cp)
物理备份：XBK
全备：XBK
增量：XBK
1.2 检查备份可用性
crontab -l --->
备份路径 --->
看备份路径 --->
看备份日志，检查备份文件（大小，内容）

1.3 定期的恢复演练
1.4 数据恢复
	只要备份和日志是完整的，恢复到故障之前的时间点（快速）
1.5 数据迁移
	操作系统不同的迁移
	mysql -> mysql （升级迁移）
	其他  ->  mysql（异构平台迁移）
	mysql ->  其他
	
2. 备份的介绍
2.1 备份类型
	热备：在数据库正常业务时，备份数据，并且能够一致性恢复（只能是innodb） 对业务影响非常小 使用 Innodb
	温备：锁表备份，只能查询不能修改（myisam）影响到写入操作  使用Mysaim
	冷备：关闭数据库业务，数据库没有任何变更的情况下，进行备份数据 业务停止
2.2 备份方式及工具介绍

3.mysqldump
3.1 连接数据库
-u 
-p
-s
-h
p
3.2 基础备份参数
-A  全备  # --all-databases
	mysqldump -uroot -p123 -A >/backup/full.sql  # 全备 备份逻辑是将数据库的数据从磁盘上拿出来，然后将数据转换为sql语句，写入到文件
-B  # 导出几个数据库。参数后面所有名字参量都被看作数据库名。
	mysqldump -uroot -p123 -B world oldguo wordpress >/backup/db.sql
库、表 # 对单张库的表进行备份
	mysqldump -uroot -p123 world city >/backup/tab.sql
	
3.3 特殊备份参数
-R # 导出存储过程以及自定义函数 --routines
-E # 导出事件
--triggers  # 导出触发器。该选项默认启用，用--skip-triggers禁用它。
--master-data=2  # (1) 记录备份时刻的binlog信息（2）自动锁表 ：1.不加 --single-transaction，温备份 2.加了--single-transaction,对于InnoDB表不锁表备份（快照备份）
	每天全备 mysqldump 60G
	周三，下午2点，数据库损坏
	恢复思路？
		1.恢复周二全备
		2.截取全备到损坏之前的binlog
--single-transaction
对于InnoDB的表，进行一致性快照备份，不锁表

4. 恢复案例
	4.1背景环境：
	正在运行的网站系统，mysql-5.7.20数据库，数据量50G，日业务增量1-5M。
	4.2 备份策略：
	每天23：00点，计划任务调用mysqldump执行全备脚本
	4.3 故障时间点：
	年底故障演练：模拟周三上午10点误删除数据库。
	4.4 思路：
	1.停业务，挂维护页，避免数据的二次伤害
	2.找一个临时库，恢复周二23：00全备
	3.截取周二23：00----周三10点误删除之间的binlog，恢复到临时库
	4. 测试可用性和完整性
5.
    5.1 方法一：直接使用临时库顶替原生产库，前端应用割接到新库
    5.2 方法二：将误删除的表导出，导入到原生产库
6. 开启业务
    处理结果：经过20分钟的处理，最终业务恢复正常

4.5 故障模拟演练
	4.5.1 准备数据
	create database backup;
	use backup
	create table t1 (id int);
	insert into t1 values(1),(2),(3);
	commit;
	rm -rf /backup/*
	4.5.2 周二 23：00全备
	
	mysqldump -uroot -p123 -A -R --triggers --set-gtid-purged=OFF --master-data=2 --single-transation|gzip > /backup/full $(date +%F).sql.gz
	4.5.3 模拟周二 23：00到周三 10点之间数据变化
	use back up
	insert into t1 values(11),(22),(33);
	commit;
	create table t2 (id int);
	insert into t2 values(11),(22),(33);

4.5.4 模拟故障，删除表（只是模拟，不代表生产操作）
drop database backup;
4.6 恢复过程
4.6.1 准备临时数据库（多实例3307）
systemctl start mysqld3307
4.6.2 准备备份
	(1)准备全备：
		cd /backup
		gunzip full_2021_03_27.sql.gz
	(2)截取二进制日志
	-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000036',MAStER_LOG_POS=793;
	mysqlbinlog --skip-gtids --start-position=753 --stop-position=1519 mysql-bin.000002 > /backup/bin.sql
	mysqlbinlog --skip-gtids --include-gtids='3ca79ab5-3e4d-11e9-a709-00c293b577e:6-7'
	/data/binlog/mysql-bin.000036 > /backup/bin.sql
4.6.3 恢复备份到临时库
	mysql -S /data/3307/mysql.sock
	set sql_log_bin=0;
	source /backup/full_2021-03-27/mysql.sql
	source /backup/bin.sql
4.6.4 将故障表导出并恢复到生产
	mysqldump -S /data/3307/mysql.sock -B backup > /backup/t1.sql
	mysql -uroot -p123
	set sql_log_bin=0
	source /backup/bak.sql;
	

练习：

1.创建一个数据库database1 # 确保binlog日志处于开启状态

2. 在database1下创建一张表t1

3.插入5行任意数据
insert into t1 values(1),(2),(3),(4),(5) 
commit;
4.全备
mysqldump -uroot -p123 --master-data=2 --single-transaction -R -E --triggers > /backup/full.sql
5.插入两行数据，任意修改3行数据，
insert into t1 values(6),(7),(8)
commit;
update t1 set id=10 where id>5
6.删除所有数据
delete from t1 where id=5;
commit;

delete from t1
commit;

insert into t1 values(1),(2),(3),(4),(5) 
commit;
update t1 set id=10 where id>2
commit;
7.再t1中又插入5行新数据，修改3行数据

需求，跳过第六步恢复表数据 # 1~5步全备，加上第7步的截取
	'''
	SET @@GLOBAL.GTID_PURGED='aa648280-a6a6-11e9-949f-000c294a1b3b:1-11'
	-- CHANGE MASTER TO MASTER_LOG_FILE='MYSQL-BIN.000002',MASTER_LOG_POS=2396;
	'''
	mysqlbinlog --skip-gtids --include-gtid='aa648280-a6a6-11e9-949f-000c294a1b3b:12-17' --exclude-gtids='aa648280-a6a6-11e9-949f-000c294a1b3b:15' /data/binlog/mysql-bin.000002 > /backup/bin.sql
	
	set sql_log_bin=0;
	source /backup/full.sql
	source /backup/bin.sql
	use database1;
	select * from t1

'''
扩展参数
-set-gtid-purged=AUTO/ON  # 在构建主从时，使用AUTO/ON
-set-gtid-purged=OFF # 仅是做普通的本机备份恢复时，可以添加；这样在全备份的文件中就不会记录这一行
SET @@GLOBAL.GTID_PURGED='aa648280-a6a6-11e9-949f-000c294a1b3b:1-11'

--max_allowed_packet=128M  控制的是备份时传输数据包的大小
mysqldump -uroot -p123 -A -B --max_allowed_packet=128M --triggers --set-gtid-purged=OFF --master-data=2 --single-transaction|gzip > /back/full_$(date +%F).sql.gz
'''

物理备份-XBK

安装依赖包：
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.e17.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.e16.x86_64.rpm

yum -y install percona-xtrackup-24-2.4.4-1.e17.x86_64.rpm

innobackuppex使用

# 备份核心理念
1. 针对非InnoDB，进行锁表备份，copy所有的非innoDB表文件
2. 针对InnoDB表，立即出发CKPT，copy所有InnoDB表相关的文件（ibdata1,ibd,frm）。并且将备份过程中产生新的数据变化的部分redo一起备份走
3.在恢复时，xbk会调用InnoDB引擎的CSR过程，将数据和redo的LSN追平，然乎偶进行一致性恢复。