备份与恢复概述,冷备,热备
对于DBA来说,最基本的工作就是数据库的备份与恢复,在意外情况下(如服务器宕机、磁盘损坏等)要保证数据不丢失,或者是最小程度地丢失。每个DBA应该每时每刻都关心自己所负责的数据库的备份情况。MySQL数据库提供的大多数工具(如mysqldump、ibbackup、replication)都能很好地完成备份的工作,当然也可以通过第三方的一些工具来完成,如xtrabackup、LVM快照备份等。DBA应该根据自己的业务要求设计出损失最小、对数据库影响最小的备份策略。
备份与恢复概述
根据备份的方法可以分为:
- Hot Backup(热备)
- Cold Backup(冷备)
- Warm Backup(温备)
Hot Backup是指在数据库运行中直接备份,对正在运行的数据库没有任何影响。这种方式在MySQL官方手册中称为Online Backup(在线备份)。Cold Backup是指在数据库停止的情况下进行备份,这种备份最为简单,一般只需要拷贝相关的数据库物理文件即可。这种方式在MySQL官方手册中称为Offline Backup(离线备份)。Warm Backup备份同样是在数据库运行时进行,但是会对当前数据库的操作有所影响,例如加一个全局读锁以保证备份数据的一致性。
如果按照备份后文件的内容,又可以分为:
- 逻辑备份
- 裸文件备份
在MySQL数据库中,逻辑备份是指备份后的文件内容是可读的,通常是文本文件,内容一般是SQL语句,或者是表内的实际数据,如mysqldump和SELECT * INTO OUTFILE的方法。这类方法的好处是可以看到导出文件的内容,一般适用于数据库的升级、迁移等工作,但是恢复所需要的时间往往较长。
裸文件备份是指拷贝数据库的物理文件,数据库既可以处于运行状态(如ibbackup、xtrabackup这类工具),也可以处于停止状态。这类备份的恢复时间往往较逻辑备份短很多。
若按照备份数据库的内容来分,又可以分为:
- 完全备份
- 增量备份
- 日志备份
完全备份是指对数据库进行一个完整的备份。增量备份是指在上次的完全备份基础上,对更新的数据进行备份。日志备份主要是指对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可能习惯性地认为运行脚本的备份是没有问题的,少了检验的机制。
在同一台机器上对数据库进行冷备是远远不够的,还需要将本地的备份放入一台远程服务器中,以确保不会因为本地数据库宕机而影响备份文件的使用。
冷备的优点是:
- 备份简单,只要拷贝相关文件即可。
- 备份文件易于在不同操作系统、不同MySQL版本上进行恢复。
- 恢复相当简单,只需要把文件恢复到指定位置即可。
- 恢复速度快,不需要执行任何SQL语句,也不需要重建索引。
冷备的缺点是:
- InnoDB存储引擎冷备的文件通常比逻辑文件大很多,因为表空间中存放着很多其他数据,如Undo段、插入缓冲等信息。
- 冷备并不总是可以轻易地跨平台。操作系统、MySQL的版本、文件大小写敏感和浮点数格式都会成为问题。
热备
ibbackup
ibbackup是InnoDB存储引擎官方提供的热备工具,可以同时备份MyISAM存储引擎表和InnoDB存储引擎表。
InnoDB存储引擎表的备份工作原理如下:
- 记录备份开始时,InnoDB存储引擎重做日志文件检查点的LSN。
- 拷贝共享表空间文件以及独立表空间文件。
- 记录拷贝完表空间文件后,InnoDB存储引擎重做日志文件检查点的LSN。
- 拷贝在备份时产生的重做日志。
对于事务型的数据库,如SQL Server数据库、Oracle数据库,热备的原理与上述大致相同。可以发现,在备份期间不会对数据库本身有任何影响,所做的操作只是拷贝数据库文件,因此任何对数据库的操作都是允许的,不会出现阻塞情况。
因此,ibbackup的优点如下:
- 在线备份。不阻塞任何SQL语句。
- 备份性能好。备份的实质是复制数据库文件和重做日志文件。
- 支持压缩备份。通过选项,可以支持不同级别的压缩。
- 跨平台支持。ibbackup可以运行在Linux、Windows以及主流的Unix系统平台上。
ibbackup对InnoDB存储引擎表的恢复过程如下:
- 恢复表空间文件。
- 应用重做日志文件恢复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.