day07-备份与恢复

备份与恢复

备份

作用；处理数据的损坏
类型：
	1> 物理损坏 ： 磁盘的损坏/核心数据的丢失/删除;
		## 主从/ 高可用
		
	2> 逻辑损坏 ： drop/delete/truncate/update  使用命令的将数据误删除的
		## 备份/binglog/binlog2/延迟从库
			## 所谓延迟从库：就是在主库在删除数据了之后，从库会指定在固定时间内不删除，如果是误删除，那么也可以在短时间内的恢复回来
			
职责：
	1.设计备份和恢复的策略
	2.备份要定期检查
	3.定期的恢复演练
	4.数据损坏的恢复（效率/一致性）
	5.迁移/升级，构建主从复制
	
工具：
	1.逻辑备份
		mysqldump(MDP)
		mysqlbinlog
		mydumper
	2.物理备份
		percona Xtrabackup(PXB / XBK / Xbackup)
	3.8.0之后的克隆（也算逻辑备份，8017之后才有）
		clone plugin
		
		

mysqldump 逻辑备份

	mysqldump:逻辑备份工具
	备份结果：
		SQL语句 create database/table   insert into（我只需要将这些做了备份，就可以了）
		
	备份逻辑：
		RR级别，获取一致性快照，为了就是保证数据的一致性
		1.元数据备份
			FTWRL  （##：如果我想在你查看表属性的，对这张表插入数据，肯定是不可以的，所以就需要加锁的操作。                
            	flush tables with read lock;手动加锁   
            	MDL锁： 是获取的，算是表上，对象上的属性。		
				## flush tables   --> close tables(关闭表)，并且阻止所有commit的操作
					例子：当我们备份大数据的时候，就会出现延迟，那么就会获取不到锁，获取不到，就没有办法对表进行操作，就不会备份成功。
				## read lock      --> all read lock（给所有的表加上读锁，允许读操作）
				## unlock tables;
			show create database      建库
			show create table         建表
				
		2.备份数据行
			select  --> 
        	INNODB 可以进行快照备份
            拼接成insert 
            非innodb表，锁表备份
  
4.1.3 适合的场景
单节点数据量,100G以内,单表2000w以内.可以使用MDP
恢复时间一般是备份时间的3-5倍.



4.2 参数应用 
4.2.1 连接参数
-u  
-p 
-h 
-P 
-S 

4.2.2 基础备份参数

-A  : 全库备份
[root@db01 ~]# mysqldump -uroot -p123 -S /tmp/mysql.sock -A >/tmp/full.sql

-B  : 单库或多库备份 
    [root@db01 ~]# mysqldump -uroot -p123 -S /tmp/mysql.sock -B oldboy test  >/tmp/db.sql


## 备份单表或多表 
[root@db01 ~]# mysqldump -uroot -p123 -S /tmp/mysql.sock  test t100w   >/tmp/t100.sql
[root@db01 ~]# mysqldump -uroot -p123 -S /tmp/mysql.sock  test t100w t1   >/tmp/t100.sql
说明: 以上方法,在恢复时先建立数据库,use到库中,再source


4.2.3 特殊备份参数
a. --master-data=2 
	1. 自动记录binlog信息
	2. 自动进行GRL锁(FTWRL),加了 --single-transaction 会有不一样的效果.

mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 >/tmp/full.sql


b. --single-transaction 
解: 
	1. 对于InnoDB表进行一致性快照备份
	2. 备份期间如果有DDL会备份失败.


## 举例子：
	我想要数一下班级的同学准确数字。
		1.锁门：我将大门锁上，所有人不能进出，然后统计之后，在解锁。
		2.快照：就是我用照相机，先给全班同学拍照，但是这个时候，其中有一个同学不是我们班的，那么就相当于，改变了我们班级的人数。也就相当于改变了表的结构。
		
c. --max_allowed_packet=128M
	## 这里在添加的时候，是需要区分客户端还是服务端。
		如果你是想要备份，那么就是从服务端，向客户端推送数据，就需要添加在客户端
		如果你需要insert into ，就相当于从客户端像服务端，插入数据，就要添加在服务端
mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2  --single-transaction  --max_allowed_packet=128M  >/tmp/full.sql


d. -R -E  --triggers 
备份时,同时将 存储过程\函数\事件\触发器 等高级对象备份走.
	## 就相当于linux中的，脚本了，定时任务了，和自己一些写好的，自定义的东西。都需要备份走
mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2  --single-transaction  --max_allowed_packet=128M -R -E  --triggers  >/tmp/full.sql


4.2.4 标准化备份/备份
[root@db01 tmp]# mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M |gzip -9 >/tmp/full_`date +%F`.sql.gz

案例：

## 案例：通过mysqldump全备+binlog实现PIT数据恢复

环境背景： 小型的业务数据库，50G，每天23:00全备，定期binlog异地备份。
故障场景： 周三下午2点，开发Navicat连接数据库实例错误，导致生产数据被误删除（DROP）


恢复思路：  
		 1.  挂维护页。
		 2.  检查备份、日志可用。
		 3.  如果只是部分损坏，建议找一个应急库进行恢复
			 a. 全备恢复 
			 b. 日志截取并恢复 
		 4.  恢复后数据校验	（业务测试部门验证）
		 5.  立即备份（停机冷备） 
		 6.  恢复架构系统
		 7.  撤维护页，恢复业务 



模拟故障: 
	1. 模拟测试数据
mysql> create database pit;
mysql> use pit 
mysql> create table t1 (id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
	2. 全备 
[root@db01 tmp]# mysqldump -uroot -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M >/tmp/full_2300.sql 
	3. 模拟周三白天的操作 
mysql> use pit
mysql> insert into t1 values(11),(22),(33);
mysql> commit;
	4. 模拟周三下午2:00,删库操作
mysql> drop database pit;
	

恢复过程 : 
	1. 恢复全备 
	source /tmp/full_2300.sql 
	   ## 在备份恢复的时候，不手动需要，set sql_log_bin=0; 是因为日志文件中，然后自动添加
	2. 截取二进制日志
	起点:  21105555
		[root@db01 tmp]# grep "\-- CHANGE MASTER TO" /tmp/full_2300.sql 
			-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=21105555;

	终点:21105836
		a. show master status ;
		b. 
			mysql> pager grep -i "drop database pit" -B 10
					## 如果不想使用了pager ，就可以unpager 也可以退出重来。
			mysql> show binlog events  in 'mysql_bin.000009';