DBA课程-day10-备份恢复迁移-2

今日预告：

1. 企业的备份恢复案例（mysqldump+binlog），年终故障恢复演练。

一、案例背景： 某中小型互联网公司。MySQL 5.7.26 ，Centos 7.6 ，数据量级80G，每日数据增量5-6M
备份策略： 每天mysqldump全备+binlog备份，每天23:00进行。
故障描述： 周三下午2点，数据由于某原因数据损坏。
处理思路： 
         1. 挂出维护页
         2. 评估一下数据损坏状态
            2.1 全部丢失-->推荐直接生产恢复
            2.2 部分丢失
            (1) 从备份中导出单表数据  
            (2)测试库进行全备恢复
         3. 恢复全备，将数据追溯到周二晚上23:00状态
         4. 截取并恢复从备份时刻，到下午两点误删除之前binlog。
         5. 校验数据一致性
         6. 撤维护页，恢复生产。
处理结果：
        1. 经过30-40分钟处理，业务恢复
        2. 评估此次故障的处理的合理性和实用性

案例模拟及恢复：
1. 进行周二全备
[root@db01 ~]# mysqldump -uroot -p123  -A -R --triggers -E --master-data=2 --single-transaction >/data/backup/full.sql

[root@db01 ~]# vim /data/backup/full.sql
SET @@GLOBAL.GTID_PURGED='ee956c61-9653-11e9-8518-000c29099eb6:1-2';
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000045', MASTER_LOG_POS=350;

2. 模拟全备之后到下午两点前的业务操作
mysql> create database mdp charset utf8mb4;
mysql> use mdp
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
mysql> insert into t1 values(11),(12),(13);
mysql> commit;
mysql> update t1 set id=20 where id>10;
mysql> commit;

