mariadb常用备份与还原工具介绍

三、常见的备份工具

mariadb本身为我们提供了mysqldump、mysqlbinlog备份工具，percona也为我们提供了强大的Xtrabackup，加上开源的mydumper，还有基于主从同步的延迟备份、从库冷备等方式，以及基于文件系统快照的备份，其实将这些方式合理搭配已经能够满足我们的需要了。而备份本身是为了恢复，所以能够让我们在出现故障后迅速、准确恢复的备份方式，就是最适合我们的，当然，同时能够省钱、省事，那就非常完美。下面就几种备份工具进行一些比较，探讨下它们各自的适用场景，及简单的使用做一下说明

1、mysqldump

⑴、mysqldump优缺点

mysqldump是最简单的逻辑备份方式（工作方式单线程）。在备份myisam表的时候，如果要得到一致的数据，就需要锁表，简单而粗暴。而在备份innodb表的时候，加上–master-data=2 –single-transaction 选项，在事务开始时刻，记录下binlog-pos点，然后利用mvcc（多版本并发控制）来获取一致的数据，由于是一个大事务，在写入和更新量很大的数据库上，将产生非常多的undo，显著影响性能，所以要慎用。

优点：简单，可针对单表备份，在完全导出表结构的时候尤其有用。可以做到对不同的存储引擎进行备份（InnoDB热备、MyISAM温备、Aria温备）

缺点：简单粗暴，单线程，备份慢而且恢复，不支持差异或增量备份，如果要进行差异或增量备份要结合binlog日志文件

mydumper是mysqldump的加强版。相比mysqldump：

内置支持压缩，可以节省2-4倍的存储空间。

支持并行备份和恢复，因此速度比mysqldump快很多，但是由于是逻辑备份，仍不是很快，如果要进行差异或增量备份要结合binlog日志文件

部分备份工具

SELECT clause INTO OUTFILE '/path/to/somefile'

逻辑备份工具，快于mysqldump。

⑵、mysqldump命令介绍及简单使用

①命令介绍

mysqldump [options] [db_name [tbl_name ...]]

备份单个库：

mysqldump [options] db_name

恢复时：如果目标库不存在，需要事先手动创建

options说明

注意

备份部分

mysqldump+二进制日志文件；

②、实例

要求如下：

③解决方案（此方法不唯一）

备份阶段

第一步，先远程登录到数据库上，事先看一下现有的数据库。

由上图可见，除了hellodb数据库，其它的数据库都是系统自带的，看一下hellodb中有那些表，及当前binlog日志的记录的位置。

由于当前数据库只有一个用户数据库，所以我们在乎其表的存储引擎来判断使用什么方式来备份。（是申请锁或是单事务）

查看表状态发现hellodb中的表全部都是MyISAM的存储引擎，那么就可以使用申请全局锁来备份了。

这时数据库全部备份完毕（此方法只适用于数据量不是很大，挑选一个相对并发的写请求不是特别多的时间或午夜备份。如果数据量特别大，此方法将不做参考范围）。

假如在这之后我们又在原来的库中建立新的表或插入数据，而在某一次我误操作删除了此数据库。将如何恢复？

由上图可见，原来的hellodb数据库中多了一张表，为不演示恢复效果我将hellodb删除，看怎么样恢复

现在hellodb己经删除，看如何恢复。

恢复部分

第一步，将服务器离线，导出现在正在使用的binlog日志，还原之前的完全备份

查看完全备份中binlog日志的起始位置。

将此日志中到删除数据库drop database hellodb之前的数据导出到存放起来，以供时间点还原之用

登录数据库

注：此时要临时关闭二进制日志，关闭其它用户连接；

导入之前的备份　

查看数据库中的表，里面没有我们备份之后建立的表，这时就用到了之前备份的binlog日志了

导入binlog日志，完全恢复数据。

这回数据就完整了。

附上一个基于mysqldump简单复制单库的myisam的脚本

2. 基于文件系统的快照

基于文件系统的快照，是物理备份的一种。在备份前需要进行一些复杂的设置，在备份开始时刻获得快照并记录下binlog pos点，然后采用类似copy-on-write的方式，把快照进行转储。转储快照本身会消耗一定的IO资源，而且在写入压力较大的实例上，保存被更改数据块的前印象也会消耗IO，最终表现为整体性能的下降。而且服务器还要为copy-on-write快照预留较多的磁盘空间，这本身对资源也是一种浪费。因此这种备份方式在生产环境使用的不多。

注：

当刚为数数据文件所在的卷（源卷）创建快照时，此时的快照卷是空的。

当源卷中的数据发生变化后，则将发生变化的那部分数据复制到快照卷上，此时通过快照访问则是未发生变化的数据来自于源卷，变化后的数据来自于快照卷。

快照不是备份，它是仅是提供访问文件的一条通路，当源卷变化的量超出快照卷的大小时，快照卷将崩溃失效。

实例

前提：

首先，mariadb的数据文件在逻辑卷上，如果使用的是支持事务的存储引擎的话，那么要将事务日志与数据文件放在同一个卷上，这样才能保证数据的完整性。

