标签：备份与恢复

第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 |

+------+

MySQL备份与恢复

标签：备份与恢复

原文地址：http://blog.51cto.com/13520772/2109329