day10 备份恢复

一、企业的备份恢复案例 (mysqldump+binlog)

案例背景：

某中小型互联网公司：MySQL 5.7.26 CentOS 7.6
数据量级 80G，每日数据量增5—6G

备份策略：

每天mysqldump全备+binlog备份，每天23：00进行

故障描述：

周三下午14时，数据由于某种原因数据损坏

处理思路：

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

处理结果：

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

案例模拟：

1.进行全备

mysqldump -uroot -p123  -A -R --triggers -E --master-data=2 --single-transaction >/data/backup/full.sql
--->进行全备
vim full.sql   --->查看如下内容：
SET @@GLOBAL.GTID_PURGED='3955eabf-8d95-11e9-b6fa-000c296913bb:1-11';
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000014', MASTER_LOG_POS=194;

2. 模拟全备之后到下午两点

mysql> create database mdp charset utf8mb4;
mysql> use mdp
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
mysql> insert into t1 values(4),(5),(6);
mysql> commit;
mysql> insert into t1 values(7),(8),(9);
commit;
mysql> update t1 set id=20 where id>10;
mysql> commit;

3. 模拟破坏

[root@db01 /data/mysql/data]# \rm -rf /data/mysql/data/*
[root@db01 /data/mysql/data]# pkill mysqld
[root@db01 /data/mysql/data]# \rm -rf /data/mysql/data/*

4. 初始化数据

[root@db01 /data/mysql/data]# mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data

5. 进行全备恢复

mysql> set sql_log_bin=0;
mysql> source /data/backup/full.sql
mysql> flush privileges;

6. 找日志起点和重点

[root@db01 /data/mysql/data]# vim full.sql

SET @@GLOBAL.GTID_PURGED='3955eabf-8d95-11e9-b6fa-000c296913bb:1-11';           
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000014', MASTER_LOG_POS=194;

[root@db01 /data/mysql/data]# mysqlbinlog --skip-gtids --include-gtids='3955eabf-8d95-11e9-b6fa-000c296913bb:12-14' /data/binlog/mysql-bin.000014 >/data/backup/bin.sql
或者：
[root@db01 /data/mysql/data]# mysqlbinlog --skip-gtids --start-position=194 /data/binlog/mysql-bin.000014 >/tmp/a.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

二、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 备份命令介绍

xerabackup
innobackupex   *****

2.3 备份方式——物理备份

(1) 对于非Innodb表(比如myisam)是，锁表CP数据文件，属于一种温备份。
(2) 对于Innodb的表(支持事务的)，不锁表，拷贝数据页，最终以数据文件的方式保存下来，把一部分redo和undo一并备份走，属于热备方式。

面试题：XBK在innodb表备份恢复的流程

  1. XBK备份执行的瞬间，立即触发ckpt，已提交的数据脏页，从内存刷写到磁盘，并记录此时的LSN号
  2. 备份时，拷贝磁盘数据页，并且记录备份过程中产生的redo和undo一起拷贝走，也就是checkpoint LSN之后的日志
  3. 在恢复之前，模拟Inodb“自动故障恢复”的过程，将redo（前滚）和undo（回滚）进行应用
  4. 恢复过程是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]
[innodbckupex]
如果说配置文件没有在/etc，可以如下操作：
[root@db01 backup]# innobackupex --defaults-file=xxx --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 全备的恢复

准备备份(Preapred)
将redo进行重做，已提交的写到数据文件，未提交的使用undo回滚掉，模拟了CSR的过程
[root@db01 ~]# innobackupex --apply-log /backup/full/
恢复备份：
前提：
1. 被恢复的目录是空
2. 被恢复的数据库的实例是关闭

[root@db01/data/bak]# pkill mysqld
[root@db01/data/bak]# cd /data/mysql/data/
[root@db01/data/mysql/data]# \rm -rf /data/mysql/data/*
[root@db01/data/bak]# innobackupex --apply-log /data/bak/2019-06-26_12-13-07/
[root@db01/data/bak]# cd 2019-06-26_12-13-07/
[root@db01/data/bak/2019-06-26_12-13-07]# cp -a * /data/mysql/data/
[root@db01/data/mysql/data]# chown -R mysql.mysql *
[root@db01/data/mysql/data]# systemctl start mysqld

