返回顶部

备份恢复

在备份恢复中的职责

备份策略的设计

(1) 备份周期:

  • 根据数据量.

(2)备份工具:

  • mysqldump (MDP) , XBK (PBK) percona Xtrabackup , MEB(MySQL Enterprise BACKUP MEB) ,mysqlbinlog

(3)备份方式:

  • 全备 mysqldump

  • 增量 binlog (flush logs ,cp) flush logs刷一下把生成的binlog文件拷走即可

  • 物理备份:

  • 全备 : XBK

  • 增量 : XBK

检查备份可用性

  • crontab -l -----> 定时任务检查

  • 备份脚本 检查

  • 备份路径 --查看备份路径

  • 看备份日志,检查备份文件(大小,内容)

定期的恢复演练

  • 一季度或者半年

数据迁移

  • 1. 停机时间 2. 回退方案

备份类型

  • 热备 : 对于业务影响最小 InnoDB

  • 温备 : 长时间锁表备份 MyISAM

  • 冷备 : 业务关闭情况下备份

备份方式及工具介绍

逻辑备份工具 

基于SQL语句进行备份
mysqldump       *****
mysqlbinlog     *****

物理备份工具

基于磁盘数据文件备份
xtrabackup(XBK) :percona 第三方   *****
MySQL Enterprise Backup(MEB)

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

mysqldump (MDP)

优点:
1.不需要下载安装
2.备份出来的是SQL,文本格式,可读性高,便于备份处理
3.压缩比较高,节省备份的磁盘空间

缺点:
4.依赖于数据库引擎,需要从磁盘把数据读出
然后转换成SQL进行转储,比较耗费资源,数据量大的话效率较低
建议:
100G以内的数据量级,可以使用mysqldump
超过TB以上,我们也可能选择的是mysqldump,配合分布式的系统
1EB  =1024 PB =1000000 TB

 xtrabackup(XBK)

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

备份策略

备份方式:
全备:全库备份,备份所有数据
增量:备份变化的数据
逻辑备份=mysqldump+mysqlbinlog
物理备份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog
备份周期:
根据数据量设计备份周期
比如:周日全备,周1-周6增量

备份工具使用-mysqldump

连接数据库

  • -u  

  • -p

  • -S

  • -h

  • P

本地备份:
mysqldump -uroot -p  -S /tmp/mysql.sock
远程备份:
mysqldump -uroot -p  -h 10.0.0.51 -P3306

备份专用基本参数

-A 全备参数

