开发者社区> 阿里云柳璃> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

RDS中的MYSQL备份恢复

简介:
+关注继续查看

RDS使用mysqldump对 MySQL 数据库进行逻辑全量备份,使用开源软件Xtrabackup进行物理全量备份,是实例级别的备份。

用户登录RDS控制台,可以下载备份文件。按照 利用逻辑备份文件恢复到自建数据库-MySQL利用物理备份文件恢复到自建数据库-MySQL中的操作步骤,实现数据的恢复。

本文主要从原理的角度来介绍MySQL数据库的备份和恢复,希望能让用户更加了解RDS的备份恢复机制。

 

一、备份类型介绍

1. 按备份操作方式:物理备份和逻辑备份

备份方式

优点

缺点

逻辑备份

1. 逻辑备份是可以用编译器或像grep和sed之类的命令查看和操作的普通文件;2. 恢复简单,非常灵活;3. 与存储引擎无关。 1. 还原时需要mysql加载和解释语句,转化为存储格式,并重建索引,所以会比较慢;2. 无法保证导出后再还原出来的一定是同样的数据。浮点数、软件BUG等都会导致问题;3. 必须由数据库服务器完成生成逻辑备份的工作,因此要使用更多的CPU周期。

物理备份

1. 基于文件的物理备份,只需要将需要的文件复制到其他地方即可完成备份;2. 恢复更简单;3. 恢复快,因为MySQL服务器不需要执行任何SQL或构建索引。 1. InnoDB的原始文件通常比相应的逻辑备份要大得多;2. 物理备份不总是可以跨平台、操作系统及MySQL版本。文件名大小写敏感和浮点格式可能会遇到麻烦。

2. 按是否备份全部数据:完全备份和增量备份

完全备份:备份全部需要备份的数据

增量备份:仅备份上次完全备份或增量备份以后变化的数据

 

二、使用Mysqldump进行逻辑备份恢复

1. 备份数据库

mysqldump作为重要的MySQL备份工具,功能相当强大。备份参数、恢复策略,需要仔细研究。

(1)基本语法

备份单个数据库或单个数据库中的指定表:

mysqldump [OPTIONS] database [tb1] [tb2]…

备份多个数据库:

mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...]

备份所有数据库:

mysqldump [OPTIONS] –all-databases [OPTIONS]

(2)选项[OPTIONS]说明

–default-character-set=charset

指定导出数据时采用何种字符集,如果数据表不是采用默认的 latin1 字符集的话,那么导出时必须指定该选项,否则再次导入数据后将产生乱码问题。

–lock-all-tables,-x

在开始导出之前,提交请求锁定所有数据库中的所有表,以保证数据的一致性。这是一个全局读锁,并且自动关闭 –single-transaction 和 –lock-tables 选项。

–lock-tables

和 –lock-all-tables 类似,不过是锁定当前导出的数据表,而不是锁定全部库下的表。本选项只适用于 MyISAM 表,如果是 Innodb 表可以用 –single-transaction 选项。

–no-create-info,-t

只导出数据,而不添加 CREATE TABLE 语句。

–no-data, -d

只导出数据库表结构,不导出任何数据。

–opt

这只是一个快捷选项,等同于同时添加 –add-drop-tables –add-locking –create-option –disable-keys –extended-insert –lock-tables –quick –set-charset 选项。本选项能让 mysqldump 很快的导出数据,并且导出的数据能很快导回。该选项默认开启,但可以用 –skip-opt 禁用。注意,如果运行 mysqldump 没有指定 –quick 或 –opt 选项,则会将整个结果集放在内存中。如果导出大数据库的话可能会出现问题。

–quick,-q

该选项在导出大表时很有用,它强制 mysqldump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。

–routines,-R

导出存储过程以及自定义函数。

–single-transaction

该选项在导出数据之前提交一个 BEGIN SQL语句,BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于事务表,例如 InnoDB 和 BDB。

本选项和 –lock-tables 选项是互斥的,因为 LOCK TABLES 会使任何挂起的事务隐含提交。
要想导出大表的话,应结合使用 –quick 选项。

–triggers

同时导出触发器。该选项默认启用,用 –skip-triggers 禁用它。

2.恢复数据库

RDS实现的是实例级别的逻辑备份,可以发现解压出来的都是实例里面各个数据库的sql文件。再执行数据库的导入操作:

mysql -hhostname -uusername -ppassword databasename < backupfile.sql

 

三、使用Xtrabackup进行物理备份恢复

Xtrabackup是由percona提供的mysql数据库备份工具,据官方介绍,这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。特点:

(1)备份过程快速、可靠;

(2)备份过程不会打断正在执行的事务;

(3)能够基于压缩等功能节约磁盘空间和流量;

(4)自动实现备份检验;

(5)还原速度快;

Xtrabackup中主要包含两个工具:

xtrabackup:是用于热备份innodb, xtradb表中数据的工具,不能备份其他类型的表,也不能备份数据表结构;

innobackupex:是将xtrabackup进行封装的perl脚本,可以备份和恢复MyISAM表以及数据表结构。

1.innobackupex工作原理

官方文档:http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/how_innobackupex_works.html

 

备份


如果在程序启动阶段未指定模式,innobackupex将会默认以备份模式启动。

默认情况下,此脚本以–suspend-at-end选项启动xtrabackup,然后xtrabackup程序开始拷贝InnoDB数据文件。当xtrabackup程序执行结束,innobackupex将会发现xtrabackup创建了xtrabackupsuspended2文件,然后执行FLUSH TABLES WITH READ LOCK,此语句对所有的数据库表加读锁,然后开始拷贝其他类型的文件。