2.4.3 XBK增量备份

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

1. 周日全备
[root@db01/data/bak]# innobackupex --user=root -password=123 --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. 周一晚上增量备份
[root@db01/data/bak]# innobackupex --user=root --password=123 --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 t1 values(1),(2),(3);
mysql> commit;

5. 周二晚上的增量备份
[root@db01/data/bak]# 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. 整理全备
[root@db01/data/bak]# innobackupex --apply-log --redo-only /data/bak/full_2019-06-26/

2. 整理合并周一增量到全备
[root@db01/data/bak]# 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 --redo-only --incremental-dir=/data/bak/inc2_2019-06-26 /data/bak/full_2019-02-26/

4. 再次整理全备
[root@db01/data/bak]# 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/bak]# chown -R mysql.mysql /data/*
[root@db01/data/bak]# systemctl start mysqld

三、企业备份恢复案例（XBK full_inc_binlog）

案例背景：某种小型互联网公司。 MySQL：5.7.26  CentOS：7.6
         数据量级600G，每日数量增加15—50M
备份策略：周日XBK全备+周一到周六inc增量+binlog备份，每天23：00进行。
故障描述：周三下午14时，数据由于某种原因数据损坏。
处理思路：
         1. 挂出维护页
         2. 评估一下数据损坏状态
             2.1 全部丢失--->直接推荐生产恢复
             2.2 部分丢失
         3. 整理合并所有备份：full+inc1+inc2
         4. 截取周二晚上到周三下午故障点的binlog日志
         5. 恢复全备，恢复binlog
         6. 检查数据完整性
         7. 恢复业务
处理结果：
         1. 经过70-80分钟处理，业务恢复
         2. 评估此次故障的处理的合理性和实用性
案例模拟：
1. 模拟周日全备
[root@db01/data/bak]# 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]# innobackup --user=root --password=123 --notimestamp --incremental --incremental-basedir=/data/bak/full /data/bak/inc1
4. 模拟周二的数据变化
mysql> use hisoss;
mysql> insert into his_order values(4),(5),(6);
mysql> commit;
5. 模拟周二数据的增量备份
[root@db01/data/bak]# innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/bak/full /data/bak/inc2
6. 模拟周三的数据变化
mysql> use hisoss;
mysql> insert into his_orser values(7),(8),(9);
mysql> commit;
7. 把数据库data目录rm掉
[root@db01/data/bak]# pkill mysqld
[root@db01/data/bak]# \rm -rf /data/mysql/data/*
8. 整理 合并备份
  (1) 整理全备
  [root@db01/data/bak]# innobackupex --apply-log --redo-only /data/bak/full
  (2) inc1合并到full中
  [root@db01/data/bak]# innobackupex --apply-log --incremental-dir=/data/bak/inc1 /data/bak/full
  (3) inc2合并到full中
  [root@db01/data/bak]# innobackupex --apply-log --incremental-dir=/data/bak/inc2 /data/bak/full
  (4)整体的整理
  [root@db01/data/bak]# innobackupex --apply-log /data/bak/full
9.恢复备份数据
[root@db01/data/bak]# cp -a /data/bak/full/* /data/mysql/data
[root@db01/data/bak]# chown -R mysql.mysql /data/*
10. 截取二进制日志并恢复
[root@db01/data/bak]# 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 root@10.0.0.52 " cat - > /data/mysql_backup.tgz"

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

四、MySQL数据迁移

4.0 迁移前要考虑的问题

技术方面：
选择什么工具？MDP XBK
非技术方面：
停机时间
回退方案

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

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成，浏览时请结合常识与多方信息审慎甄别。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

相关阅读更多精彩内容

友情链接更多精彩内容