前言：可以精通MySQL数据备份技术，但是希望你永远用不上MySQL数据恢复技术！

信息量太大了，这边建议您不要看为好&&&

一、运维在数据库备份恢复方面的职责

1.1设计备份策略

全备？增量？
时间，自动

1.2日常备份检查

备份是否存在
备份数据的可用性
备份空间是否够用

1.3定期数据恢复演练(测试库进行)

一季度、半年、一年

1.4故障恢复

通过现有的备份，能将数据库恢复到故障之前的时间点

1.5迁移

停机时间
回退方案

二、备份类型

2.2热备

在数据库正常工作时，备份数据，并且能够一致性恢复(只能是innodb)
对业务影响非常小

2.1温备

锁表备份，即只可查询不能修改(myisam)
影响到写入和修改的操作

2.3冷备

关闭数据库业务，数据库没有任何变更的情况下，进行数据备份
业务停止

三、备份工具

3.1逻辑备份工具

基于SQL语句进行备份(MySQL自带命令)
mysqldump   
mysqlbinlog

3.2物理备份工具

基于磁盘数据文件备份
xtrabackup(XBK) ：percona 第三方
MySQL Enterprise Backup（MEB）MySQL企业版备份

四、逻辑备份和物理备份的比较

4.1mysqldump(MDP)

优点:
不需要下载安装(MySQL自带命令)
备份出来的是SQL，文本格式，可读性高，便于备份管理
压缩比高，节省备份所占空间

缺点：
依赖于数据库引擎，需要从磁盘把数据读出，然后把数据转换成SQL进行存储，比较耗费资源，数据量大的话效率较低

建议：
100G以内的数据量，使用mysqldump
超过TB以上，我们也建议使用mysql'dump,配合分布式的系统
1EB=1024PB=1000000TB

4.2xtrabackup(XBK)

优点：
类似于直接cp数据文件，不需要管逻辑结构，相对性能较高

缺点：
可读性差
压缩比低

建议;
>100G<TB

五、备份策略

全备： 全库数据备份
增量： 备份基于全备的有变化的数据

逻辑备份=mysqldump+mysqlbinlog
物理备份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog

备份周期： 根据数据量设计周期
一般中小企业： 周期全备+每天增量备份

六、逻辑备份工具mysqldump使用

6.1MySQL客户端通用参数

-u  用户  
-p  密码   
-S  sock文件   
-h  IP  
-P  端口号 

6.2备份专用基本参数

-A   全库备份
-B   分库备份
库 表 表 表    备份某个库下的某些表，不需要参数，第一个为库名，后边的都是它的表

全备参数 -A

mkdir -p /data/backup   创建一个存放备份数据的专用目录
mysqldump -uroot -p123456 -A -S /tmp/mysql.sock >/data/backup/full.sql
可以vim进行'修改'和查看上述文件！因为文件是SQL语句

补充：常规备份是要加 --set-gtid-purged=OFF,解决备份时命令行出现密码的警告

全备参数 -B

mysqldump -uroot -p123456 -B world oldboy -S /tmp/mysql.sock >/data/backup/w_o.sql
备份world库和oldboy库

备份某个库下的一张或者多张表

mysqldump -uroot -p123456 world city country -S /tmp/mysql.sock >/data/backup/world.sql
备份world库下的city表和country表

注意：此备份方法只会备份建表语句和插入语句，
以上备份恢复时:必须库事先存在,并且ues进库才能source恢复

6.3MySQL备份核心参数

-R           在备份时，同时备份存储过程和函数，如果没有则自动忽略
-E           在备份时，同时备份触发器，若没有则自动忽略
--triggers   在备份时，同时备份触发器，若没有则自动忽略
--master-data=2  
--single-transaction

--master-data=2 （必加参数）（参树等于1或2）

参数2的功能：
1.自动记录备份时的position号
2.自动锁表
3.配合--single-transaction，减少锁的（innodb引擎）

参数等于=
0 默认值
1  以change master to命令形式，可以用作主从复制
2  以注释的形式记录，备份时刻的文件名+postion号  一般等于2，功能如上三条

--single-transaction（必加参数）