如果–ibbackup未指定,innobackupex将会自行尝试确定使用的xtrabackup的binary。其确定binary的逻辑如下:首先判断备份目录中xtrabackup_binary文件是否存在,如果存在,此脚本将会依据此文件确定使用的xtrabackup binary。否则,脚本将会尝试连接database server,通过server版本确定binary。如果连接无法建立,xtrabackup将会失败,需要自行指定binary文件。

在binary被确定后,将会检查到数据库server的连接是否可以建立。其执行逻辑是:建立连接、执行query、关闭连接。若一切正常,xtrabackup将以子进程的方式启动。

FLUSH TABLES WITH READ LOCK是为了备份MyISAM和其他非InnoDB类型的表,此语句在xtrabackup已经备份InnoDB数据和日志文件后执行。在这之后,将会备份 .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, and .opt 类型的文件。

当所有上述文件备份完成后,innobackupex脚本将会恢复xtrabackup的执行,等待其备份上述逻辑执行过程中生成的事务日志文件。接下来,表被解锁,slave被启动,到server的连接被关闭。接下来,脚本会删掉xtrabackupsuspended2文件,允许xtrabackup进程退出。

 

恢复


为了恢复一个备份,innobackupex需要以–copy-back选项启动。

innobackupex将会首先通过my.cnf文件读取如下变量:datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir,并确定这些目录存在。

接下来,此脚本将会首先拷贝MyISAM表、索引文件、其他类型的文件(如:.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt files),接下来拷贝InnoDB表数据文件,最后拷贝日志文件。拷贝执行时将会保留文件属性,在使用备份文件启动MySQL前,可能需要更改文件的owener(如从拷贝文件的user更改到mysql用户)。

2. 使用innobackupex备份数据库

(1)完全备份:

innobackupex –user=root -p /home/backup/

备份后的文件:在备份的同时,备份数据会在备份目录下创建一个以当前日期时间为名字的目录存放备份文件。

11-1024x733-图片1

各文件说明:

(1) backup-my.cnf —— 备份命令用到的配置选项信息;

2 (1)--图片2

(2) ibdata —— 备份的表空间文件;

(3) xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件;

3 (1)--图片3

(4) xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置;

4-图片4

(5) xtrabackup_checkpoints —— 备份类型(如完全或增量)、备份状态(如是否已经为prepared状态)和LSN(日志序列号)范围信息;

5--图片5

(6) xtrabackup_logfile —— 备份的重做日志文件。

在使用innobackupex进行备份时,还可以使用–no-timestamp选项来阻止命令自动创建一个以时间命名的目录;如此一来,innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。

 

(2)准备(prepare)一个完全备份

一般情况下,在备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此,此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。

innobakupex命令的–apply-log选项可用于实现上述功能。

innobackupex –apply-log /home/backup/2014-05-03_17-21-11/

执行成功,显示如下:

图片6

在实现“准备”的过程中,innobackupex通常还可以使用–use-memory选项来指定其可以使用的内存的大小,默认通常为100M。如果有足够的内存可用,可以多划分一些内存给prepare的过程,以提高其完成速度。

 

3.恢复数据库

(1)模拟数据库损坏

直接使用删除数据目录文件来模拟损坏:

图片7

 

图片8

(2)还原完全备份:

innobackupex命令的–copy-back选项用于执行恢复操作,其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。

innobackupex –copy-back /home/backup/2014-05-03_17-21-11/

如果执行正确,其输出信息的最后几行通常如下:

图片9

 

(3)修改还原后的数据目录权限:

图片10

 

(4)启动MySQL

/bin/sh /usr/bin/mysqld_safe –defaults-file=/etc/my.cnf &

 

(5)连接数据库,验证还原后的数据

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云数据库RDS MySQL的数据安全预防与恢复
数据库往往是企业最为核心的数据保护对象,对数据库系统安全的保护,对数据库服务器和数据库中的数据、应用、存储的安全保护对企业来说至关重要,尽管我们用了很多技术手段,也很可能因为管理上的失误导致严重后果,我们需要用技术和管理组合手段,在数据库进行使用之前,就需要对敏感权限进行管控,确定使用环境的安全,并做好全面的预防措施;在数据库的使用过程中,更是需要谨慎操作,假设真的出了问题,还可以进行数据的恢复,以防止数据库系统及其数据遭到泄露、篡改或破坏。
3209 0
RDS for MySQL 5.7 备份恢复为本地实例
RDS for MySQL 5.7 备份恢复为本地实例详细步骤
509 0
RDS for mysql5.7 基础版本使用mysqldump 全量加增量恢复到本地
rds mysql 5.7基础版本无法下载物理备份,在业务不允许中断,并且本地数据库没有公网的情况下,如果要迁移数据到本地可以利用mysqldump 导出的dump 文件然后结合binlog 增量把rds数据迁移到本地。
1909 0
RDS for MySQL 5.7 备份恢复为本地实例
RDS for MySQL 5.7 备份恢复为本地实例详细步骤
7914 0
RDS for MySQL 字符序(collation)引发的性能问题
RDS for MySQL 字符序引发的 CPU 性能问题
3195 0
RDS for MySQL 字符序(collation)引发的性能问题
经常会遇到的 RDS 实例性能问题(比如 RDS 实例 CPU 使用率高),而其中有一类是由于字符集的字符排序规则不一致导致的。这类问题如何定位,如何解决?田杰带你来解决这类问题哦。
7439 0
RDS for MySQL 表上 Metadata lock 的产生和处理
RDS for MySQL 表上 Metadata lock 的产生和处理 1. Metadata lock wait 出现的场景 2. Metadata lock wait 的含义 3. 导致 Metadata lock wait 等待的活动事务 4. 解决方案
2797 0
281
文章
25
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载