mysqldump -uroot -p123 -A  >/backup/full.sql

 单机去除警告信息(只限于单机使用,主从不可以使用

# 1.常规备份是要加 --set-gtid-purged=OFF,解决备份时的警告
# [root@db01 ~]# mysqldump -uroot -p123 -A  --set-gtid-purged=OFF  >/backup/full.sql
# 2.构建主从时,做的备份,不需要加这个参数
# [root@db01 ~]# mysqldump -uroot -p123 -A    --set-gtid-purged=ON >/backup/full.sql

-B db1 db2 db3 备份指定的多个数据库

mysqldump -uroot -p123 -B world oldguo wordpress >/backup/db.sql

备份指定的单个或多个表(备份world库中的city和country两个表)

mysqldump -uroot -p123 world city country > /backup/tab.sql

特殊备份参数使用必须要加的

  • -R 备份存储过程及函数

  • --triggers 备份触发器

  • -E 备份事件

mysqldump -uroot -p -A -R -E --triggers >/data/backup/full.sql

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

mysqldump -uroot -p  -A  -R --triggers -F >/bak/full.sql

--master-data=2(重点

以注释的形式,保存备份开始时间点的binlog的状态信息

mysqldump -uroot -p  -A  -R --triggers --master-data=2   >/back/world.sql
[root@db01 ~]# grep 'CHANGE' /backup/world.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=194;

功能:
(1)在备份时,会自动记录,二进制日志文件名和位置号
0 默认值
1  以change master to命令形式,可以用作主从复制
2  以注释的形式记录,备份时刻的文件名+postion号
(2) 自动锁表
(3)如果配合--single-transaction,只对非InnoDB表进行锁表备份,InnoDB表进行“热“”备,实际上是实现快照备份。

--single-transaction

innodb 存储引擎开启热备(快照备份)功能       
master-data可以自动加锁
(1)在不加--single-transaction ,启动所有表的温备份,所有表都锁定
(1)加上--single-transaction ,对innodb进行快照备份,对非innodb表可以实现自动锁表功能
例子6: 备份必加参数
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

--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:在构建主从复制环境时需要的参数配置
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

--max-allowed-packet=# 

  • 控制的是备份时传输数据包的大小
mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF --max-allowed-packet=256M >/data/backup/full.sql

备份恢复案例

背景环境

  • 正在运行的网站系统,mysql-5.7.20 数据库,数据量50G,日业务增量1-5M

备份策略

  • 每天23:00点,计划任务调用mysqldump执行全备脚本

故障时间点

  • 年底故障演练:模拟周三上午10点误删除数据库

思路

  • 1、停业务,挂维护页,避免数据的二次伤害

  • 2、找一个临时库,恢复周二23:00全备

  • 3、截取周二23:00 --- 周三10点误删除之间的binlog,恢复到临时库

  • 4、测试可用性和完整性

  • 5.1 方法一:直接使用临时库顶替原生产库,前端应用割接到新库

  • 5.2 方法二:将误删除的表导出,导入到原生产库

故障模拟演练

先清除干扰数据

rm -rf /backup/*

准备数据

create database backup;
use backup
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

模拟周二 23:00全备

mysqldump -uroot -p123 -A  -R  --triggers --set-gtid-purged=OFF --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

模拟周二 23:00到周三 10点之间数据变化

use backup
insert into t1 values(11),(22),(33);
commit;
create table t2 (id int);
insert into t2 values(11),(22),(33);
commit;

模拟故障,删除库(只是模拟,不代表生产操作)

drop database backup;

恢复过程

准备临时数据库(多实例3307)

systemctl status mysqld3307

准备备份

cd /backup
gunzip full_2018-10-14.sql.gz 

截取二进制日志

检索 MASTER_LOG_POS 起始位置

 查看结束位置

show master status;
show binlog events in 'mysql-bi.000001';

 截取binlog日志

mysqlbinlog --skip-gtids   --start-position=753 --stop-position=1519  /data/binlog/mysql-bi.000001 >/backup/bin.sql

恢复备份到临时库

mysql -S /data/3307/mysql.sock

source /backup/full_2020-03-05.sql
source /backup/bin.sql

将故障表导出并恢复到生产

mysqldump   -S /data/3307/mysql.sock -B  backup  >/backup/bak.sql
# 3306数据库操作
set sql_log_bin=0;
source /backup/bak.sql;
set sql_log_bin=1;

物理备份 xtrabackup(XBK、Xbackup)

安装依赖包

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

下载软件并安装

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

备份核心理念

  • (1) 非InnoDB表,进行短暂的锁表,然后Copy数据文件

  • (2) 对于InnoDB表,立即出发checkpoint,会立即记录一个LSN,COPY数据文件.

  • (3) 将备份过程中产生的redo进行截取和保存,并记录此时最新的LSN

全备份过程

innobackupex  --socket=/tmp/mysql.sock --user=root --password=123 --no-timestamp /data/backup/full

备份产生的文件介绍

  • (1) xtrabackup_binlog_info *****

  • 记录备份时刻的二进制日志信息. 可以作为binlog截取的起点.

  • (2) xtrabackup_checkpoints *****

  • from : 备份中包含的LSN号的起点,全备:0,增量:上次备份的结束位置

  • to : ckpt 时的LSN

  • last-9 : 备份结束时的LSN.下次增量备份的起始位置

利用全备进行恢复

1. 
[root@db01 ~]# pkill mysqld
2. 
[root@db01 ~]# \rm -rf /data/mysql/data/*
3. *****
[root@db01 ~]# innobackupex --apply-log --redo-only /data/backup/full
4. 
[root@db01 full]#cp -a /data/backup/full/* /data/mysql/data/
5. 
[root@db01 full]# chown -R mysql.mysql /data/mysql/data/*
6. 
[root@db01 full]# /etc/init.d/mysqld start

增量备份 innobackupex

清空备份路径

\rm -rf /backup/*

模拟数据

create database full charset utf8mb4;
use full;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

进行周日的全备

innobackupex --user=root --password=123 -S /tmp/mysql.sock --no-timestamp /backup/full

模拟周一的数据变化

create database inc1 charset utf8mb4;
use inc1;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

进行周一的增量备份

说明:

  • --incremental 开关

  • --incremental-basedir=/backup/full 基于哪个备份进行增量

  • /backup/inc1 增量备份的位置点

innobackupex   --user=root --password=123 -S /tmp/mysql.sock --no-timestamp --incremental --incremental-basedir=/backup/full /backup/inc1

检查备份的LSN

cat /backup/full/xtrabackup_checkpoints 
cat /backup/inc1/xtrabackup_checkpoints  

模拟周二数据变化

create database inc2 charset utf8mb4;
use inc2;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

进行周二的增量备份 

innobackupex   --user=root --password=123 -S /tmp/mysql.sock --no-timestamp --incremental --incremental-basedir=/backup/inc1 /backup/inc2 

 模拟周三数据变化

create database inc3 charset utf8mb4;
use inc3;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;

进行周三的增量备份   

innobackupex   --user=root --password=123 -S /tmp/mysql.sock --no-timestamp --incremental --incremental-basedir=/backup/inc1 /backup/inc3

模拟上午10点数据库崩溃

# 停止mysql
pkill mysqld 
\rm -rf /data/mysql/data/*

恢复前的准备

(1) 整理full
innobackupex --apply-log --redo-only  /backup/full

(2) 合并inc1到full,并整理备份
innobackupex --apply-log --redo-only  --incremental-dir=/backup/inc1 /backup/full 

(3) 合并inc2到full,并整理备份 
innobackupex --apply-log  --incremental-dir=/backup/inc2 /backup/full 

(4) 最后一次整理full
innobackupex --apply-log  /backup/full

 截取二进制日志

起点:

cat /backup/inc2/xtrabackup_binlog_info

终点:  mysql-bin.000031 最后一个gtid号

mysqlbinlog /data/binlog/mysql-bi.000002 |grep 'SET'

 截取

mysqlbinlog --skip-gtids --include-gtids='e0b63073-5efd-11ea-9d00-00163e09c1f2:10-12' /data/binlog/mysql-bi.000002>/backup/binlog.sql

恢复备份数据

cp -a  /backup/full/* /data/mysql/data/
chown -R mysql. /data/
systemctl start mysqld
mysql> set sql_log_bin=0;
mysql> source /backup/binlog.sql
show databases;
set sql_log_bin=1;

验证数据

案例

备份集中单独恢复表

drop table city;
create table city like city_bak;
alter table city discard tablespace;
cp /backup/full/world/city.ibd  /application/mysql/data/world/
chown -R mysql.mysql  /application/mysql/data/world/city.ibd 
alter table city import  tablespace;

从mysqldump 全备中获取库和表的备份

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

msyql低版本向高版本迁移案例

搭建5.6的测试环境

创建必须的目录

mkdir /data/mysql/data  -p 
mkdir /application/ -p
mkdir /data/binlog -p

上传软件至 /application 下并解压

(2) 建用户,改权限

useradd mysql
chown -R mysql. /data /application/

(3) 修改环境变量

vim /etc/profile
export PATH=/application/mysql/bin:$PATH
source /etc/profile

数据初始化

yum remove mariadb-libs
yum install -y libaio-devel
\rm -rf /data/mysql/data/*
/application/mysql/scripts/mysql_install_db --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data

准备配置文件和启动脚本

配置文件  

cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql 
datadir=/data/mysql/data 
server_id=99
user=mysql
log_bin=/data/binlog/mysql-bin
binlog_format=row
socket=/tmp/mysql.sock 
[mysql]
socket=/tmp/mysql.sock
EOF

systemctl启动mysql配置 

cp  /application/mysql/support-files/mysql.server /etc/init.d/mysqld

启动数据库

/etc/init.d/mysqld start
mysqladmin -uroot -p password 123

迁移5.6 数据到 5.7

(1) 5.6 数据库备份

mysqldump -uroot -p123 -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql
scp /tmp/full.sql 10.0.0.51:/data/3308 

(2)准备5.7数据库

[root@db01 /]# systemctl start mysqld3308
[root@db01 /]# mysql -S /data/3308/mysql.sock
mysql> source /data/3308/full.sql
[root@db01 /]# mysql_upgrade  -uroot -p123 -S /data/3308/mysql.sock
(3) binlog的持续追加
(4) 停业务,恢复剩余的binlog
(5) 业务割接

 

posted @ 2020-03-05 14:51  Crazymagic  阅读(271)  评论(0编辑  收藏  举报