作用：
对于innodb的表，实现快照备份，不锁表

上述所说master-data可以自动加锁
在不加--single-transaction ，启动所有表的温备份，所有表都锁定
加上--single-transaction ,对innodb进行快照备份,对非innodb表可以实现自动锁表功能

-F 在备份开始时,刷新一个新binlog日志

虽然在备份时，他会刷新binlog日志，但是它会根据库的个数决定生成多少个binlog日志，一般不用！

--set-gtid-purged=auto(默认)

auto , on
off 

使用场景:
1. --set-gtid-purged=OFF, 可以使用在日常备份参数中. 可加可不加，不加会报警
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql
2. auto , on:在构建主从复制环境时必需要的参数配置   自动是outo,加入的话加on
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

--max-allowed-packet=# （128M）

如果因为表太大导致备份报错，则加入这个参数即可。
一般等于128M即可，也可根据实际情况来定

完成备份语句示例：

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF --max-allowed-packet=256M >/data/backup/full.sql

七、企业故障恢复案例

7.1背景介绍：

某小型互联网公司，MySQL5.7.26，centos7，数据量级80G，每日增长5-6M

7.2使用的备份策略：

每天mysqldump全备+binlog备份

7.3故障描述

周三下午2点，数据由于某原因数据全部损坏

7.4处理思路

1.挂出维护页
2.评估一下数据损坏状态
  2.1全部丢失---》推荐直接生产恢复
  2.2部分丢失---》1）从备份中导出但表数据 2）测试库进行全备恢复
3.恢复全备，将数据追溯到周二晚上23：00状态
4.截取并恢复从备份时刻，到下午两点误删除之前的binlog
5.效验数据一致性
6.撤回维护页，恢复生产

7.5处理结果：

1.经过30-40分钟处理，业务回复
2.评估此次故障的处理的合理性和实用性

开始干活！

案例模拟：

1.周二全备：

mysqldump -uroot -p123456 -A -R --triggers -E --master-data=2 --single-transaction >/data/backup/full.sql
全量备份（模拟周二晚上的全量备份）

获取两条重要的语句

vim /data/backup/full.sql
--master-data=2参数导致拥有如下两行：

SET @@GLOBAL.GTID_PURGED='27a3ae28-8dac-11e9-8e94-000c297eff65:1-6';
表示该备份文件中拥有1-6的gtid事务号的备份
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=194;
表示当前备份到了mysql-bin.00005号文件，的1-6事务
194代表已经备份到了position号为194号

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.模拟损坏

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

4.初始化数据库并启动 （弄一个干净的MySQL）

mysqld --initialize-insecure --user=mysql  --basedir=/application/mysql --datadir=/data/mysql/data
systemctl start mysqld

5.进行全备恢复（到周二晚上11点的全备）

set sql_log_bin=0;       临时关闭日志记录
source /data/backup/full.sql;       恢复数据
flush privileges;          刷新
set sql_log_bin=1;      再把日志记录改回来

6.找日志的起点和终点

