对于备份恢复的理解

根据备份方法不同可以将备份划分为：

hot backup、cold backup、warm backup

热备是指在数据库运行中直接备份，对正在运行的数据库操作没有影响，又成为online backup。

冷备是指备份操作在数据库停止情况下备份，只需要复制相关的数据库物理文件，又称为offline backup

温备同样是在数据库运行中进行的，但是会对当前数据库的操作有所影响，如加一个全局读锁，保证备份的数据的一致性。

根据备份后文件的内容，备份分为：

逻辑备份、裸文件备份（物理备份）

逻辑备份是指备份出的文件内容是可读的，一般是文本文件，内容是SQL语句，或者表内实际数据。适合数据迁移、升级。缺点是恢复时间长。

物理备份是指复制数据库的物理文件，既可以是数据库运行中的复制，也可以是在数据库停止运行时直接的数据文件复制。恢复时间相对短。

按照备份数据库的内容，备份分为：

完全备份、增量备份、日志备份

全备是指对数据库进行完整的备份

增备是在上次备份的基础上，对于更改的数据进行备份，虽然备份的数据可能少了，但是仍然会扫描所有的数据

日志备份主要指对MySQL数据库二进制日志的备份，通过对一个全备进行二进制日志的重做来完成数据库的point-in-time的恢复工作

注：MySQL数据库复制原理就是异步实时的将二进制日志重做传送并应用到从数据库。

但是对于MySQL数据库，官方并没有提供真正的增备方案，大部分是通过二进制日志完成增量备份的工作。相对于真正的增量备份效率很低。真正的增备，只需要记录每页最后的检查点的LSN，如果大于之前的全备时的LSNS，就备份这个页，否则不用备份。加快了备份的速度和恢复时间。这也是xtrabackup工具增备的原理。

数据库备份的一致性，对于mysqldump是通过--single-transaction参数对innodb引擎的表实现的。这种备份要求在备份的时候数据在这一段时间点上是一致的。对于innodb引擎，因为支持MVCC特性，实现一致的备份比较简单，用户可以先开启一个事务，然后导出一组相关的表，最后提交。当然，用户的事务隔离级别必须是RR，这样就可以给出一个完美的一致性备份。然而，前提是用户正确的设计应用程序。比如，扣费和道具购买，需要是一个事务。

任何时候都需要做好远程异地备份，也就是容灾的防范。比如9.11时间和汶川地震等不可抗力导致机器损坏等等。

一、冷备

对于innodb引擎，只需要备份MySQL数据库的frm文件，ibdata、独立表空间文件、redo。另外建议定期备份MySQL配置文件，有利于恢复操作。关键在于不要遗漏原本需要的物理文件，如ibdata、redo等等。缺少这些文件会导致数据库无法启动。另外要注意磁盘空间满了导致备份失败的情况。一定要有检验机制。在一台机器上对数据库进行冷备是远远不够的，至少需要将本地产生的备份存放到远程服务器，确保不会因为本地数据库的宕机影响备份文件的使用。

冷备的优点是操作简单易行，恢复速度快，不需要执行任何SQL，不需要重建索引。

冷备的缺点是冷备的文件一般要很大。因为表空间中存放很多其他数据， 如undo段，插入缓冲等信息。冷备不总是轻易的跨平台。OS、MySQL版本、文件大小写敏感都会成为问题。

二、逻辑备份

mysqldump通常用来完成转成数据库的备份及不同数据库之间的移植。如MySQL低版本数据库升级到MySQL高版本数据库，或者MySQL数据库移植到Oracle、SQL server数据库等。对于mysqldump的语法可以通过mysqldump --help查看，这里不在一一赘述。这里只列举一些重要参数作为参考。

--single-transaction：在备份开始前，先执行start transaction命令，以此来获得备份的一致性，只对innodb引擎有效，启用该参数进行备份时，保证没有ddl操作。因为RR不能隔离DDL操作。

--lock-tables(-l)： 依次锁住架构下的所有表，一般用于MyISAM引擎，备份时，只能对数据库进行读操作，不过备份依然可以保证一致性。要注意它和--single-transaction是互斥的，不能同时使用，如果既有MyISAM，也有innodb，那么只能选择-l。因为-l是依次对每个架构中的表上锁的，所以，只能保证每个架构下表备份的一致性，不能保证所有架构下表的一致性。

--lock-all-tables(-x)：在备份过程中，对所有架构中所有表加读锁。可以避免-l不能锁住所有表的问题。但是会对生产产生严重影响。

--skip-add-drop-table ：默认会在create database是前，先drop database。这个参数可以防止删除生产表。

--master-data[=value]：通过该参数产生的备份转成文件主要用来建立一个replication，当value是1时，记录change master语句，value是2时，change master被注释。要注意，这个选项会自动忽略-l，如果没有--single-transaction，会自动使用-x。

--hex-blob：会将binary、varbinary、blob字段用16进制进行备份

--tab=path（-T path）：产生tab分割的数据文件，对于没张表，mysqldump创建一个包含create table语句的table_name.sql文件，包含数据的table_anme.txt文件。可以改变默认的分隔符、换行符等等。

 

