备份恢复与迁移

1 DBA 在数据库备份恢复方面的职责

1.1 设计备份策略
全备 增量 时间 自动

1.2 日常备份检查
备份存在性 备份空间够用否

1.3 定期恢复演练(测试库)
一季度 或者 半年

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

1.5 迁移（非技术）
1. 停机时间 2. 回退方案

2 备份类型
2.1 热备
在数据库正常业务时,备份数据,并且能够一致性恢复（只能是innodb） 对业务影响非常小

2.2 温备
锁表备份,只能查询不能修改（myisam） 影响到写入操作

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

3 备份方式及工具介绍
3.1 逻辑备份工具
基于SQL语句进行备份 mysqldump（MDP） * mysqlbinlog *

3.2 物理备份工具
基于磁盘数据文件备份 xtrabackup(XBK) ：Percona 第三方 * MySQL Enterprise Backup（MEB）

4. 逻辑备份和物理备份的比较
4.1 mysqldump (MDP)
优点： 1.不需要下载安装 2.备份出来的是SQL，文本格式，可读性高,便于备份处理 3.压缩比较高，节省备份的磁盘空间 缺点： 4.依赖于数据库引擎，需要从磁盘把数据读出 然后转换成SQL进行转储，比较耗费资源，数据量大的话效率较低 建议： 100G以内的数据量级，可以使用mysqldump 超过TB以上，我们也可能选择的是mysqldump，配合分布式的系统 1EB =1024 PB = 1000000 TB

4.2 xtrabackup(XBK)
优点： 1.类似于直接cp数据文件，不需要管逻辑结构，相对来说性能较高 缺点： 2.可读性差 3.压缩比低，需要更多磁盘空间 建议： >100G<TB

5.备份策略
5.1 备份方式
全备:全库备份，备份所有数据 增量:备份变化的数据 逻辑备份=mysqldump+mysqlbinlog 物理备份=xtrabackup_full+xtrabackup_incr+binlog 或者 xtrabackup_full+binlog

5.2 备份周期:
根据数据量设计备份周期 比如：周日全备，周1-周6增量 其他：通过主从复制备份

6. 逻辑备份工具-mysqldump??
6.1 客户端通用命令,和链接有关
-u -p -S -h -P 本地备份连接方式： mysqldump -uroot -pxxx -S /tmp/mysql.sock远程备份的连接方式： mysqldump -uroot -pxxx -h xxx -P xxx

6.2 基本备份参数
-A 全库备份 例子：实现全库备份 [root@db01 ~]# mkdir -p /data/backup[root@db01 ~]# mysqldump -uroot -p123 -A -S /tmp/mysql.sock >/data/backup/full.sql-B 备份 单个库或多个库数据 例子: 备份oldboy和world数据库 [root@db01 ~]# mysqldump -uroot -p123 -B world oldboy -S /tmp/mysql.sock >/data/backup/db.sql 库名 表名 ：备份某个库下的1张或多张表 例子：备份world数据库下的city和country表 [root@db01 ~]# mysqldump -uroot -p123 world city country -S /tmp/mysql.sock >/data/backup/tab.sql 注意： 此种方法，只会备份建表+插入语句。所以，恢复前需要把库建好，而且要use到库中。

6.3 必加参数（1）
-R 在备份时，同时备份存储过程和函数，如果没有会自动忽略-E 在备份时，同时备份EVENT，如果没有会自动忽略—triggers 在备份时，同时备份触发器，如果没有会自动忽略

6.4 必加参数(2)
—master-data=2 记录备份开始时 position号 ，可以作为将来做日志截取的起点。 功能： 1. 记录备份时的position 2. 自动锁表 3. 配合—single-transaction，减少锁的(innodb引擎) —single-transaction Creates a consistent snapshot by dumping all tables in a single transaction. Works ONLY for tables stored instorage engines which support multiversioning (currently only InnoDB does); the dump is NOT guaranteed to be consistent for other storage engines. While a—single-transaction dump is in process, to ensure a valid dump file (correct table contents and binary log position), no other connection should use the following statements: ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, as consistent snapshot is not isolated from them. Option automatically turns off —lock-tables. 对于innodb的表，实现快照备份，不锁表

6.5 其他(不是必加的，了解下功能即可)
-R -E —triggers 备份时,同时将 存储过程\函数\事件\触发器 等高级对象备份走.—max-allowed-packet=128—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.sql2. auto , on:在构建主从复制环境时需要的参数配置 mysqldump -uroot -p -A -R -E —triggers —master-data=2 —max-allowed-packet=128M —single-transaction —set-gtid-purged=ON >/data/backup/full.sql3. 标准化备份：[root@db01 tmp]# mysqldump -uroot -p -A —master-data=2 —single-transaction -R -E —triggers —maxallowed_packet=64M |gzip -9 >/tmp/fulldate +%F.sql.gz

6.6 企业的备份恢复案例（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. 评估此次故障的处理的合理性和实用性

案例模拟及恢复：
6.7.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;

6.7.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;

6.7.3 模拟损坏
\rm -rf /data/mysql/data/ pkill mysqld\rm -rf /data/mysql/data/