mysql> show binlog events in 'mysql-bin.000005';
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name         | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| mysql-bin.000005 |    4 | Format_desc    |         6 |         123 | Server ver: 5.7.26-log, Binlog ver: 4                              |
| mysql-bin.000005 |  123 | Previous_gtids |         6 |         194 | 27a3ae28-8dac-11e9-8e94-000c297eff65:1-6                           |
| mysql-bin.000005 |  194 | Gtid           |         6 |         259 | SET @@SESSION.GTID_NEXT= '27a3ae28-8dac-11e9-8e94-000c297eff65:7'  |
| mysql-bin.000005 |  259 | Query          |         6 |         366 | create database mdp charset utf8mb4                                |
| mysql-bin.000005 |  366 | Gtid           |         6 |         431 | SET @@SESSION.GTID_NEXT= '27a3ae28-8dac-11e9-8e94-000c297eff65:8'  |
| mysql-bin.000005 |  431 | Query          |         6 |         526 | use `mdp`; create table t1(id int)                                 |
| mysql-bin.000005 |  526 | Gtid           |         6 |         591 | SET @@SESSION.GTID_NEXT= '27a3ae28-8dac-11e9-8e94-000c297eff65:9'  |
| mysql-bin.000005 |  591 | Query          |         6 |         662 | BEGIN                                                              |
| mysql-bin.000005 |  662 | Table_map      |         6 |         706 | table_id: 285 (mdp.t1)                                             |
| mysql-bin.000005 |  706 | Write_rows     |         6 |         761 | table_id: 285 flags: STMT_END_F                                    |
| mysql-bin.000005 |  761 | Xid            |         6 |         792 | COMMIT /* xid=815 */                                               |
| mysql-bin.000005 |  792 | Gtid           |         6 |         857 | SET @@SESSION.GTID_NEXT= '27a3ae28-8dac-11e9-8e94-000c297eff65:10' |
| mysql-bin.000005 |  857 | Query          |         6 |         928 | BEGIN                                                              |
| mysql-bin.000005 |  928 | Table_map      |         6 |         972 | table_id: 285 (mdp.t1)                                             |
| mysql-bin.000005 |  972 | Write_rows     |         6 |        1022 | table_id: 285 flags: STMT_END_F                                    |
| mysql-bin.000005 | 1022 | Xid            |         6 |        1053 | COMMIT /* xid=818 */                                               |
| mysql-bin.000005 | 1053 | Gtid           |         6 |        1118 | SET @@SESSION.GTID_NEXT= '27a3ae28-8dac-11e9-8e94-000c297eff65:11' |
| mysql-bin.000005 | 1118 | Query          |         6 |        1189 | BEGIN                                                              |
| mysql-bin.000005 | 1189 | Table_map      |         6 |        1233 | table_id: 285 (mdp.t1)                                             |
| mysql-bin.000005 | 1233 | Update_rows    |         6 |        1299 | table_id: 285 flags: STMT_END_F                                    |
| mysql-bin.000005 | 1299 | Xid            |         6 |        1330 | COMMIT /* xid=820 */                                               |
| mysql-bin.000005 | 1330 | Stop           |         6 |        1353 |                                                                    |
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
22 rows in set (0.00 sec)

因为前边可以看到，全备已经备到mysql-bin.000005文件的1-6事务，所以截取从7开始，到结尾

mysqlbinlog --skip-gtids --include-gtids='27a3ae28-8dac-11e9-8e94-000c297eff65:7-11' /data/binlog/mysql-bin.000005 >/data/backup/bin.sql

7.恢复日志备份

set sql_log_bin=0;
source /data/backup/bin.sql
set sql_log_bin=1;

完事！

若单表坏了，从全备中找到该表的建表语句和insert语句，恢复即可

统用语句，换个表名库名即可
1、获得表结构（city表）
 sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q'  full.sql>createtable.sql
2、获得INSERT INTO 语句，用于数据的恢复
 grep -i 'INSERT INTO `city`' full.sql >data.sql 
3.获取单库的备份（world库）
 sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

八、MySQL物理备份工具-xtrabackup(XBK、Xbackup)

8.1安装

8.1.1安装依赖包

yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev

8.1.2下载软件并安装

三种下载方式，我从桌面拉取（rpm包）然后yum install -y 对应的rpm包即可
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

innobackupex --version  检查下载好的版本也是检查是否安装成功

8.2、备份命令介绍:

xtrabackup
innobackupex    ******
innobackupex --version 查看版本

8.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
2.拷贝数据也，保存为数据文件
3.自动将备份过程redo,会一并备份走，提取最后的to LSN，last LSN

恢复：
其实就是模拟了CSR过程
对比LAST LSN ， From lsn
使用redo进行前滚，对未提交的事务进行回滚
最后得到一个一致性备份

8.4、innobackupex使用

8.4.1 全备

[root@mysql52 ~] mkdir -p /data/bak
[root@mysql52 ~] innobackupex -S /tmp/mysql.sock --user=root --password=123456 /data/bak
默认即全备
备份名字会自动以当时时间命名

第二种
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 /data/bak
                       强制执定读取配置文件路径

注意配置文件加入：

[client]
socket=/tmp/mysql.sock

自主定制备份文件名