3. 模拟损坏
\rm -rf /data/mysql/data/* 
pkill mysqld 
\rm -rf /data/mysql/data/* 

4. 初始化数据
[root@db01 /data/mysql/data]# mysqld --initialize-insecure --user=mysql  --basedir=/application/mysql --datadir=/data/mysql/data 
[root@db01 /data/mysql/data]# /etc/init.d/mysqld start

5. 进行全备恢复 
mysql> set sql_log_bin=0;
mysql> source /data/backup/full.sql 
mysql> flush privileges;

6.  找日志起点和终点
[root@db01 ~]# vim /data/backup/full.sql
SET @@GLOBAL.GTID_PURGED='ee956c61-9653-11e9-8518-000c29099eb6:1-2';
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000045', MASTER_LOG_POS=350;

[root@db01 ~]# mysqlbinlog --skip-gtids --include-gtids='ee956c61-9653-11e9-8518-000c29099eb6:3-7' /data/binlog/mysql-bin.000045 >/data/backup/bin.sql
或者：
[root@db01 ~]# mysqlbinlog --skip-gtids --start-position=350 /data/binlog/mysql-bin.000045 >/tmp/aa.sql

7. 恢复日志
mysql> set sql_log_bin=0;
mysql> 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

### 一条真实企业数据库备份语句
mysqldump -uroot -p123 -A  -R  --triggers --master-data=2 max_allowed_packet=128M  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

作业： 模仿以上备份命令，书写备份脚本

==================================

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

2.1.2 下载软件并安装
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.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.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

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 备份到原来数据目录下
   
   备份过程：
   1. ckpt ，记录ckpt后LSN ,to  lsn
   2. 拷贝数据页 ，保存为数据文件
   3. 自动将备份过程redo，会一并备份走，提取最后的last LSN
   
   恢复： 
   其实就是模拟了CSR过程
   对比LAST LSN ,to lsn
   使用redo进行前滚，对未提交的事务进行回滚
   最后得到一个一致性备份
          
2.4、innobackupex使用
2.4.1 全备
[root@db01 backup]# innobackupex --user=root --password=123  /data/bak
注意：
备份工具是依赖于/etc/my.cnf   
[mysqld] 
[client]
[innobackupex]
如果说配置文件没有在/etc  ，可以如下操作
[root@db01 backup]# innobackupex --defaults-file=xxxxx --user=root --password=123  /data/bak

自主定制备份路径名
[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/bak/full_$(date +%F)

备份集中多出来的文件：
-rw-r----- 1 root root       24 Jun 29 09:59 xtrabackup_binlog_info
-rw-r----- 1 root root      119 Jun 29 09:59 xtrabackup_checkpoints
-rw-r----- 1 root root      489 Jun 29 09:59 xtrabackup_info
-rw-r----- 1 root root     2560 Jun 29 09:59 xtrabackup_logfile

xtrabackup_binlog_info ：（备份时刻的binlog位置）
[root@db01 full]# cat xtrabackup_binlog_info 
mysql-bin.000003    536749
79de40d3-5ff3-11e9-804a-000c2928f5dd:1-7
记录的是备份时刻，binlog的文件名字和当时的结束的position，可以用来作为截取binlog时的起点。

xtrabackup_checkpoints ：
backup_type = full-backuped
from_lsn = 0            上次所到达的LSN号(对于全备就是从0开始,对于增量有别的显示方法)
to_lsn = 160683027      备份开始时间(ckpt)点数据页的LSN    
last_lsn = 160683036    备份结束后，redo日志最终的LSN
compact = 0
recover_binlog_info = 0

（1）备份时刻，立即将已经commit过的，内存中的数据页刷新到磁盘(CKPT).开始备份数据，数据文件的LSN会停留在to_lsn位置。
（2）备份时刻有可能会有其他的数据写入，已备走的数据文件就不会再发生变化了。
（3）在备份过程中，备份软件会一直监控着redo的undo，如果一旦有变化会将日志也一并备走，并记录LSN到last_lsn。
从to_lsn  ----》last_lsn 就是，备份过程中产生的数据变化.

2.4.2 全备的恢复
准备备份（Prepared）
将redo进行重做，已提交的写到数据文件，未提交的使用undo回滚掉。模拟了CSR的过程
[root@db01 ~]# innobackupex --apply-log  /backup/full/
恢复备份
前提：
1、被恢复的目录是空
2、被恢复的数据库的实例是关闭
systemctl stop mysqld
创建新目录

[root@db01 backup]# mkdir /data/mysql1
数据授权
chown -R mysql.mysql /data/mysql1
恢复备份
[root@db01 full]# cp -a /backup/full/* /data/mysql1/
启动数据库
vim /etc/my.cnf
datadir=/data/mysql1
[root@db01 mysql1]# chown -R mysql.mysql /data/mysql1
systemctl start mysqld

2.4.3  XBK增量备份
备份方式：基于上次的备份的增量
增量备份不能单独恢复，必须合并到全备中，一起恢复

1. 周日全备

innobackupex --user=root --password=123 --no-timestamp /data/bak/full_$(date +%F)

2. 模拟周一数据变化

create database xbk charset utf8mb4;    
use xbk
create table t1(id int);
insert into t1 values(1),(2),(3);
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)

2.4.5 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. 整理并合并周二的增量到全备

[root@db01 /data/bak]# innobackupex --apply-log  --incremental-dir=/data/bak/inc2_2019-06-26 /data/bak/full_2019-06-26/

4. 再次整理全备

innobackupex --apply-log  /data/bak/full_2019-06-26

5. 破坏数据库，恢复数据

[root@db01 /data/bak]# pkill mysqld
[root@db01 /data/bak]# \rm -rf /data/mysql/data/*
[root@db01 /data/bak]# innobackupex --copy-back /data/bak/full_2019-06-26

[root@db01 /data/mysql/data]# chown -R mysql.mysql /data/*
[root@db01 /data/mysql/data]# /etc/init.d/mysqld start

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. 模拟周日的全备

[root@db01 ~]# innobackupex --user=root --password=123 --no-timestamp /data/bak/full

2. 模拟周一的数据变化

mysql> create database hisoss charset utf8mb4;
mysql> use hisoss;
mysql> create table his_order(id int);
mysql> insert into his_order values(1),(2),(3);
mysql> commit;

3. 模拟周一的增量备份

[root@db01 /data/bak]# 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),(22),(33);
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. 有一个傻子，把数据库data目录给rm掉了

pkill mysqld 
 \rm -rf /data/mysql/data/*

8. 整理 合并备份

（1） 整理全备 
 [root@db01 ~]# innobackupex --apply-log --redo-only /data/bak/full
（2） inc1 合并并整理到full中
[root@db01 ~]# innobackupex --apply-log --redo-only --incremental-dir=/data/bak/inc1 /data/bak/full 
（3） inc2 合并并整理到full中
[root@db01 ~]# innobackupex --apply-log --incremental-dir=/data/bak/inc2 /data/bak/full 
（4） 整体的整理
innobackupex --apply-log  /data/bak/full

9. 恢复备份数据

cp -a /data/bak/full/* /data/mysql/data/
[root@db01 /data/bak]# chown -R mysql.mysql /data

10. 截取二进制日志并恢复

mysqlbinlog --skip-gtids --include-gtids='180629c3-97ed-11e9-aeaa-000c29099eb6:5' /data/binlog/mysql-bin.000050 >/data/bak/bin.sql

恢复：
mysql> set sql_log_bin=0;
mysql> source /data/bak/bin.sql


扩展： 
假如，只是少量数据被损坏，以上方法有哪些不妥的地方？
alter table t1  discard tablespace
alter table t1  import  tablespace

innobackupex --user=root --password=123 --defaults-file=/etc/my.cnf --no-timestamp --stream=tar --use-memory=256M  --parallel=8 /data/mysql_backup | gzip | ssh [email protected] " cat - > /data/mysql_backup.tgz"

 --stream=tar 
 --use-memory=256M  
 --parallel=8

4. MySQL数据迁移

4.0迁移前要考虑的问题

## 1.技术方面
选择什么工具，MDP XBK 
## 2.非技术
停机时间
回退方案

4.1 换主机

4.1.1 数据量小

思路：
1. 在线 MDP，XBK备份出来，scp到目标主机
2. 追加所有备份后的日志
3. 申请停机5分钟
4. 剩余部分的binlog继续恢复（搭建主从的方式来替代）
5. 校验数据
6. 进行业务割接

4.1.1 数据量大

XBK备份出来，scp到目标主机
搭建主从的方式
申请停机15分钟
校验数据
进行业务割接

4.2 换版本升级

例如：
5.6  -》 5.7 
（1）方法一：
建议使用 mysqldump逻辑备份方式，按业务库进行分别备份，排除掉 information_schema,performance_schema,sys
恢复完成后，升级数据字典
（2）方法二：
进行过滤复制，排除掉 information_schema,performance_schema,sys

4.3 异构迁移-系统不一样

只能用逻辑备份

4.4 异构迁移-数据库产品不同

Oracle --OGG------> MYSQL
MySQL ---CSV--> MongoDB
MySQL ---JSON--> MongoDB