1.企业的备份恢复案例(mysqldump+binlog)
案例背景:
某中小型互联网公司,mysql5.7.26,CentOS7.6,数据量80G,每日数据量5-8M
备份策略:每天mysqldump全备+binlog备份,每天23点进行
故障描述:周三下午2点,数据损坏
处理思路:
1.挂出维护页
2.评估一下数据损坏状态
2.1全部丢失----->推荐直接生产恢复
2.2 部分丢失----->(1)从备份中导出单表数据 (2测试库进行全备恢复)
3.恢复全备,将数据追溯到周二晚上23点
4.截取并恢复从备份时刻到下午两点误删除之前的binlog
5.校验数据一致性
6.撤维护页,恢复生产
处理结果:
1.经过30-40分钟处理,业务恢复
2.评估此次故障的处理的合理性和实用性
案例模拟
1.进行全备
mysqldump -uroot -p -A -R --triggers -E --master-data=2 --single-transaction -S /data/3307/mysql.sock >/data/backup/full.sql
参数解释:
-R 备份时,同时备份存储过程和函数,如果没有则自动忽略,没有警告
-E 备份事件events,如果没有则自动忽略
--triggers 备份触发器,如果没有则自动忽略
--master-data=2
记录备份开始时,position号,可以作为将来日志截取的起点
功能: 1.记录备份时的position
2.自动锁表
3.配合--single-transaction,减少锁的(innodb引擎)
--single-transaction
功能:
对于InnoDB的表,实现快照备份,不需要锁表
SET @@GLOBAL.GTID_PURGED='e0e94318-8de0-11e9-bbf7-000c29c19cf1:1-5';
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000043', MASTER_LOG_POS=194;
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
4. 初始化数据
[root@db01 /data/mysql/data]# mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data
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=oldboy123 /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表备份恢复的流程
0、xbk备份执行的瞬间,立即触发ckpt,已提交的数据脏页,从内存刷写到磁盘,并记录此时的LSN号
1、备份时,拷贝磁盘数据页,并且记录备份过程中产生的redo和undo一起拷贝走,也就是checkpoint LSN之后的日志
2、在恢复之前,模拟Innodb“自动故障恢复”的过程,将redo(前滚)与undo(回滚)进行应用
3、恢复过程是cp 备份到原来数据目录下
恢复:
其实就是模拟了CSR过程
对LAST LSN ,to LSN
使用redo进行前滚,对未提交的事务进行回滚
自主定制备份路径名
[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/bak/full_$(date +%F)
--apply-log将redo以提交的数据进行刷写,并将未提交的进行一个回滚
2.4案例
2.4.1XBK全备
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.2XBK全备的恢复
将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.3XBK增量备份演示
备份方式:基于上次的备份的增量
增量备份不能单独恢复,必须全部合并到全备中一起恢复
<1>. 全备
innobackupex --user=root --password=oldboy123 --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=oldboy123 --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=oldboy123 --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
2.4.5XBK增量恢复演示
思路:
合并所有增量到全备
每个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/
注意:最后一个增量追加不加--redo-only参数
<4>再次整理全备
innobackupex --apply-log --redo-only /data/bak/full_2019-06-26/
<5>破坏并恢复
pkill mysqld
rm -rf /data/mysql/data/*
恢复
cd /data/mysql/data/
innobackupex --copy-back /data/bak/full_2019-06-26
chown -R mysql. /data/*
systemctl start mysqld
partition按月进行分表
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=oldboy123 --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-log /data/bak/full
<2>inc1整理并合并
innobackupex --apply-log --redo-log --incremental --incremental-basedir=/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.申请停机5min时间
4.剩余部分的binlog继续恢复(搭建主从的方式来替代)
5.检验数据
6.进行业务割接
4.1.1数据量大
XBK备份出来,SCP到目标主机
搭建主从的方式
申请停机15min
检验数据
进行业务割接
4.2换版本升级
1.建议使用mysqldump逻辑备份方式,按业务库进行分别备份,排除掉 information_schema,performance_shema,sys
恢复完成后,升级数据字典
2.构建主从
进行过滤复制排除掉information_schema,performance_shema,sys。
4.3异构迁移--系统不一样
只能用逻辑备份(mysqldump),
4.4异构迁移--数据库产品不同
Oracle---OGG--->MYSQL
MYSQL----CSV--->MongoDB
MYSQL---JSON--->MongoDB