6.7.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

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

6.7.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

6.7.7 恢复日志
mysql> set sqllog_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 作业： 模仿以上备份命令，书写备份脚本

7 XBK的应用
7.1 安装
2.1.1 安装依赖包： wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repoyum -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.rpmhttps://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

7.2 备份命令介绍:
xtrabackup innobackupex **

7.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进行前滚，对未提交的事务进行回滚 最后得到一个一致性备份

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

7.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.cnfdatadir=/data/mysql1[root@db01 mysql1]# chown -R mysql.mysql /data/mysql1systemctl start mysqld

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

案例一：
# 1. 周日全备 innobackupex —user=root —password=123 —no-timestamp /data/bak/full$(date +%F) # 2. 模拟周一数据变化 create database xbk charset utf8mb4; use xbkcreate 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 xbkcreate 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/inc2019-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 tablespacealter table t1 import tablespaceinnobackupex —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 —parallel=8

8 MySQL数据迁移
## 4.0迁移前要考虑的问题## 技术方面选择什么工具，MDP XBK ## 非技术停机时间 回退方案 ## 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 ——> MYSQL

9. Percona Xrabackup 应用??
5.1 介绍
物理备份工具. 备份恢复更快.
支持全备和增量备份

5.2 全备备份逻辑
a. 8.0 之前
预备: 初始化进程和线程,分配专用内存. 备份:0. 连接目标数据库,获取数据库信息. a. 当前LSN号码记录 —-> show engine InnoDB stutus ; 主要: Last checkpoint at NO.b. non-InnoDB 数据 :frm , csv , MYI ,MYI ——> FTWRLc. unlock tables; d. Copy Innodb 数据: ibd ibdata1 undo tmp ,可以允许DML e. 备份期间的redo截取和备份,并且记录LSN号. 结束: 记录binlog的当前位置点,将所有备份信息记录至专用日志文件中.

b. 8.0 之前
预备: 初始化进程和线程,分配专用内存. 备份:0. 连接目标数据库,获取数据库信息. a. 当前LSN号码记录 —-> show engine InnoDB stutus ; 主要: Last checkpoint at NO.b. LOCK INSTANCE FOR BACKUP; UNLOCK INSTANCE; c. Copy Innodb 数据: ibd ibdata1 undo tmp ,可以允许DML d. 备份期间的redo截取和备份,并且记录LSN号. 结束: 记录binlog的当前位置点,将所有备份信息记录至专用日志文件中.
5.3 增量备份逻辑
a. 第一次增量备份,使用全备作为”参照物”,把变化的数据页和备份过程中产生的redo保存.
b. 往后所有的增量,都基于上一次备份作为参照物.把变化的数据页和备份过程中产生的redo保存.
c. 增量备份只针对InnoDB表有效,所以在8.0之前,针对非InnoDB表,都是全备.

5.4 恢复过程??
例如: 备份策略为,FULL+inc1+inc2….
a. prepare 全备 (CR)应用redo前滚 应用undo回滚(省略) b. 合并所有增量到全备并且prepare 应用redo前滚 应用undo回滚(除了最后一次增量,这步省略) c. 合并后的全备prepare d. 恢复备份
5.5 PXB的版本兼容性（选择）

MySQL 5.6 ,5.7 : PXB 2.4版本
MySQL 8.0.11 ~ 8.0.19 : PXB 8.0 稳定版.
MySQL 8.0.20 : PXB 8.0.12+

5.6 全量备份
5.6.0 安装
rz yum install -y mysql-8.0.20-linux-glibc2.12-x86_64
5.6.1 全量备份
mkdir -p /data/backup xtrabackup —defaults-file=/etc/my.cnf —user=root —password=123 —backup —target-dir=/data/backup/full Ps： 需要mysql客户端配置sock /etc/mysql.cnf [client]socket=/tmp/mysql.socket 或命令行指定： —socket=/tmp/mysql.sock
5.6.2 数据恢复：
a 搞破坏
[root@db01 ~]# pkill mysqld [root@db01 ~]# rm -rf /data/3306/data/ [root@db01 ~]# rm -rf /data/3306/logs/ [root@db01 ~]# rm -rf /data/3306/binlog/
b 准备：(CR)
从： mv /data/3306/data/ /tmp/ 清空数据 mv /data/3306/binglog/ /tmp/ 清空binglog日志：

xtrabackup —prepare —target-dir=/data/backup/full 说明： 模拟CR过程，将redo前滚，undo回滚，让备份数据是一致状态
c 拷回数据：
xtrabackup —copy-back —target-dir=/data/backup/full
d 修改权限并启动数据库
[root@db01 data]# chown -R mysql.mysql /data/* [root@db01 data]# /etc/init.d/mysqld start

5.7 增量备份

