1、备份类型

1.1、热备

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

1.2、温备

 

锁表备份,只能查询不能修改(myisam)
影响到写入操作

1.3、冷备

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

2. 备份方式及工具介绍

2.1 逻辑备份工具

基于SQL语句进行备份
mysqldump      
mysqlbinlog  

 

2.2 物理备份工具

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

 

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

3.1 mysqldump (MDP)

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

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

 

3.2 xtrabackup(XBK)

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

4.备份策略

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

 

5.备份工具使用-mysqldump

5.1 mysqldump (逻辑备份的客户端工具)

5.1.1 客户端通用参数

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

 

5.1.2 备份专用基本参数

-A 全备参数

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

 

-B db1 db2 db3 备份多个单库

说明:生产中需要备份,生产相关的库和MySQL库
mysqldump -B mysql gtid --set-gtid-purged=OFF >/data/backup/b.sql 

 

备份单个或多个表

mysqldump -uroot -p world city country >/backup/bak1.sql
以上备份恢复时:必须world库事先存在,并且ues才能source恢复

 

5.1.3 高级参数应用

特殊参数1使用(必须要加)

-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

功能:
(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表可以实现自动锁表功能
例子: 备份必加参数
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=256M

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

 --max-allowed-packet=# 
调整数据包大小,备份数据少可以忽略

 

5.3. 压缩备份并添加时间戳

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

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

mysqldump备份的恢复方式(在生产中恢复要谨慎,恢复会删除重复的表)
set sql_log_bin=0;
source /backup/full_2018-06-28.sql

注意:
1、mysqldump在备份和恢复时都需要mysql实例启动为前提。
2、一般数据量级100G以内,大约15-45分钟可以恢复,数据量级很大很大的时候(PB、EB)
3、mysqldump是覆盖形式恢复的方法。

一般我们认为,在同数据量级,物理备份要比逻辑备份速度快.
逻辑备份的优势:
1、可读性强
2、压缩比很高

 

6. 备份时优化参数:

(1) max_allowed_packet   最大的数据包大小

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

(2) 增加key_buffer_size    (临时表有关)
(3) 架构分离,分别备份      (架构拆分,分布式备份)

 

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

10.1安装

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

 

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

 

10.2、备份命令介绍:

xtrabackup
innobackupex 

 

10.3 备份方式——物理备份

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

 

面试题: xbk 在innodb表备份恢复的流程

  0、xbk备份执行的瞬间,立即触发ckpt,已提交的数据脏页,从内存刷写到磁盘,并记录此时的LSN号
  1、备份时,拷贝磁盘数据页,并且记录备份过程中产生的redo和undo一起拷贝走,也就是checkpoint LSN之后的日志
  2、在恢复之前,模拟Innodb“自动故障恢复”(CSR)的过程,将redo(前滚)与undo(回滚)进行应用
  3、恢复过程是cp 备份到原来数据目录下

 

10.4、innobackupex使用

10.4.1 全备

 innobackupex --user=root --password=123  --host=127.0.0.1 /data/backup

自主定制备份路径名

innobackupex --user=root --password=123 --host=127.0.0.1 --no-timestamp /data/backup/full

 

备份集中多出来的文件:

xtrabackup_binlog_info
xtrabackup_checkpoints
xtrabackup_info
xtrabackup_logfile

xtrabackup_binlog_info :(备份时刻的binlog位置)
cat xtrabackup_binlog_info 
mysql-bin.000003    536749
79de40d3-5ff3-11e9-804a-000c2928f5dd:1-7
记录的是备份时刻,binlog的文件名字和当时的结束的position,可以用来作为截取binlog时的起点。

xtrabackup_checkpoints :
backup_type = full-backupedz 全备
from_lsn = 0            上次所到达的LSN号(对于全备就是从0开始,对于增量有别的显示方法)
to_lsn = 160683027      备份开始时间(ckpt)点数据页的LSN    
last_lsn = 160683036    备份结束后,redo日志最终的LSN
compact = 0
recover_binlog_info = 01)备份时刻,立即将已经commit过的,内存中的数据页刷新到磁盘(CKPT).开始备份数据,数据文件的LSN会停留在to_lsn位置。
(2)备份时刻有可能会有其他的数据写入,已备走的数据文件就不会再发生变化了。
(3)在备份过程中,备份软件会一直监控着redo的undo,如果一旦有变化会将日志也一并备走,并记录LSN到last_lsn。
从to_lsn  ----》last_lsn 就是,备份过程中产生的数据变化.

 

10.4.2 全备的恢复

准备备份(Prepared)

将redo进行重做,已提交的写到数据文件,未提交的使用undo回滚掉。模拟了CSR的过程
 innobackupex --apply-log  /backup/full

恢复备份

前提:
1、被恢复的目录是空  rm -rf /data/mysql/data/*
2、被恢复的数据库的实例是关闭
systemctl stop mysqld

数据授权

chown -R mysql.mysql /data/mysql/data

恢复备份

cp -a /backup/full/* /data/mysql/data/

 

启动数据库

 

10.4.3 innobackupex 增量备份(incremental)

1)增量备份的方式,是基于上一次备份进行增量。
(2)增量备份无法单独恢复。必须基于全备进行恢复。
(3)所有增量必须要按顺序合并到全备中。

 

增量备份命令

1)删掉原来备份
略.
(2)全备(周日)
[root@db01 backup]# innobackupex --user=root --password --no-timestamp /backup/full >&/tmp/xbk_full.log
(3)模拟周一数据变化

(4)第一次增量备份(周一)
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/full  /backup/inc1 &>/tmp/inc1.log
(5)周二增量
 innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/inc1  /backup/inc2  &>/tmp/inc2.log
(7)模拟周三数据变化

 

恢复到周三误drop之前的数据状态

恢复思路:
1.  挂出维护页,停止当天的自动备份脚本
2.  检查备份:周日full+周一inc1+周二inc2,周三的完整二进制日志
3. 进行备份整理(细节),截取关键的二进制日志(从备份——误删除之前)
4. 测试库进行备份恢复及日志恢复
5. 应用进行测试无误,开启业务
6. 此次工作的总结

 

恢复过程

1. 检查备份
2. 备份整理(apply-log)+合并备份(full+inc1+inc2)
(1) 全备的整理
 innobackupex --apply-log --redo-only /data/backup/full
(2) 合并inc1到full中,加上redo-only 只前滚,最后一次合并不用加
innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc1 /data/backup/full
(3) 合并inc2到full中,最后一次不用加
innobackupex --apply-log  --incremental-dir=/data/backup/inc2 /data/backup/full
(4) 最后一次整理全备
 innobackupex --apply-log  /data/backup/full
(5)复制数据页
 cp -a /backup/full/*   /data/mysql/data
chown -R mysql.mysql /data/*