三、逻辑备份的恢复

可以采用mysql -u -p < 备份文件名的方式，也可以登录数据库后，用source的方式。但是要注意，mysqldump可以导出存储过程。触发器，事务，数据，但不能导出视图

因此，如果用户数据库中使用了视图，需要在mysqldump备份数据库后，导出视图的定义，或者备份视图定义的frm文件。在恢复时导入，才能保证mysqldump数据库的完全恢复。

四、二进制日志备份与恢复

首先要配置binlog，在配置文件中写入log-bin，sync_binlog=1，如果对数据一致性要求不高，可以不设置innodb_support_xa=1。注意备份前，先对binlog做flush logs，生成一个新的二进制日志文件，然后备份之前的二进制日志。恢复操作通mysqlbinlog --start-position= --stop-position=来恢复。

五、热备

我使用的工具是xtrabackup，功能主要有，非阻塞备份innodb等事务引擎数据库、备份MyISAM表会阻塞、支持全备、增备、压缩备份、支持限流。对于索引数据，即使不备份，也会在prepare时，--rebuild-indexs。

开始备份时，xtrabackup首先记录了重做日志的位置，对备份的innodb存储引擎表的物理文件，即共享表空间和独立表空间进行copy操作。最后记录备份完成后的redo位置。二进制日志的恢复是point-in-time的恢复而不是增量备份。xtrabackup对于innodb存储引擎的增量备份，工作原理如下：

1）选择一个备份文件，记录检查点lsn

2）进行增量备份时，比较表空间中页的lsn是否大于上次备份时的lsn，如果是，则备份该页，同时记录当前检查点的lsn

innobackupex备份原理：

1）是perl写的脚本，调用xtrabackup来备份innodb数据库，但是xtrabackup是C语言写的程序，调用了innodb函数库和MySQL客户端的函数库。innodb函数提供了向数据文件应用的redo log功能，而MySQL客户端函数库提供了解析命令行参数的功能。innobackupex备份innodb数据库的功能，都是通过调用xtrabackup --backup和xtrabackup --prepare来完成的。没有必要直接使用xtrabackup来备份。xtrabackup通过跳转到datadir目录，然后通过两个线程来完成备份过程。

1> log-copy thread：备份开始时，改后台线程一直监控redo log（每秒一次），将redo log的修改复制到备份之后的文件xtrabackup_logfile中。如果redo log生成很快，可能这个线程跟不上redo log产生的速度，redo log文件进行切换覆盖的时候，xtrabackup会报错。

2>data-file-copy thread：前后有一个复制data file的线程，不是简单的复制，而是调用了innodb函数库，像innodb引擎数据库那样打开数据文件，进行读取，然后每次复制一个page，然后对page进行验证，如果验证错误，最多重复十次。

要注意的是，复制数据文件分成了两个过程：

 

一个是复制innodb事务引擎的数据文件，是不需要持有锁的；另一个是复制非事务引擎的数据文件和table的定义文件.frm，复制这些文件时，是需要先通过FTWRL，然后在进行复制的，所以会导致整个数据库被阻塞。

 

xtrabackup参数：

1、对于innobackupex选项最佳实践

1.优化FTWRL锁（flush table with read lock）

在备份非innodb数据库时，会使用FTWRL全局锁锁住整个数据库，如果数据库中有一个长查询在运行，那么FTWRL就不能获得，会被阻塞，进而阻塞所有dml操作。即使kill掉全局锁也无法从阻塞中恢复过来。另外在成功获得了全局锁以后，在copy非事务引擎的文件过程中，整个数据库也是被锁住的。所以，应该让全局锁的时间尽量的短。因为在copy非事务引擎数据的文件时，会阻塞innodb事务引擎，当然也会阻塞所有其他非事务引擎。

1）防止阻塞：

---ftwrl-wait-timeout=# 表示，如果在FTWRL时，如果有长查询，最多等待60s，如果长查询在60s内结束，就可以成功执行FTWRL，如果没有结束，那么就报错退出。参数默认是0.

 

--ftwrl-wait-threshold=# 表示，在运行多长时间的查询以后，认为是长查询，对于长查询等待---ftwrl-wait-timeout的时间

2）缩短全局锁的时间

--rsync：用来缩短备份非事务引擎表的锁定时间，如果需要备份的数据库和表的量很大，可以加快速度

3）并行优化

--parallel，在备份阶段，压缩/解压阶段，加密/解密阶段，应用日志，拷贝阶段都可以并行

4）内存优化

--user-memory=# 在--apply-log阶段使用这个选项

个人总结的最佳实践：

--ftwrl-wait-timeout=60 防止发生阻塞

--rsync 减少FTWRL时间 缩短备份非事务引擎表的锁定时间

--parallel=4  开并行

--use-memory=4G crash recovery期间，即应用日志期间使用的内存

--throttle——》限流，不会影响生产，但是，备份速度会有锁降低

 

 

本作品采用 [知识共享署名 4.0 国际许可协议](https://creativecommons.org/licenses/by/4.0/) 进行许可。 转载时请注明原文链接。From TCeason