[root@db01 backup] innobackupex --user=root --password=123 --no-timestamp /data/backup/file_(date +%F)
--no-timestamp 即不使用默认文件名，自定义

备份集中多出来的文件：

xtrabackup_binlog_info

备份时刻的二进制日志的文件名、gtid号、当时结束的position号 可以用来作为截取binlog时的起点。
[root@mysql52 /data/bak/2019-06-26_12-11-54]# cat xtrabackup_binlog_info 
mysql-bin.000007    194 27a3ae28-8dac-11e9-8e94-000c297eff65:1-11

xtrabackup_checkpoints

增量备份时使用
[root@mysql52 /data/bak/2019-06-26_12-11-54] cat xtrabackup_checkpoints 
backup_type = full-prepared           备份类型  full代表全量备份   incremental代表增量备份
from_lsn = 0                          上次所到达的LSN号(对于全备就是从0开始,对于增量有别的显示方法)
to_lsn = 105291190                    备份开始时间(ckpt)点数据页的LSN
                                      相差9，但是可以理解为一样，因为全量备份永远都是相差九
last_lsn = 105291199                  备份结束后，redo日志最终的LSN
compact = 0
recover_binlog_info = 0

从to_lsn  ----》last_lsn 就是，备份过程中产生的数据变化.

8.4.2全备恢复：

准备：将redo进行重做，已提交的写到数据文件，未提交的使用undo回滚掉。模拟了CSR的过程

innobackupex --apply-log /data/bak/2019-06-26_12-11-54/
准备工作
190626 12:27:00 completed OK!
看到这个才可继续恢复

恢复

前提：
1、被恢复的目录是空
2、被恢复的数据库的实例是关闭

[root@mysql52 /data/bak/2019-06-26_12-11-54] cp -a * /data/mysql/data/
[root@mysql52 /data/mysql/data] chown -R mysql.mysql *

8.4.3 innobackupex 增量备份(incremental)

说明：

1、增量备份的方式，是基于上一次备份进行增量。
2、增量备份无法单独恢复。必须基于全备进行恢复。
3、所有增量必须要按顺序合并到全备中。
专业术语，full代表全备，inc代表增量备份

全备（周日）

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

模拟周一数据变化

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;

周一晚上增量备份

innobackupex --user=root --password=123456 --no-timestamp --incremental --incremental-basedir=/data/bak/full_2019-06-26 /data/bak/inc_$(date +%F)

--no-timestamp  不适用默认的备份名，自定义备份名
--incremental   表示增量备份
--incremental-basedir=/data/bak/full_2019-06-26   基于这个做增量备份 

模拟周二白天数据变化

 use xbk
create table t2(id int);
insert into t2 values(1),(2),(3);
commit;

周二增量备份

innobackupex --user=root --password=123456 --no-timestamp --incremental --incremental-basedir=/data/bak/inc_2019-06-26 /data/bak/inc2_$(date +%F)        

检查增量备份是否正确*****

[root@mysql52 /data/bak] cat full_2019-06-26/xtrabackup_checkpoints inc_2019-06-26/xtrabackup_checkpoints  inc2_2019-06-26/xtrabackup_checkpoints
backup_type = full-backuped    备份类型，full代表全备
from_lsn = 0
to_lsn = 105293371
last_lsn = 105293380
compact = 0
recover_binlog_info = 0

backup_type = incremental     incremental代表增量备份
from_lsn = 105293371
to_lsn = 105299299
last_lsn = 105299308
compact = 0
recover_binlog_info = 0

backup_type = incremental
from_lsn = 105299299
to_lsn = 105305893
last_lsn = 105305902
compact = 0
recover_binlog_info = 0

last_lsn 减掉9刚好等于下一个的from_lsn 即代表增量备份对上了

XBK增量恢复演示：

恢复思路：
合并所有增量到全备
每个XBK备份都需要恢复准备（prepare）
--apply-log  该回滚回滚，该前滚前滚
--redo-only  数据准备，需要加此参数，除了最后一次增量不需要加

1.整理全备 (prepare)

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/
                                                         要合并的增量数据          被合并到的备份数据 （全量）      

检查合并是否正确

board.png

3.整理并合并周二增量到全备