5.7.1 备份操作：

  1. # 1.备份操作：
  2. # 1.1.全量备份（周日）：
  3. xtrabackup --defaults-file=/etc/my.cnf  --socket=/tmp/mysql.sock  --user=root --password=123  --backup --parallel=4 --target-dir=/data/backup/full
  1. # 模拟周一白天操作
  2. mysql> create database pxb;
  3. mysql> use pxb
  4. mysql> create table t1 (id int);
  5. mysql> insert into t1 values(1),(2),(3);
  6. mysql> commit;
  1. # 1.2.增量备份（周一晚上）：
  2. xtrabackup --defaults-file=/etc/my.cnf --socket=/tmp/mysql.sock  --user=root --password=123  --backup --parallel=4 --target-dir=/data/backup/inc  --incremental-basedir=/data/backup/full
  4. parallel=4   并发
  5. --target-dir=/data/backup/inc   文件放在哪
  6. --incremental-basedir 参照物
  1. # 模拟损坏  
  2. [root@db01 ~]# pkill mysqld
  3. [root@db01 ~]# rm -rf /data/3306/data/*  /data/3306/binlog/*
  4. [root@db01 ~]# rm -rf /data/3306/data/*  /data/3306/binlog/*
  5. [root@db01 ~]# rm -rf /data/3306/data/*  /data/3306/binlog/*

5.7.2 恢复

  1. # 2.恢复操作：
  2. # 2.1 准备全备份的日志：
  3. xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full
  6. # 2.2 准备增量备份的日志：
  7. xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full  --incremental-dir=/data/backup/inc
  10. # 2.3 全备份准备：
  11. # xtrabackup --prepare --target-dir=/data/backup/full
  14. # 2.4 拷回数据：
  15. xtrabackup    --copy-back --target-dir=/data/backup/full
  17. #2.5 修改数据目录的权限和属性：
  18. chown -R mysql:mysql /data/*

10. 克隆 迁移

10.1 本地clone

  1. 4.1.1 加载插件
  2. INSTALL PLUGIN clone SONAME 'mysql_clone.so';
  4. SELECT PLUGIN_NAME, PLUGIN_STATUS
  5. FROM INFORMATION_SCHEMA.PLUGINS
  6. WHERE PLUGIN_NAME LIKE 'clone';
  8. 4.1.2 创建克隆专用用户
  9. CREATE USER clone_user@'%' IDENTIFIED by 'password'; 
  10. GRANT BACKUP_ADMIN ON *.* TO 'clone_user';
  12. 4.1.3 本地克隆
  13. [root@db01 3306]# mkdir -p /data/test/
  14. [root@db01 3306]# chown -R mysql.mysql /data/
  15. mysql -uclone_user -ppassword -e "CLONE LOCAL DATA DIRECTORY = '/data/test/clonedir';"
  17. # 观测状态
  18. mysql -uroot -p123 -e  "SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress;"
  20. 4.1.4 启动新实例
  21. [root@db01 clonedir]# mysqld_safe  --datadir=/data/test/clonedir --port=3333 --socket=/tmp/mysql3333.sock --user=mysql --mysqlx=OFF &

10.2 远程clone

  1. 4.2 远程clone
  4. 4.2.0 各个节点加载插件
  6. INSTALL PLUGIN clone SONAME 'mysql_clone.so';
  7. 或
  9. [mysqld]
  10. plugin-load-add=mysql_clone.so
  11. clone=FORCE_PLUS_PERMANENT
  14. SELECT PLUGIN_NAME, PLUGIN_STATUS
  15. FROM INFORMATION_SCHEMA.PLUGINS
  16. WHERE PLUGIN_NAME LIKE 'clone';
  19. 4.2.1 创建克隆用户 
  21. 官方建议:  
  22. # 源端:  backup admin 
  23. mysql -uroot -p123 -e "create user backup@'10.0.0.%' identified with mysql_native_password by '123';"
  24. mysql -uroot -p123 -e "grant backup_admin   on *.* to  backup@'10.0.0.%';"
  27. # 目标端: clone admin 
  28. mysql -uroot -p123 -S /tmp/mysql3333.sock -e "create user clone@'10.0.0.%' identified with mysql_native_password by '123';"
  29. mysql -uroot -p123 -S /tmp/mysql3333.sock -e "grant clone_admin  on *.* to  clone@'10.0.0.%';"
  32. 4.2.2 远程clone(目标端)
  33. # 设置白名单
  34. mysql -uroot -p123 -S /tmp/mysql3333.sock -e "SET GLOBAL clone_valid_donor_list='10.0.0.51:3306';"
  36. # 开始克隆
  37. mysql -uclone -p123 -h10.0.0.51  -P3333 -e "CLONE INSTANCE FROM backup@'10.0.0.51':3306 IDENTIFIED BY '123';"
  40. +++++++++++++++++++++++++++++
  41. [root@db01 clonedir]# mysql -uclone -p123 -h10.0.0.51  -P3333 -e "CLONE INSTANCE FROM backup@'10.0.0.51':3306 IDENTIFIED BY '123';"
  42. mysql: [Warning] Using a password on the command line interface can be insecure.
  43. ERROR 3870 (HY000) at line 1: Clone Donor plugin mysqlx is not active in Recipient.
  46. vim /etc/my.cnf  --->  mysqlx=off  -----> /etc/init.d/mysqld restart
  48. ++++++++++++++++++++++++++++++