备份与恢复概述,冷备,热备

对于DBA来讲，最基本的工做就是数据库的备份与恢复，在乎外状况下（如服务器宕机、磁盘损坏等）要保证数据不丢失，或者是最小程度地丢失。每一个DBA应该每时每刻都关心本身所负责的数据库的备份状况。MySQL数据库提供的大多数工具（如mysqldump、ibbackup、replication）都能很好地完成备份的工做，固然也能够经过第三方的一些工具来完成，如xtrabackup、LVM快照备份等。DBA应该根据本身的业务要求设计出损失最小、对数据库影响最小的备份策略。

备份与恢复概述

根据备份的方法能够分为：

1. Hot Backup（热备）
2. Cold Backup（冷备）
3. Warm Backup（温备）

Hot Backup是指在数据库运行中直接备份，对正在运行的数据库没有任何影响。这种方式在MySQL官方手册中称为Online Backup（在线备份）。Cold Backup是指在数据库中止的状况下进行备份，这种备份最为简单，通常只须要拷贝相关的数据库物理文件便可。这种方式在MySQL官方手册中称为Offline Backup（离线备份）。Warm Backup备份一样是在数据库运行时进行，可是会对当前数据库的操做有所影响，例如加一个全局读锁以保证备份数据的一致性。

若是按照备份后文件的内容，又能够分为：

1. 逻辑备份
2. 裸文件备份

在MySQL数据库中，逻辑备份是指备份后的文件内容是可读的，一般是文本文件，内容通常是SQL语句，或者是表内的实际数据，如mysqldump和SELECT * INTO OUTFILE的方法。这类方法的好处是能够看到导出文件的内容，通常适用于数据库的升级、迁移等工做，可是恢复所须要的时间每每较长。

裸文件备份是指拷贝数据库的物理文件，数据库既能够处于运行状态（如ibbackup、xtrabackup这类工具），也能够处于中止状态。这类备份的恢复时间每每较逻辑备份短不少。

若按照备份数据库的内容来分，又能够分为：

1. 彻底备份
2. 增量备份
3. 日志备份

彻底备份是指对数据库进行一个完整的备份。增量备份是指在上次的彻底备份基础上，对更新的数据进行备份。日志备份主要是指对MySQL数据库二进制日志的备份，经过对一个彻底备份进行二进制日志的重作来完成数据库的point-in-time的恢复工做。MySQL数据库复制（Replication）的原理就是异步实时进行二进制日志重作。

对于MySQL数据库来讲，官方没有提供真正的增量备份的方法，大部分是经过二进制日志来实现的。这种方法与真正的增量备份相比，效率仍是很低的。假设有一个100G的数据库，若是经过二进制日志来完成备份，可能同一个页须要屡次执行SQL语句来完成重作的工做。可是对于真正的增量备份来讲，只须要记录当前每一个页最后的检查点的LSN。若是大于以前彻底备份时的LSN，则备份该页，不然不用备份。这大大加快了备份的速度以及缩短了恢复的时间，同时这也是xtrabackup工具增量备份的原理。

此外，还须要理解数据库备份的一致性，这要求在备份的时候数据在这一时间点上是一致的。举例来讲，在一个网络游戏中有一个玩家购买了道具，这个事务的过程是：先扣除相应的金钱，而后往其装备表中插入道具，确保扣费和获得的道具是互相一致的。不然，在恢复时，可能出现金钱被扣除了，可是装备丢失的状况。

对于InnoDB存储引擎来讲，由于其支持MVCC(多版本控制)功能，所以实现备份一致比较容易。能够先开启一个事务，而后导出一组相关的表，最后提交。固然，事务隔离级别必须是REPEATABLE READ的，这样的作法就能够给你一个完美的一致性备份。然而，这个方法的前提是须要你正确地设计应用程序。上述购买道具的过程不能够分为两个事务来完成，如一个完成扣费，一个完成道具的购买。若备份发生在这二者之间，则会由于逻辑设计的问题致使备份出的数据依然是不一致的。

对于mysqldump备份工具来讲，能够经过添加-single-transaction选项来得到InnoDB存储引擎的一致性备份，这时的备份是在一个执行时间很长的事务中完成的。另外，对于InnoDB存储引擎的备份，要务必加上-single-transaction的选项（虽然是mysqldump的一个可选选项）。

