mysql_7 备份恢复
标签（空格分隔）： mysql
mysql数据损坏类型
物理损坏
硬盘损坏： 硬件 磁道 dd 格式化
文件损坏： 数据文件损坏 redo损坏
逻辑损坏
drop
delete
truncate
update
dba 、运维在备份、恢复的职责
设计备份和容灾的策略
备份策略
备份工具选择
备份周期设计
备份监控方法
容灾策略
备份：什么备份 主从
架构： 高可用 演示从库 灾备库
定期的备份、容灾检查
备份软件 -> 带库
定期的故障恢复演练
数据损坏时的恢复且快速恢复
数据迁移工作
mysql 常用备份工具
- 逻辑备份方式
mysqldump
mydumper
load data in file
主从方式
-
物理备份方式
MySQL Enterprise Backup(企业版)
Percona Xtrabackup (PBK,XBK) -
架构备份方式
mysqldump mdp 应用
逻辑备份工具 备份的是sql语句
InnoDB 可以采取快照备份的方式。开启一个独立的事务，获取当前最新的一次性快照 放在临时表中 转换成sql语句（create database create table insert ） 保存到sql文件中
非innodb表
需要锁表备份 触发FTWARL 全局锁表 转换成sql语句（create database create table insert ） 保存到sql文件中
mysqldump 核心参数
连接参数
-u #用户
-p # 密码
-h #host
-P
-S #指定socket
备份参数
-A #全部备份
mysqldump -A -u root -p > /tmp/all.sql
-B 备份1或多个库
mysqldump -u root -p -B world test > /tmp/wt.sql
备份单表或多表
mysqldump -u root -p world city > /tmp/world_city.sql
备份高级参数
--master-data = 2
场景：
每周日 23：00 全备,周一到周六 binlog备份。所有备份时完整的。
周三时，有一个核心运维人员删库操作。
恢复全备 + 所有需要binlog恢复
痛点：binlog 的 截取 起点和终点
起点：寻找比较困难
方法1： 最好备份的时间开启时，立即切割日志。 -F 刷新新的日志
方法2： 备份开始时，自动记录日志文件信息 --master-data=2
终点：drop之前的位置点。
功能：
1.备份时自动记录binlog信息
2.自动锁表和解锁
3.配合single transaction 可以减少 锁表时间。
mysqldump -u root -p -A --master-data=2 > /tmp/full.sql
#会在备份文件上多出
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.00005', MASTER_LOG_POS=355
--single-transaction
对于innodb引擎表备份时，开启一个独立事务，获取一致性的快照进行备份。 最好和--master-data=2 一起使用
mysqldump -u root -p -A --master-data=2 --single-transaction > /tmp/full.sql
-R -E --triggers
-R #备份存储过程和函数
-E #备份事件
--triggers #触发器
mysqldump -u root -p -A --master-data=2 --single-transaction -R -E --triggers > /tmp/full.sql
--max_allowed_packet=64M
mysqldump -u root -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /tmp/full.sql
超出包的最大传输大小，注意：客户端和服务端都可以使用这个参数
备份案例
场景：
基础环境： centos 7.6 + mysql 5.7 LNMT 网址业务 数据量100G
备份策略： mysqldump每天全备， binlog定时备份
故障: 核心业务库被误删除
恢复思路：
1.挂维护页
2.找测试库
3.恢复周二全备
4.截取周二全备 然后恢复binlog日志
5.测试业务功能正常
6.恢复业务
方案1： 故障库导回到原生产
方案2： 直接用测试库充当生成库，先跑着。之后到导入到主业务库
1.创建数据
create database mdp charset utf8mb4;
2.模拟备份
mysqldump -u root -p -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /tmp/full_date + %F.sql
3.再插入一些数据
4.删除库
drop database mdp;
5.开始恢复
检查全备的开始id
vim full_时间.sql 找到下面开始的id
-- change master to master_log_file
6.恢复全备
set sql_log_bin=0
source /data/xxx.sql
7.截取binlog
起点：
change master to master_log_file='mysql-bin.000019', MASTER_LOG_POS=788;
终点
show master status;
show binlog events in 'mysql-bin.000020'
找到drop之前的位置点
position截取
mysqlbinlog --skip-gtids --start-position=788 --stop-position=1275 /data/binlog/mysql-bin.000019 mysql-bin.000020 > /tmp/binlog.sql
gtid截取
起点中记录了
set @@GLOBAL.GTID_PURGED='';
mysqlbinlog --skip-gtids --include-gtids="开始的gtids:17-19" /data/binlog/mysql-bin.000019 mysql-bin.000020 > /tmp/binlog.sql
8.恢复binlog
set sql_log_bin = 0
source /tmp/binlog.sql
set sql_log_bin = 1
比较
SAS 硬盘 做 RAID 10
磁盘阵列
从硬件层面提高了可用性 速度快 成本高
mysqldump 适合小数据量的
可读性比较强 压缩比 节省空间
备份时间相对较长 恢复时间长
分布式架构 数据量较大时候，可以采取分布式备份，也可以选择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