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

一、备份的意义从数据安全的角度来说，数据库服务器磁盘都会做RAID，Mariadb本身也有主从等容灾机制，但它们都无法完全取代备份。容灾和高可用能帮我们有效的应

二、备份类型

1、根据备份时，数据库服务器是否在线：

2、根据备份的数据集：

4、根据备份时是备份整个数据还是仅备份变化的数据：

5、备份策略：

6、备份对象

三、常见的备份工具

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'

LOAD DATA INFILE '/path/from/somefile'

不会备份关系定义，仅备份表中的数据；

逻辑备份工具，快于mysqldump。

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

①命令介绍

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

备份单个库：

mysqldump [options] db_name

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

options说明

--all-databases:　备份所有库

--databases db1 db2 ...: 备份指定的多个库

注意：备份前要加锁

--lock-all-tables：请求锁定所有表之后再备份，对MyISAM、InnoDB、Aria做温备

--single-transaction: 能够对InnoDB存储引擎实现热备；

备份代码：

--events: 备份事件调度器代码

--routines: 备份存储过程和存储函数

--triggers：备份触发器

备份时滚动日志：

--flush-logs: 备份前、请求到锁之后滚动日志；

复制时的同步位置标记：

--master-data=[0|1|2]

0: 不记录

1：记录为CHANGE MASTER语句

2：记录为注释的CHANGE MASTER语句

注意

使用mysqldump备份

请求锁：--lock-all-tables或使用--singe-transaction进行innodb热备；

滚动日志：--flush-logs

选定要备份的库：--databases

记录二进制日志文件及位置：--master-data=

恢复

建议：关闭二进制日志，关闭其它用户连接；

建议备份策略：基于mysqldump

备份部分

mysqldump+二进制日志文件；

恢复

完全备份+各二进制日志文件中至此刻的事件，对MySQL配置文件，以及与MySQL相关的OS配置文件在每次修改后都应该直接进行备份；

②、实例

要求如下：

备份所有数据库，要每周日凌晨自动执行；

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

备份阶段

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

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

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

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

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

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

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

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

恢复部分

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

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