day10（备份恢复*****）
2019-06-26 本文已影响0人
五月_w
1、企业的备份恢复案列（mysqldump+binlog），年终故障恢复演练
案例背景：某中小型互联网公司。mysql 5.6.26 ,Cent0s 7.6 ,数据量级80G，每日数据增量5-6M
备份策略：每天mysqldump全备+Binlog备份
故障描述：周三下午两点数据由于某原因数据损坏。
处理思路：
1、挂出维护页。
2、评估一下数据损坏状态
1)、全部丢失------>推荐直接生产恢复。
2）、部分丢失------>a.从备份中导出单表数据 b.测试库进行全备恢复。
3、恢复全备，将数据追溯到周二晚上23:00状态。
4、截取并恢复从备份时刻，到下午两点误删除之前binlog。
5、校验数据一致性。
6、撤维护页，恢复生产。
处理结果：
1、经过30-40分钟处理，业务恢复
2、评估此次故障的处理的合理性和实用性
案例模拟：
1、进行全备
mysqldump -uroot -p123 -A -R --triggers -E --master-data=2 --single-transaction >/data/backup/full.sql
vim /data/backup/full.sql
SET @@GLOBAL.GTID_PURGED='ac73f334-8d93-11e9-986d-000c2987e498:1-13';
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000022', MASTER_LOG_POS=194;
2、模拟全备之后到下午2点之前的业务操作
create database mdp charset utf8mb4;
use mdp
create table t1(id int);
insert into t1 values(1),(2),(3);
insert into t1 values(11),(12),(13);
commit;
insert into t1 values(15);
commit;
update t1 set id=20 where id>10;
select * from t1;
3、模拟损坏
rm -rf /data/mysql/data
pkill mysqld
rm -rf /data/mysql/data
4、初始化数据
mysqld --initialize-insecure --user=mysql --datadir=/data/mysql/data --basedir=/application/mysql
systemctl start mysqld
5、进行全备恢复
mysql -uroot -p
set sql_log_bin=0;
source /data/backup/full.sql;
flush privileges;
6、找日志起点和终点
vim /data/backup/full.sql
SET @@GLOBAL.GTID_PURGED='ac73f334-8d93-11e9-986d-000c2987e498:1-13';
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000022', MASTER_LOG_POS=194;
mysqlbinlog --skip-gtids --include-gtids='ac73f334-8d93-11e9-986d-000c2987e498:14-17' /data/binlog/mysql-bin.000022 >/data/backup/bin.sql
7、登录数据库恢复日志
set sql_log_bin=0;
source /data/backup/bin.sql;
扩展：从全备中导出单表备份
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
2、XBK的应用
2.1安装
2.1.1 安装依赖包：
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
下载工具
yum install percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
innobackupex --version
备份
innobackupex --user=root --password=123 /data/bak
cd /data/bak/2019-06-26_12-14-07
cat xtrabackup_binlog_info ------>包含二进制日志 gtid position
cat xtrabackup_checkpoints ------->包含起始结束LSN号
cat xtrabackup_info ----->包含总体信息
2.2、备份命令介绍
xtrabackup
innobackupex *****
2.3、备份方式--------物理备份
(1)对于非innodb表（比如 myisam）是，锁表cp数据文件，属于温备份
(2)对于innodb的表（支持事务的），不锁表，拷贝数据页，最终以数据文件的方式保存下来，把一部分redo和undo一并备走。属于热备方式。
面试题
xbk 在innodb表备份恢复的流程
备份过程：
1、ckpt，记录ckpt后的LSN，to LSN
2、拷贝数据页，保存为数据文件
3、自动将备份过程redo,会一并备份走，提取最后的LSN，last LSN
恢复：
其实就是模拟了CSR过程
对LAST LSN ,From LSN
使用redo进行前滚，对未提交的事务进行回滚
2.4、案列
2.4.1、XBK全备
1、全备
注意：备份工具依赖于/etc/my.cnf
vim /etc/my.cnf
[client]
socket=/tmp/mysql.sock
innobackupex --user=root --password=123 /data/bak
2、模拟数据库损坏环境
pkill mysqld
rm -rf /data/mysql/data/*
2.4.2、全备的恢复
将redo进行重做，已提交的写入数据文件
innobackupex --apply-log /data/bak/2019-06-26_12-26-38
cp -a * /data/mysql/data/
chown -R mysql. /data/mysql/data/*
systemctl start mysqld
2.4.3、XBK增量备份
备份方式：基于上次的备份的增量
增量备份不能单独恢复，必须合并到全备中一起恢复
1、全备
innobackupex --user=root --password=123 --no-timestamp /data/bak/full_$(date +%F)
2. 模拟周一数据变化
mysql> create database xbk charset utf8mb4;
mysql> use xbk
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
3. 周一晚上增量备份
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/bak/full_2019-06-26 /data/bak/inc_$(date +%F)
4. 模拟周二白天的数据变化
use xbk
create table t2(id int);
insert into t2 values(1),(2),(3);
commit;
5. 周二晚上的增量备份
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/bak/inc_2019-06-26 /data/bak/inc2_$(date +%F)
6. 检查备份没有接上
cat full_2019-06-26/xtrabackup_checkpoints inc_2019-06-26/xtrabackup_checkpoints inc2_2019-06-26/xtrabackup_checkpoin
image.png
2.4.4、XBK增量恢复演示
思路：合并所有增量导全备
每个XBK备份都需要恢复准备（prepare）
--apply-log
--redo-only 合并增量的时候用，防止回滚
1、整理全备
innobackupex --apply-log --redo-only /data/bak/full_2019-06-26/
2、整理并合并周一增量到全备
innobackupex --apply-log --redo-only --incremental-dir=/data/bak/inc_2019-06-26 /data/bak/full_2019-06-26/
3、整理并合并周二增量到全备
innobackupex --apply-log --incremental-dir=/data/bak/inc2_2019-06-26 /data/bak/full_2019-06-26
4、再次整理全备
innobackupex --apply-log --redo-only /data/bak/full_2019-06-26/
5、破坏并恢复
pkill mysqld
cd /data/mysql/data
rm -rf *
innobackupex --copy-back /data/bak/full_2019-06-26
chown -R mysql. /data/*
systemctl start mysqld
3. 企业备份恢复案例（XBK full+inc+binlog）
案例背景： 某中型互联网公司。MySQL 5.7.26 ，Centos 7.6 ，数据量级600G，每日数据增量15-50M
备份策略： 周日XBK全备+周一到周六inc增量+binlog备份，每天23:00进行。
故障描述： 周三下午2点，数据由于某原因数据损坏。
处理思路：
1. 挂出维护页
2. 评估一下数据损坏状态
2.1 全部丢失-->推荐直接生产恢复
2.2 部分丢失
3. 整理合并所有备份：full+inc1+inc2
4. 截取 周二晚上到周三下午午故障点的binlog日志
5. 恢复全备，恢复binlog
6. 检查数据完整性
7. 恢复业务
处理结果：
1. 经过70-80分钟处理，业务恢复
2. 评估此次故障的处理的合理性和实用性
案例模拟：
1. 模拟周日的全备
innobackupex --user=root --password=123 --no-timestamp /data/bak/full
2. 模拟周一的数据变化
create database hisoss charset utf8mb4;
use hisoss
create table his_order(id int);
insert into his_order values(1),(2),(3);
commit；
3. 模拟周一的增量备份
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/bak/full /data/bak/inc1
4. 模拟周二数据变化
use hisoss
insert into his_order values(11),(12),(13);
commit；
5. 模拟周二的增量备份
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/bak/inc1 /data/bak/inc2
6. 模拟周三数据变化
use hisoss
insert into his_order values(111),(222),(333);
commit；
7.破坏数据库
pkill mysqld
cd /data/mysql/data
rm -rf *
8. 整理 合并备份
（1）整理全备
innobackupex --apply-log --redo-only /data/bak/full
（2）inc1 整理并合并
innobackupex --apply-log --redo-only --incremental --incremental-dir=/data/bak/inc1 /data/bak/full
（3）inc2 整理并合并
innobackupex --apply-log --incremental --incremental-dir=/data/bak/inc2 /data/bak/full
(4) 检查
cd /data/bak
cat full/xtrabackup_checkpoints inc2/xtrabackup_checkpoints
（5）整理全备
innobackupex --apply-log /data/bak/full
9.恢复备份数据
cp -a /data/bak/full/* /data/mysql/data/
chown -R mysql. /data/*
systemctl start mysqld
10. 截取周二晚上11点到下午2点的数据
cd /data/bak/inc2
cat xtrabackup_binlog_info
mysql -uroot -p
show binlog events in 'mysql-bin.000030';
mysqlbinlog --skip-gtids --include-gtids='2f3b00d2-97ed-11e9-8dae-000c2987e498:5' /data/binlog/mysql-bin.000030 >/data/bak/bin.sql
恢复：
set sql_log_bin=0;
source /data/bak/bin.sql;
use hisoss;
select * from his_order;
扩展
假如，只是少量数据被损坏，以上方法有哪些不妥？
alter table t1 diacard tablespace
alter table t1 import tablespace
4、MySQL数据迁移
4.0、迁移前靠考虑的问题
技术方面
选择什么工具 MDP XBK
非技术方面
停机时间
回退方案
4.1、换主机
4.1.1、数据量小
思路：
1. 在线 MDP , XBK备份出来，scp到目标主机
2. 追加所有备份后的日志
3. 申请停机
4. 剩余部分的binlog继续恢复（搭建主从的方式来替代）
5. 校验数据
6. 进行业务割接
4.1.2、数据量大
1. XBK备份出来，scp到目标主机
2. 搭建主从的方式
3. 申请停机15分钟
4. 校验数据
5. 进行业务割接
4.2、换版本升级
例如：
5.6 ----> 5.7
（1）方法一：
建议使用mysqldump逻辑备份方式，按业务库进行分别备份，排除掉 information_schema,performance_schema,sys
恢复完成后，升级数据字典
（2）方法二：
进行过滤复制，排除掉 information_schema,performance_schema,sys
4.3、异构平台- 系统不一样
系统不一样，只能用mysqldump逻辑备份
4.4、异构- 数据库产品不同
Oracle ---OGG-----> MySQL
MySQL ---CSV------>MogoDB
MySQL ---JSON----->MogoDB
