1、企业备份恢复案例（mysqldmp+binlog）
案列背景：某中小型互联网公司。mysql 5.7.26，CentOS 7.6 ，数据量级80G，每日数据增量5-6M
备份策略：每天mysqldump全备+binlog备份，每天23点进行
故障描述：周三下午俩点，数据库由于某原因数损坏。
处理思路：
1、挂出维护页
2、评估一下数据损坏的状态
1）、全部丢失--->推荐直接生产恢复
2）、部分丢失--->1）从备份中导出单表数据 2）测试库进行全备恢复
3、恢复全备，将数据追溯到周二晚上23点状态
4、截取并恢复从备份时刻到下午俩点误删除之前binlog。
5、校验数据一致性
6、撤维护页，恢复生产。
处理结果：
1、经过30-40分钟处理，业务恢复，生成故障恢复报告
2、评估此次故障的处理的合理性和实用性。
案列模拟：
1、进行周二全备
mysqldump -uroot -p1 -A -R --triggers -E --master-data=2 --single-transact
vim full.sql
SET @@GLOBAL.GTID_PURGED='952baf3a-8d93-11e9-a95b-000c299be7b1:1-8';
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=194;
2、模拟全备之后到下午俩点前的业务操作
mysql> create database mdp charset utf8mb4;
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、数据初始化
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data
systemctl start mysqld
5、进行全备恢复
set sql_log_bin=0;
source /data/backup/full.sql
mysql> flush privileges; 刷新
6、截取日志
mysqlbinlog --skip-gtids --include-gtids='952baf3a-8d93-11e9-a95b-000c299be7b1:9-13' /data/binlog/mysql-bin.000006 >/data/backup/bin.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
2、XBK的应用
2.1、备份命令介绍:
xtrabackup
innobackupex ******
2.2 备份方式——物理备份
（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.3、innobackupex使用
2.3.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.3.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
-----------------------------------------------------------------------------------------
安装并实施演练：
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、下载xtrabackup
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
yum install -y percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
查看 innobackupex --version
3、备份路径
innobackupex --defaults-file=/etc/my.cnf --user=root --password=1 /data/bak
4、关闭进程
pkill mysqld
5、删除
rm -rf /data/mysql/data/ * #----由于在这里*有其他意义，所有加了一个空格，其实是没有空格的
6、准备备份
innobackupex --apply-log /data/bak/2019-06-26_12-13-07/
7、恢复
cd /data/bak/2019-06-26_12-13-07/
cp -a * /data/mysql/data/
chown -R mysql. /data/
systemctl start mysqld
8、自主定制备份路径名
innobackupex --user=root --password=1 --no-timestamp /data/bak/full_$(date +%F)
3、XBK增量备份演示：
备份方式：基于上次的备份的增量
增量备份不能单独恢复，必须合并到全备中，一起恢复
1、全备
innobackupex --user=root --password=1 --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=1 --no-timestamp --incremental --incremental-basedir=/data/bak/full_2019-06-26 /data/bak/inc_$(date +%F)
4、模拟周二白天的数据变化
mysql> use xbk
mysql> create table t2(id int);
mysql> insert into t2 values(1),(2),(3);
mysql> commit;
5、周二晚上的增量备份
innobackupex --user=root --password=1 --no-timestamp --incremental --incremental-basedir=/data/bak/inc_2019-06-26 /data/bak/inc2_$(date +%F)
6、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 /data/bak/full_2019-06-26/
5)、破坏数据库，恢复数据
pkill mysqld
rm -rf /data/mysql/data/*
innobackupex --copy-back /data/bak/full_2019-06-26
chown -R mysql.mysql /data/*
/etc/init.d/mysqld start
cat full_2019-06-26/xtrabackup_checkpoints inc_2019-06-26/xtrabackup_checkpoints inc2_2019-06-26/xtrabackup_checkpoints
4、企业备份恢复案例（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=1 --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、模拟周一增量备份
innobackupex --user=root --password=1 --no-timestamp --incremental --incremental-basedir=/data/bak/full /data/bak/inc1
4. 模拟周二的数据变化
mysql> use hisoss;
mysql> insert into his_order values(11),(22),(33);
mysql> commit;
5、模拟周二的增量备份
innobackupex --user=root --password=1 --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）、整理全备
innobackupex --apply-log --redo-only /data/bak/full
2）、inc1 合并并整理到full中
innobackupex --apply-log --redo-only --incremental-dir=/data/bak/inc1 /data/bak/full
3）、inc2 合并并整理到full中
innobackupex --apply-log --incremental-dir=/data/bak/inc2 /data/bak/full
4）、整理的整理
innobackupex --apply-log /data/bak/full
9、恢复备份数据、加权限、重启mysql
cp -a /data/bak/full/ * /data/mysql/data #------这里是拷贝bak目录下的所有到data下，*在里有特殊意义，加了一个空格，其实是没有的
chown -R mysql.mysql /data/
systemctl start mysqld
10、截取二进制日志
mysqlbinlog --skip-gtids --include-gtids='24047f06-97ed-11e9-9198-000c299be7b1:5' /data/binlog/mysql-bin.000014 >/data/bak/bin.sql
11、恢复
mysql> set sql_log_bin=0;
mysql> source /data/bak/bin.sql;
5、MySQL数据迁移
迁移前要考虑的问题
0、技术方面
选择什么工具：MDP、XBK。
非技术方面
停机时间
回退方案
1、换主机
1、数据量小。
思路：
1、在线MDP，XBK备份出来，scp到目标主机
2、追加所有备份后的日志
3、申请停机时间5分钟
4、剩余部分的binlog继续恢复（搭建主从的方式来替代）
5、校验数据
6、进行业务割接
2、数据量大。
XBK备份出来，scp到目标主机
搭建主从的方式
申请停机15分钟
校验数据
进行业务割接
3、换版本升级
例如：
5.6 -> 5.7
1）方法一
建议使用mysqldump逻辑备份方式，按业务库进行分别备份，排除掉information_schema,performance_schema,sys，恢复完成后，升级数据字典
2）方法二
进行过滤复制，排除掉information_schema,performance_schema,sys
4、异构迁移-系统不一样
只能用逻辑备份
5、异构迁移-数据库不一样
oracle --ogg--> mysql
mysql --csv--> mongodb
mysql --json--> mongodb