MySQL备份与恢复
第1章 关于备份的概念
1.1 为什么要进行备份?
备份是数据安全的最后一道防线,对于任何数据丢失的场景,备份虽然不一定能恢复百分之百的数据(这主要取决于备份的周期),但至少能尽量将损失降到最低,衡量备份的恢复有两个重要的指标:恢复点目标(RPO)和恢复时间目标(RTO),前者关注能恢复到什么程度,后者关注恢复需要多长时间
1.2 mysql备份的类型:
1.2.1 热备份:
不影响业务的正常工作,在工作的过程中,进行备份,这些动态备份在读取或修改数据的过程中进行,很少中断或者不中断传输或处理数据,使用热备份时,系统仍可供读取和修改数据的操作访问
1.2.2 冷备份:
关闭数据库之后进行备份,这个备份在用户不能访问数据时进行,因此无法读取或修改数据,这些脱机备份会阻止任何使用数据的活动,这些类型的备份不会干扰正常运性的系统的性能,但是对于某些应用程序,会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据
1.2.3 温备份:
这些备份在读取数据时进行,但在多数情况下,在进行备份时不能修改数据本身,这种中途备份类型的优点是不必完全锁定最终用户,但缺点是无法在进行备份时修改数据集,这可能使这种类型的备份不适用于某些应用程序,在备份过程中无法修改数据可能产生性能问题
1.3 主要的备份方式:
物理备份--->使用sql语句
逻辑备份--->数据文件的二进制副本
增量备份--->备份二进制日志文件,可以后恢复到任意时间点的数据
1.4 备份的工具:
1. mysqldump : mysql自带的逻辑备份工具
2. mysqlbinlog : 实现binlog备份的自带命令
3. xtrabackup : precona公司开发的性能很高的物理备份工具
第2章 逻辑备份工具:
2.1 mysqldump :就是将库和表的创建语句以及insert语句以文本的形式备份出来
musqldump命令参数:
注意:mysqldump在备份需要依赖SQL层进行解析,因此mysql服务在关闭时,无法进行备份
2.1.1 企业标准备份语句示例:
mysqldump -uroot -p123 -A -R --triggers --master-data=2 >/bak/full.sql|gzip >/bak/all_$(date +%F).sql.gz
[root@db01 bak]# ll
total 2272
-rw-r--r-- 1 root root 20 Apr 9 09:11 all_2018-04-09.sql.gz
-rw-r--r-- 1 root root 2319228 Apr 9 09:11 full.sql
2.1.2 --master-data=2 参数表示在备份后,记录binlog文件中的时间节点
2.1.3 --single-transaction
对innoDB引擎进行热备,支持innoDB引擎,使用该参数会单独开启一个事务进行备份,利用事务的快照技术实现,基于事务引擎处理,不用锁表就可以获得一致性的备份,体现了ACID四大事务特性中的隔离性,生产中99%使用innoDB事务引擎
虽然支持热备,并不意味着你可以任意时间点进行备份,特别是业务繁忙期,不建议做备份策略,一般备份都是在夜间
2.1.4 --flush-log/F 参数表示刷新binlog日志
2.1.5 -B 参数在备份时,会加入create和use语句,恢复时不需要创建数据库即可
2.2 利用mysqldump备份进行恢复实战
1. 对jiang数据进行备份:
mysqldump -uroot -p123 -B -R --triggers --master-data=2 jiang|gzip >/tmp/all_$(date +%F).sql.gz
2. 故障模拟,删除jiang数据库
mysql> drop database jiang;
Query OK, 2 rows affected (0.27 sec)
3. 使用gzip解压备份文件
[root@db01 tmp]# gzip -d all_2018-04-10.sql.gz
[root@db01 tmp]# ll
total 656
-rw-r--r-- 1 root root 2552 Apr 10 04:36 all_2018-04-10.sql
4. 导入备份文件
mysql> set sql_log_bin=0;
mysql> source /tmp/all_2018-04-10.sql
5. 检查数据
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| jiang |
| mysql |
| performance_schema |
| test |
+--------------------+
2.2.1 mysqlbinlog:配合备份工具使用:
mysqlbinlog --start-position --stop-position
1. 配合备份工具达到增量备份
2. 可以每周进行一次全备,记录二进制日志时间点以后,对二进制日志进行备份
第3章 生产案例一:
3.1 企业案例:
公司网站数据:一共25G,每天更改量(binlog)100M
3.1.1 故障原因:
磁盘扩容,误格式化数据磁盘
数据库系统异常断电,导致磁盘数据文件损坏.ibd
故障演练,模拟损坏
3.1.2 恢复思路:
1. 关闭所有和故障数据库有关的业务,防止二次伤害
2. 在测试库上恢复昨天的全备,追加备份时间到故障时间的binlog日志
3. 检验数据没问题后,将测试库数据导出,导入生产库
4. 重新开启业务
3.1.3 项目结果:
经过30分钟的时间,业务恢复正常
3.2 模拟案例:
周一23:00全备
mysqldump -uroot -p123 -A -R --triggers --master-data=2 >/bak/full.sql|gzip >/bak/all_$(date +%F).sql.gz
周二发生业务:
use world
update city set countrycode='CHN' where countrycode='JPN';
commit;
delete from city where countrycode ='USA';
commit;
delete from city where countrycode <> 'CHN';
commit;
delete from city where name='tokyo';
commit;
发生故障,要求恢复数据到tokyo删除之前的状态
3.2.1 具体步骤:
1. 找到备份数据,进行解压:
[root@db01 bak]# gunzip all_2018-04-09.sql.gz
[root@db01 bak]# ll
total 2268
-rw-r--r-- 1 root root 0 Apr 9 09:11 all_2018-04-09.sql
-rw-r--r-- 1 root root 2319228 Apr 9 09:11 full.sql
2. 暂时关闭无用binlog日志
mysql> set sql_log_bin=0;
导入全备的文件
source full.sql
查看当前使用的binlog文件:
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000039 | 1889100 | | | |
+------------------+----------+--------------+------------------+-------------------+
截取二进制日志文件:
mysqlbinlog –start-position= --stop-position=
第4章 生产案例二:
4.1 背景环境:
正在运行的网站系统,mysql数据库数据量25G,日业务量10-15M(读多写少)
4.1.1 备份方式:
每天晚上11点,定时任务调用mysqldump执行全备脚本
4.2 故障时间:周二上午10点
原因:数据库系统异常断电,导致磁盘数据文件损坏
故障模拟:
第5章 xtrbackup
5.1 xtrabackup是什么?
percona公司的备份工具,性能比较高,是物理备份工具
5.2 xtrabackup工具的优缺点:
5.2.1 优点:
1. 物理备份工具,在同级数据量基础上,都要比逻辑备份性能好很多
2. 特别是在数据量比较大的时候,体现更加明显
5.2.2 缺点:
准备和数据库数据所占空间大小对等的备份空间
5.3 xtrabackup的备份方式:
1. 拷贝数据页文件
2. 拷贝数据文件
3. 事务日志
5.4 备份原理:
5.4.1 对于innoDB表,可以实现热备
1. 在数据还有修改操作的时候,直接将数据文件备份走,此时,备份走的数据对于当前mysql来讲是不一致的
2. 将备份过程中的redo和undo一并备走
3. 为了恢复的时候,只要保证备份出来的数据页lsn和redo lsn进行匹配,将来恢复的就是一致的数据,redo和undo应用
5.4.2 myisam表,实现自动锁表拷贝文件
备份开始时首先会开启一个后台检测进程,实时检测mysql redo变化,一旦发现有新的日志写入,立刻将日志记入后台日志文件xtrabackup_log中,之后复制innoDB的数据文件,系统表空间文件ibdatax,复制结束后,将执行flush tables with readlock,然后复制.frm MYI MYD等文件,最后执行unlock tables,最终停止xtrabackup_log
第6章 xtrabackup使用
6.1.1 安装xtrabackup
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL
yum -y install percona-xtrabackup
6.1.2 全备命令:
默认按照时间戳生成:
innobackupex --user=root --password=123 /bak/
指定生成备份集的名字
innobackupex --user=root --password=123 --no-timestamp /backup/full
6.2 恢复的过程
故障模拟:删除全部数据文件 并关闭服务
rm –rf /application/mysql/data*
pkill mysqld
6.2.1 准备恢复:
作用:将备份过程中commit事务,进行重做并且合并到备份中,将未提交的事务进行回滚,最终目的是lsn=redo lsn
innobackupex --apply-log /backup/full/
6.2.2 恢复方法一:
cp -a * /application/mysql/data/
chown -R mysql.mysql /application/mysql/data/
6.2.3 恢复方法二:推荐
innobackupex --copy-back /backup/full/
chown -R mysql.mysql /application/mysql/data/
第7章 xtrabackup的增量备份:
7.1 如何备份?
7.1.1 首先要有一次全备的备份集,作为基点
innobackupex --user=root --password=123 --no-timestamp /backup/full
备份后,数据库的数据并不是一成不变的,所以在一定时间后还要进行增量的备份,即只对变化的数据页进行备份,即增量备份
7.1.2 模拟数据页的变化:
mysql> use jiang
mysql> create table t1(id int);
mysql> insert into t1 values (1),(2),(3);
mysql> select *from t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)
mysql> commit;
7.1.3 第一次增量备份:
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/full/ /backup/inc1
7.1.4 模拟数据页变化:
mysql> insert into t1 values(5),(6),(7);
mysql> select * from t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 5 |
| 6 |
| 7 |
+------+
mysql> commit;
7.1.5 第二次增量备份:
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/inc1/ /backup/inc2
7.1.6 模拟故障:
rm –rf /application/mysql/data/*
7.2 如何恢复?
7.2.1 关闭mysql服务:
pkill mysqld
7.2.2 应用日志到全备
innobackupex --apply-log --redo-only /backup/full/
7.2.3 合并第一次增量备份到全备集中:一致性的合并
innobackupex --apply-log --redo-only --incremental-dir=/backup/inc1 /backup/full/
7.2.4 合并第二次增量备份到全备集中:一致性的合并
innobackupex --apply-log --incremental-dir=/backup/inc2 /backup/full/
7.2.5 整体进行合并:
innobackupex --apply-log /backup/full
7.2.6 恢复备份:
innobackupex --copy-back /backup/full/
chown -R mysql.mysql /application/mysql/data/
7.2.7 启动数据库:
/etc/init.d/mysqld start
7.2.8 进入数据库,暂时关闭binlog日志,因为后面的sql语句是不需要记录的
mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
7.2.9 查看备份文件中记录事务的节点信息:
cat xtrabackup_binlog_info
mysql-bin.000019 920
7.2.10 将二进制日志内容导出
mysqlbinlog --start-position=920 /data/mysql/mysql-bin.000019 >/tmp/binsql.bak
7.2.11 在数据库中导入文件内容
mysql> source /tmp/binsql.bak
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected, 1 warning (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
7.2.12 查看数据是否恢复
mysql> select * from t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 11 |
| 22 |
| 33 |
| 55 |
| 66 |
| 77 |
+------+