看一下数据文件的属性

步骤：

备份部分

第一步，如果对源卷创建快照，那么首先要对数据库申请全局锁，滚动二进制日志，记录二进制日志位置标记

⑴、申请全局锁

将此二进制日志信息记录下来

此时可以创建快照了

第二步，创建完快照后解锁

当快照卷创建完成后，可以对数据库解锁（创建锁与解锁必须是同一会话，也就是说，当创建完锁之后，这个会话不可退出，之后还要在这个会话中对数据库解锁，一但退出，此会话的全局锁将失效）

这时数据库又可以正常进行写入操作了

第三步，备份快照

挂载备份之后的快照

复制快照中的内容

删除快照卷

里源卷的数据库employees中添入一些数据。

当备份过完成后，过了几个小时，数据库误删除了一些数据，这时就可用到此次完全备份与即时点还原日志。

还原部分

第一步，停止数据库服务，将备份后的数据中的某一张表或整个库替换此数据库中误删除的表或整个库。

替换　

注：此时文件的属性要与原文件的一致

第二步，启动服务

查看完全备份信息

并没有备份后插入的数据，所以在用到binlog日志了,查看当前的binlog的位置

跨文件了~~~，没关系统，先还原同一个日志文件中的数据，再恢复这个日志中的数据，在mysql-bin.000012中找到delect之前的位置，并使用mysqlbinlog将其导出，临时性关闭binlog日志功能，恢复此间数据。

从日志中看标识到1108即可恢复到删除之前，将此区间导出

在数据中临时关闭binlog日志功能。

查看一下原来的数据

全部都回来了，退出会话，再次登录后，binlog日志将开始记录了。（以上操作，均要在 设置了skip-networking的情况下操作，完全恢复后，在配置文件中[mysqld]中将skip-networking注释掉，记得再来一次完全备份后，mariadb又可重新工作了）

3. Xtrabackup

⑴、简介

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

• 备份过程快速、可靠；

• 备份过程不会打断正在执行的事务；

• 能够基于压缩等功能节约磁盘空间和流量；

• 自动实现备份检验；

• 还原速度快；

⑵、安装

其最新版的软件可从 http://www.percona.com/software/percona-xtrabackup/ 获得

⑶、原理说明

这或许是最为广泛的备份方式。percona之所以家喻户晓，Xtrabackup应该功不可没。它实际上是物理备份+逻辑备份的组合。在备份innodb表的时候，它拷贝ibd文件，并一刻不停的监视redo log的变化，并不断的追加到自己的事务日志文件。在拷贝ibd文件过程中，ibd文件本身可能会被多次擦写，导致表空间数据与最初的不一致，其实这并不是问题，因为在拷贝完成后的第一个prepare（准备）阶段，Xtrabackup采用类似于innodb崩溃恢复的方法，把数据文件恢复到与日志文件一致的状态，并把未提交的事务回滚。如果同时需要备份myisam表以及innodb表结构等文件，那么就需要用flush tables with lock来获得全局锁，开始拷贝这些不再变化的文件，同时获得binlog位置，拷贝结束后释放锁，也停止对redo log的监视。
它的工作原理如下：

由于mysql中不可避免的含有myisam表，同时innobackup并不备份表结构等文件，因此想要完整的备份mysql实例，就少不了要执行flush tables with read lock，而这个语句会被任何查询(包括select)阻塞，在阻塞过程中，它又反过来阻塞任何查询(包括select)。如果碰巧备份实例上有长查询先于flush tables with read lock执行，数据库就会hang住。而当flush tables with read lock获得全局锁后，虽然查询可以执行，但是仍会阻塞更新，所以，我们希望flush tables with read lock从发起到结束，持续的时间越短越好。

⑷、实例：

利用Xtrabackup实现完全与增量备份

步骤

前提

授权一个仅可以备份操作的用户

①、完全备份

命令格式：

说明：

使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命令的目录中。

在备份的同时，innobackupex还会在备份目录中创建如下文件：

• xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

• xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。
  

• xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；
  

• backup-my.cnf —— 备份命令用到的配置选项信息；
  

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

====================================正式开始=====================================

完全备份部分

对当前的mariadb数据库做一次完备份

最后显示的信息：

• 备份的位置（以时间命令的目录下）

• binlog日志的当前位置

• 备份的状态

看一下备份目录中的文件

==========================================到此完全备份完成==============================

为了演示效果我会将数据目录清空。

完全恢复部分

注：

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

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

命令说明：

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

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

============================================正式开始====================================

准备工作开始

==================================准备工作完成=================================

• 从一个完全备份中恢复数据

注：

恢复不用启动MySQL

命令格式：

说明：

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

如果出现ok表示恢复完毕了。

回到数据目录下看一下文件的属性，确保文件的所有属性都是正确的用户，并可以以身份来访问与运行，如果不是，请修改其文件属性

启动mariadb

数据都恢复回来了。

==========================================到此完全备份、恢复完成======================

②增量备份

使用innobackupex进行增量备份

每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。

命令格式：

命令说明

其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。

需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。

“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：