冷备

对InnoDB存储引擎的冷备很是简单，只须要备份MySQL数据库的frm文件、共享表空间文件、独立表空间文件（*.ibd）、重作日志文件。另外，按期备份MySQL数据库的配置文件my.cnf，这样有利于恢复操做。

一般，DBA会写一个脚原本执行冷备的操做，DBA可能还会对备份完的数据库进行打包和压缩，这并非一件难事。关键在于，不要遗漏本来须要备份的物理文件，如共享表空间和重作日志文件，少了这些文件数据库可能都没法启动。另一种常常发生的状况是，因为磁盘空间已满而致使的备份失败，DBA可能习惯性地认为运行脚本的备份是没有问题的，少了检验的机制。

在同一台机器上对数据库进行冷备是远远不够的，还须要将本地的备份放入一台远程服务器中，以确保不会由于本地数据库宕机而影响备份文件的使用。

冷备的优势是：

1. 备份简单，只要拷贝相关文件便可。
2. 备份文件易于在不一样操做系统、不一样MySQL版本上进行恢复。
3. 恢复至关简单，只须要把文件恢复到指定位置便可。
4. 恢复速度快，不须要执行任何SQL语句，也不须要重建索引。

冷备的缺点是：

1. InnoDB存储引擎冷备的文件一般比逻辑文件大不少，由于表空间中存放着不少其余数据，如Undo段、插入缓冲等信息。
2. 冷备并不老是能够轻易地跨平台。操做系统、MySQL的版本、文件大小写敏感和浮点数格式都会成为问题。

热备

ibbackup

ibbackup是InnoDB存储引擎官方提供的热备工具，能够同时备份MyISAM存储引擎表和InnoDB存储引擎表。

InnoDB存储引擎表的备份工做原理以下：

1. 记录备份开始时，InnoDB存储引擎重作日志文件检查点的LSN。
2. 拷贝共享表空间文件以及独立表空间文件。
3. 记录拷贝完表空间文件后，InnoDB存储引擎重作日志文件检查点的LSN。
4. 拷贝在备份时产生的重作日志。

对于事务型的数据库，如SQL Server数据库、Oracle数据库，热备的原理与上述大体相同。能够发现，在备份期间不会对数据库自己有任何影响，所作的操做只是拷贝数据库文件，所以任何对数据库的操做都是容许的，不会出现阻塞状况。

所以，ibbackup的优势以下：

1. 在线备份。不阻塞任何SQL语句。
2. 备份性能好。备份的实质是复制数据库文件和重作日志文件。
3. 支持压缩备份。经过选项，能够支持不一样级别的压缩。
4. 跨平台支持。ibbackup能够运行在Linux、Windows以及主流的Unix系统平台上。

ibbackup对InnoDB存储引擎表的恢复过程以下：

1. 恢复表空间文件。
2. 应用重作日志文件恢复InnoDB存储引擎表。

ibbackup提供了一种高性能的热备方式，是InnoDB存储引擎备份的首选方式。不过它是收费软件，好在Pecona公司给咱们带来了开源、免费的XtraBackup热备工具，它能够实现ibbackup的全部功能，而且还扩展支持真正的增量备份功能。所以，更好的选择应该是使用XtraBackup来完成热备的工做。

XtraBackup

XtraBackup支持MySQL数据库5.0版和5.1版，同时也支持InnoDB Plugin版本新增的Barracuda页格式。XtraBackup在GPL v2开源协议下发布，官方网站地址是：https：//launchpad.net/percona-xtrabackup。

xtrabackup命令的使用方法以下：

xtrabackup --backup|--prepare [OPTIONS]

xtrabackup命令的可选参数以下所示：

(The defaults options should be given as the first argument)

--print-defaults Prints the program's argument list and exit.

--no-defaults Don't read the default options from any file.

--defaults-file=Read the default options from this file.

--defaults-extra-file=Read this file after the global options files have been read.

--target-dir=The destination directory for backups.

--backup Make a backup of a mysql instance.