innobackupex --apply-log --incremental-dir=/data/bak/inc2_2019-06-26 /data/bak/full_2019-06-26/
                                            要合并的数据（增量数据）     合并到（全量数据）
注意：因为是最后一次增量合并，所以不需要加redo-only参数

检查是否合并成功

clipb3oard.png

4.全部增量合并好之后，再整理一次全量备份

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

5.破坏数据（模拟数据丢失）

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

6.恢复

[root@mysql52 /data/mysql/data] innobackupex --copy-back /data/bak/full_2019-06-26
注意路径，这命令是XBK自带，其实就是cp全量数据到MySQL数据路径下

7.授权

chown -R mysql.mysql *

8.启动并检查MySQL数据是否正常

略。。。

杀手锏&终极模拟：

背景及计划说明：

企业备份恢复案例（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=123456 --no-timestamp /data/bak/full

2.模拟周一数据

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

3.模拟周一晚上的增量备份

innobackupex --user=root --password=123456 --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=123456 --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 -rf * 了。

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

8.整理 合并备份

1、整理全备
innobackupex --apply-log --redo-only /data/bak/full

2、合并并整理周一的增量(inc1)到全备

innobackupex --apply-log --redo-only --incremental-dir=/data/bak/inc1 /data/bak/full

3、合并并整理周二的增量(inc2)到全备

innobackupex --apply-log --incremental-dir=/data/bak/inc2 /data/bak/full

4、最后一次整体的整理

innobackupex --apply-log /data/bak/full

5、恢复备份的数据（此刻已经到了周二晚上的数据）

 cp -a /data/bak/full/* /data/mysql/data/
 chown -R mysql.mysql *

6、启动MySQL

systemctl start mysqld

7.查看增量备份的那一刻，已经备份的事务号

[root@mysql52 /data/bak/inc2]# cat xtrabackup_binlog_info 
mysql-bin.000009    1136    22b30c0d-97cb-11e9-88c1-000c297eff65:1-5,
27a3ae28-8dac-11e9-8e94-000c297eff65:1-11,
290e32be-97ed-11e9-ac16-000c297eff65:1-4

8、查看MySQL中的事务号，排除备份中已有的事务号

mysql> show binlog events in 'mysql-bin.000009';

9、截取二进制日志

mysqlbinlog --skip-gtids --include-gtids='290e32be-97ed-11e9-ac16-000c297eff65:5' /data/binlog/mysql-bin.000009 >/data/bak/bin.sql

10、恢复二进制日志数据

set sql_bin_log=0;
source /data/bak/bin.sql;
set sql_bin_log=1;

11、查看确认数据

mysql> select * from hisoss.his_order;

完事！升职加薪哈哈哈哈

扩展：假如只是少量数据被损坏，以上方法有哪些不妥的地方？
alter table t1 discard tablespace
alter table t1 import tablespace
先把备份的丢失的表的ibd文件移过去，创建相同表结构的表，用以上命令删除和恢复ibd文件即可。

企业备份语句：

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

上边语句参数说明

--stream=tar     压缩的形式打包，节省速度
--use-memory=256M  单表最大为256，因为有的表太大，无法备份，给个参数就好了
 --parallel=8    并发备份，一般设置为CPU个数的一般，但是不要超过16，磁盘也跟不上
ssh 那个是远程直接拷贝备份文件到某台机器上。

MySQL数据迁移

4.0 迁移前要考虑的问题
技术方面： 选择什么工具或者方法 （免费的软件：MDP 、XBK）
非技术方面：停机时间 回退方案

4.1换主机
4.1.1数据量小
思路：
1.在线 MDP、XBK备份出来，scp到目标进行恢复
2.追加所有备份后的日志
3.追加到差不多一致的时候，申请停机(五分钟即可)
4.剩余少量的二进制日志继续恢复 （搭建主从的方式来替代）
5.效验数据
6.进行业务割接（切换用户访问的地址指向新的服务器）


4.1.1数据量大
1.XBK备份出来，scp到目标主机
2.搭建主从的方式
3.申请停机十五分钟
......



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


4.3 异构迁移-系统不一样
只能用逻辑备份


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

oracle ----> MYSQL