(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。

(2)基于所有的备份将未提交的事务进行“回滚”。

于是，操作就变成了：

接着执行：

而后是第二个增量：

命令说明：

其中BASE-DIR指的是完全备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即如果有多次增量备份，每一次都要执行如上操作；

==================================增加备份正式开始====================================

首先，在还原后的数据库中插入一些数据。

结果如下：

增量备份开始

====================================到此增量备份完成==================================

如果在此增量之后，又增加了数据，如果数据量不是很大的话，基于二进制做即时还原会更快一些。此时又插入了一些数据

基于增量的数据还原

第一步，删除数据文件

第二步，开始准备还原的数据

所以说，只有需要恢复数据时，才可开始准备数据，因为其间可能有多个增量需要整合！

=============================准备工作到此完毕===================================

开始还原

查看binlog日志的标记，导出binlog日志并附加到数据库中

============================================增量备份演示完毕===========================

附加一些高级应用

• Xtrabackup的“流”及“备份压缩”功能

Xtrabackup对备份的数据文件支持“流”功能，即可以将备份的数据通过STDOUT传输给tar程序进行归档，而不是默认的直接保存至某备份目录中。要使用此功能，仅需要使用--stream选项即可。如：

甚至也可以使用类似如下命令将数据备份至其它服务器：

此外，在执行本地备份时，还可以使用--parallel选项对多个文件进行并行复制。此选项用于指定在复制时启动的线程数目。当然，在实际进行备份时要利用此功能的便利性，也需要启用innodb_file_per_table选项或共享的表空间通过innodb_data_file_path选项存储在多个ibdata文件中。对某一数据库的多个文件的复制无法利用到此功能。其简单使用方法如下：

同时，innobackupex备份的数据文件也可以存储至远程主机，这可以使用--remote-host选项来实现：

• 导入或导出单张表

默认情况下，InnoDB表不能通过直接复制表文件的方式在mysql服务器之间进行移植，即便使用了innodb_file_per_table选项。而使用Xtrabackup工具可以实现此种功能，不过，此时需要“导出”表的mysql服务器启用了innodb_file_per_table选项（严格来说，是要“导出”的表在其创建之前，mysql服务器就启用了innodb_file_per_table选项），并且“导入”表的服务器同时启用了innodb_file_per_table和innodb_expand_import选项。

(1)“导出”表

导出表是在备份的prepare阶段进行的，因此，一旦完全备份完成，就可以在prepare过程中通过--export选项将某表导出了：

此命令会为每个innodb表的表空间创建一个以.exp结尾的文件，这些以.exp结尾的文件则可以用于导入至其它服务器。

(2)“导入”表

要在mysql服务器上导入来自于其它服务器的某innodb表，需要先在当前服务器上创建一个跟原表表结构一致的表，而后才能实现将表导入：

然后将此表的表空间删除：

接下来，将来自于“导出”表的服务器的mytable表的mytable.ibd和mytable.exp文件复制到当前服务器的数据目录，然后使用如下命令将其“导入”：

• 使用Xtrabackup对数据库进行部分备份
  

Xtrabackup也可以实现部分备份，即只备份某个或某些指定的数据库或某数据库中的某个或某些表。但要使用此功能，必须启用innodb_file_per_table选项，即每张表保存为一个独立的文件。同时，其也不支持--stream选项，即不支持将数据通过管道传输给其它程序进行处理。

此外，还原部分备份跟还原全部数据的备份也有所不同，即你不能通过简单地将prepared的部分备份使用--copy-back选项直接复制回数据目录，而是要通过导入表的方向来实现还原。当然，有些情况下，部分备份也可以直接通过--copy-back进行还原，但这种方式还原而来的数据多数会产生数据不一致的问题，因此，无论如何不推荐使用这种方式。

(1)创建部分备份

创建部分备份的方式有三种：正则表达式(--include), 枚举表文件(--tables-file)和列出要备份的数据库(--databases)。

(a)使用--include

使用--include时，要求为其指定要备份的表的完整名称，即形如databasename.tablename，如：

(b)使用--tables-file

此选项的参数需要是一个文件名，此文件中每行包含一个要备份的表的完整名称；如：

(c)使用--databases

此选项接受的参数为数据名，如果要指定多个数据库，彼此间需要以空格隔开；同时，在指定某数据库时，也可以只指定其中的某张表。此外，此选项也可以接受一个文件为参数，文件中每一行为一个要备份的对象。如：

(2)整理(preparing)部分备份

prepare部分备份的过程类似于导出表的过程，要使用--export选项进行：

此命令执行过程中，innobackupex会调用xtrabackup命令从数据字典中移除缺失的表，因此，会显示出许多关于“表不存在”类的警告信息。同时，也会显示出为备份文件中存在的表创建.exp文件的相关信息。

(3)还原部分备份

还原部分备份的过程跟导入表的过程相同。当然，也可以通过直接复制prepared状态的备份直接至数据目录中实现还原，不要此时要求数据目录处于一致状态。

===============================================完===================================

本文转自 jinlinger 51CTO博客，原文链接：http://blog.51cto.com/essun/1396832，如需转载请自行联系原作者