--stats Calculate the statistic of the datadir（it is recommended you take mysqld offline）.

--prepare Prepare a backup so you can start mysql server with your restore.

--export Create files to import to another database after it has been prepared.

--print-param Print the parameters of mysqld that you will need for a for copyback.

--use-memory=This value is used instead of buffer_pool_size.

--suspend-at-end Creates a file called xtrabackup_suspended and waits until the user deletes that file at the end of the backup.

--throttle=（use with--backup）Limits the IO operations（pairs of reads and writes） per second to the values set here.

--log-stream outputs the contents of the xtrabackup_logfile to stdout.

--incremental-lsn=（use with--backup）Copy only.ibd pages newer than the specified LSN high：low. 

##ATTENTION##：checkpoint lsn*must*be used.Be Careful！

--incremental-basedir=（use with--backup）Copy only.ibd pages newer than the existing backup at the specified directory.

--incremental-dir=（use with--prepare）Apply.delta files and logfiles located in the specified directory.

--tables=name Regular Expression list of table names to be backed up.

--create-ib-logfile（NOT CURRENTLY IMPLEMENTED）will create ib_logfile* after a--prepare.

###If you want to create ib_logfile*only re-execute this command using the same options.###

--datadir=name Path to the database root.

--tmpdir=name Path for temporary files.Several paths may be specified as a colon（：）separated string.

If you specify multiple paths they are used round-robin.

若是咱们要作一个彻底备份，能够执行以下命令：

./xtrabackup --backup

./xtrabackup Ver alpha-0.2 for 5.0.75 unknown-linux-gnu（x86_64）

＞＞log scanned up to（0 1009910580）

............................................................................................................................

............................................................................................................................

Copying./tpcc/customer.ibd

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/customer.ibd

＞＞log scanned up to（0 1010561109）

……done

Copying./tpcc/district.ibd

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/

tpcc/district.ibd

……done

............................................................................................................................

............................................................................................................................

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/

tpcc/warehouse.ibd

……done

＞＞log scanned up to（0 1014592707）

Stopping log copying thread..

Transaction log of lsn（0 1009910580）to（0 1014592707）was copied.

XtraBackup实现增量备份

MySQL数据库自己提供的工具并不支持真正的增量备份，更准确地说，二进制日志的恢复应该是point-in-time的恢复而不是增量备份。XtraBackup工具支持对InnoDB存储引擎的增量备份，其工做原理以下：

（1）首先完成一个彻底备份，并记录下此时检查点的LSN。

（2）在进行增量备份时，比较表空间中每一个页的LSN是否大于上次备份时的LSN，若是是，则备份该页，同时记录当前检查点的LSN。

所以XtraBackup的备份和恢复过程大体以下：

（full backup）

#./xtrabackup --backup --target -dir=/backup/base

（incremental backup）

#./xtrabackup --backup --target -dir=/backup/delta --incremental -basedir=/backup/base

（prepare）

#./xtrabackup --prepare --target -dir=/backup/base

（apply incremental backup）

#./xtrabackup --prepare --target -dir=/backup/base --incremental -dir=/backup/delta

上述过程当中，首先将所有文件备份到/backup/base目录下，增量备份产生的文件备份到/backup/delta。恢复过程当中，首先指定彻底备份的路径，而后将增量备份应用于该彻底备份。如下显示了一个完整的增量备份过程：

./xtrabackup --backup

＞＞log scanned up to（0 378161500）

The latest check point（for incremental）：'0：377883685'＜=====使用这个LSN

＞＞log scanned up to（0 379294296）

Stopping log copying thread..

Transaction log of lsn（0 377883685）to（0 379294296）was copied.

（must do--prepare before the each incremental backup）

./xtrabackup --prepare

./xtrabackup --backup --incremental=0:377883685

incremental backup from 0：377883685 is enabled.

＞＞log scanned up to（0 379708047）

Copying./ibdata1

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/

tmp_diff/ibdata1.delta

……done

The latest check point（for incremental）：'0:379438233'＜====下一个增量备份开始的LSN

＞＞log scanned up to（0 380663549）

Stopping log copying thread..

Transaction log of lsn（0 379438233）to（0 380663549）was copied.