本章记录数据库的备份与恢复操做。MySQL提供了不少工具完成备份工做:mysqldump、ibbackup、replication,也可使用一些第三方的工具完成,如xtrabacup、LVM快照等。mysql
根据备份方法的不一样,能够将备份分为:linux
Hot Backup(热备):指的是在数据库运行中直接备份,对运行没有影响sql
Cold Backup(冷备):在数据库中止的状况下,这种备份最简单,通常就复制物理文件便可数据库
Warm Backup(温备):在数据库运行中,可是对数据库操做会有影响,如加一个全局的读锁保证备份数据的一致性windows
备份后的文件,又能够分为:安全
逻辑备份:指备份出的文件内容是可读的,通常是文本文件,内容是一条条SQL语句,或者是表内实际数据组成。如mysqldump和select * into outfile的方法。这类方法的好处是能够观察导出的文件内容,通常适用于数据库的升级、迁移等工做。可是缺点是恢复所须要的时间每每比较长。服务器
裸文件备份:指复制数据库的物理文件,既能够是在数据库运行中的复制,也能够是在数据库中止运行时直接的数据文件复制。这类备份的恢复时间每每较逻辑备份要短。架构
按照备份数据库的内容,又可分为:并发
彻底备份:对数据库进行一个完整的备份异步
增量备份:对上次完整备份的基础上,对更改的数据进行备份
日志备份:经过对一个彻底备份进行二级制日志的重作来完成数据库的point-in-time的恢复工做。MySQL数据库的复制原理就是异步实时地将二进制日志重作传送并应用到从数据库。
对MySQL来讲,官方没有提供真正的增量备份的方法,大部分是经过二进制日志完成增量备份的工做。这种备份较之真正的增量备份来讲,效率仍是很低的。由于可能对一个页执行屡次SQL完成重作。对于真正的增量备份,只须要记录当前每页最后的检查点的LSN,若是大于以前全备时的LSN,则备份该页,不然不用备份,这大大加快了备份的速度和恢复的时间,同时也是xtrabackup工具增量备份的原理。
此外还要注意理解数据库备份一致性,要求在备份的时候数据在这一时间点上是一致的。例如:买东西,扣钱得东西,可是备份过程当中备份了扣钱,而没有备份得东西就很糟糕了。
InnoDB支持MVCC功能,所以实现一致的备份比较简单。用户能够先开启一个事务,而后导出一组相关的表,最后提交。事务的隔离级别固然是要REPEATABLE READ,这样就能够给出一个完美的一致性备份。
对于mysqldump备份工具来讲,能够经过添加--single-transaction选项得到InnoDB存储引擎的一致性备份,原理和以前所说的相同。
最后,任什么时候候都须要作好远程异地备份,容灾的防范。
对于InnoDB存储引擎的冷备很是简单,只须要备份MySQL数据库的frm文件,共享表空间文件,独立表空间文件*.ibd,重作日志文件。另外,建议备份MySQL数据库的配置文件my.cnf,有利于恢复操做。
一台机器的冷备是不够的,要将数据放在远程的机房。
冷备的优势是:
备份简单,只须要复制相关文件便可
备份文件易于在不一样操做系统,不一样MySQL版本上进行恢复
恢复至关简单,只须要把文件恢复到指定位置便可
恢复速度快,不须要执行任何SQL语句,也不须要重建索引
冷备的缺点是:
文件比逻辑文件大不少,由于表空间存放不少其它数据,好比undo段,插入缓冲等。
冷备也不老是能够轻易跨平台,操做系统、MySQL版本、文件大小写敏感、浮点数格式都会成为问题。
mysqldump [arguments] > file_name
若是想备份全部的数据库,使用--all-databases选项:
mysqldump --all-databases > dump.sql
若是想要备份指定的数据库 --databases db1 db2 db3
若是想要对test这个架构进行备份,可使用:
mysqldump --single-transaction test > test_backup.sql 以前说了--single-transaction用于保证备份的一致性
参数有不少,可使用mysqldump --help查看,下面介绍一些比较重要的参数:
--single-transaction: 在备份开始前,先执行START TRANSACTION命令,以得到备份的一致性,当前该参数只对InnoDB存储引擎有效。
--lock-tables:在备份中,一次锁住每一个架构下的全部表。通常用于MyISAM存储引擎,能够保证一致性。这个参数与上面参数是互斥的,只能用一个。若是有两种表,只能选择这个。可是只能保证同一架构下的一致性,不能保证全部架构下的一致性。
--lock-all-tables: 用于避免上面说的一致性问题,锁住全部的表
--add-drop-database:在create database前先进行drop database。这个参数须要和--all-databases或者--databases选项一块儿使用。
--master-data[=value]:经过该参数产生的备份转存文件主要用来创建一个replication。当value为1时,转存文件中记录CHANGE MASTER语句。为2时,CHANGE MASTER语句被写出SQL注释。默认值为空。这个会忽略--lock-tables选项,若是没有使用--single-transaction就会自动加上--lock-all-tables选项。
--events: 备份事件调度器
--routines:备份存储过程和函数
--triggers:备份触发器
--hex-blob:将BINARY、VARBINARY、BLOG、BIT列类型备份为十六进制的格式。文本模式下有些字符可能看不见。
--tab=path:产生TAB分割的数据文件。
--where:导出指定的文件数据
这个也是一种逻辑备份的方法,更准确地说是导出一张表中的数据。
SELECT [column 1], [column 2] ...
INTO
OUTFILE 'file_name'
[{FIELDS | COLUMNS}
[TERMINATED BY 'string'] 表示分隔符
[[OPTIONALLY] ENCLOSED BY 'char'] 表示对字符串的包含符
[ESCAPED BY 'char']] 表示转义符
[ LINES
[ STARTING BY 'string'] 表示每行开始的字符串
[ TERMINATED BY 'string'] 表示每行结束的字符串
]
FROM TABLE WHERE...
mysqldump的恢复操做比较简单,由于备份的就是SQL,执行这个文件就能够了。
mysql -uroot -p < test_backup.sql
若是导出时包含了建立和删除数据库的SQL语句,那么必须确保删除架构时,架构目录下没有其余与数据库相关的文件,不然会出错。
由于逻辑备份的文件是由SQL语句组成的,也能够经过SOURCE命令来执行导出的逻辑备份文件:
source /home/mysql/test_back.sql
经过mysqldump能够恢复数据库,可是其能够导出存储过程,触发器,事件,数据,可是不能导出视图。所以若是使用了视图,备份完数据库后,还须要导出视图的定义,或备份视图定义的文件frm,并在恢复时导入。
若经过mysqldump-tab,或者经过select into outfile导出的数据须要恢复,这时能够经过命令LOAD DATA INFILE进行导入。语法以下:
LOAD DATA INTO TABLE a IGNORE 1 LINES INFILES '/home/mysql/a.txt'
[REPLACE | IGNORE] INTO TABLE tbl_name
[CHARACTER SET charset_name]
[{FIELDS | COLUMNS}
[ TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
[TERMINATED BY 'string']
]
[IGNORE number LINES]
[(col_name_or_user_var, ...)]
[SET col_name= expr, ...]
能够设置导入过程忽略对外键的检查,加快导入速度:set @@foreign_key_checks=0
这是MySQL提供的一个命令行程序,从本质上来讲,是LOAD DATA INFILE的命令接口,大部分选项和LOAD DATA INFILE语法相同。
mysqlimport [options] db_name textfile1 [textfile2...]
不一样的是,其能够用来导入多张表。而且经过--user-thread参数并发地导入不一样的文件。并发是指同时导入多个文件,不是同时操做一个文件。
二级制日志很是关键,用户能够经过它完成point-in-time的恢复工做。MySQL的replication一样须要二进制日志,默认状况下是不开启的,须要配置log-bin=mysql-bin
在以前说过,只是简单的启用二进制日志是不够的,须要一些其余参数保证最为安全和正确地记录二进制日志,所以对于InnoDB存储引擎,推荐的二进制日志的服务器配置应该是:
log-bin = mysql-bin
sync_binlog = 1
innodb_support_xa=1
在备份二进制日志文件前,能够经过FLUSH LOGS命令生成一个新的二进制日志文件,而后备份以前的。
恢复二进制日志也很是简单,经过mysqlbinlog便可。
mysqlbinlog [options] log_file
这个是InnoDB存储引擎官方提供的热备工具,能够同时备份MyISAM存储引擎和INNODB存储引擎表。对InnoDB的备份工做原理以下:
1.记录备份开始时,InnoDB存储引擎重作日志文件检查点的LSN。
2.复制共享表空间文件以及独立表空间文件
3.记录复制完表空间文件后,InnoDB存储引擎重作日志文件检查点的LSN
4.复制在备份时产生的重作日志。
对于事务的数据库,如Oracle和SQL Server,热备的原理大体和上相同。能够发如今备份期间不会对数据库自己有任何影响,所作的操做只是复制数据库文件,所以任何对数据库的操做都是容许的,不会阻塞任何操做。
ibbackup的优势以下:
1.在线备份,不阻塞任何的SQL
2.备份性能好,实质是复制数据库文件和重作日志文件
3.支持压缩备份,经过选项,支持不一样级别的压缩
4.跨平台支持,能够运行再linux、windows和主流的unix系统上
ibbackup对InnoDB存储引擎表的恢复步骤以下:
1.恢复表空间文件
2.应用重作日志文件
ibbackup提供了一种高性能的热备方式,是首选方式。可是其是收费的,不过开源的缘由,社区的力量,Percona公司作了一款免费的XtraBackup热备工具,其实现了全部ibbackup功能,并扩展支持了真正的增量备份功能。
该工具支持MySQL5.0以上版本,在GPL v2开源下发布。
命令是: xtrabackup--backup | --prepare [OPTIONS],具体可选参数就不进行介绍了。
若是要作一个彻底备份,能够执行命令:
xtrabackup --backup
MySQL数据库自己提供的工具并不支持真正的增量备份,更准确地说,二进制日志的恢复应该是point-in-time的恢复而不是增量备份。
XtraBackup支持增量备份,工做原理以下:
1.首先完成一个全备,记录下此时检查点的LSN
2.在进行增量备份时,比较表空间中每一个页的LSN是否大于上次备份时的LSN,若是是,则备份该页,同时记录下当前检查点的LSN。
xtrabackup --backup --target-dir=/backup/base 全备份
xtrabackup --backup --target-dir=/backup/delta --incremental-basedir=/backup/base 增量备份
xtrabackup --prepare --target-dir=/backup/base 准备增量
xtrabackup --prepare --target-dir=/backup/base --incremental-basedir=/backup/delta 添加增量数据
MySQL自己不支持快照功能,因此快照备份是指经过文件系统支持的快照功能对数据库进行备份。备份的前提是将全部数据库文件放在同一个文件分区中,而后对该分区进行快照操做。
支持快照的文件系统设备包括FreeBSD的UFS文件系统,Solaris的ZFS文件系统,GUN/Linux的逻辑管理器(LVM)等。这里以LVM为例进行介绍,UFS和ZFS的快照实现大体和LVM类似。
LVM是LINUX系统下对磁盘分区进行管理的一种机制。LVM在硬盘和分区上创建一个逻辑层,来提升磁盘分区管理的灵活性。管理员能够经过LVM系统轻松管理磁盘分区。例如,将若干个磁盘分区链接成一个整块的卷组,造成一个存储池。管理员能够在卷组上随意建立逻辑卷,并进一步在逻辑卷上建立文件系统。管理员经过LVM能够方便地调整卷组的大小,而且能够对磁盘存储按照组的方式进行命名、管理和分配。
vgdisplay命令查看系统中有哪些卷组。lvdisplay能够用来查看当前系统中有哪些逻辑卷。
LVM使用了写时复制技术来建立快照。当建立一个快照时,仅复制原始卷中数据的元数据,并不会有数据的物理操做,所以快照的建立过程是很是快的。当快照建立完成,原始卷上有写操做时,快照会跟踪原始卷块的改变,将要改变的数据在改变以前复制到快照预留的空间中,所以这个原理称为写时复制。对于读取操做,若是读取的数据块是建立快照后没有修改过的,会将读操做直接重定向原始卷上,若是修改过,就直接读取保存在快照中该块在原始卷上改变以前的数据。采起写时复制机制保证了读取快照时获得的数据与快照建立时一致。
复制是MySQL数据库提供的一种高可用高性能的解决方案,通常用来创建大型应用。整体来讲,replication的工做原理分为如下3个步骤:
1.主服务器(master)把数据更改记录到二进制日志中。
2.从服务器(slave)把主服务器的二进制日志复制到本身的中继日志中
3.从服务器重作中继日志中的日志,把更改应用到本身的数据库上,以达到数据的最终一致性。
复制的原理其实就是一个彻底备份加上二进制日志备份的还原。不一样的是这个二进制日志的还原操做基本上实时在进行中。这里要注意,复制不是彻底实时进行同步的,而是异步实时。这中间存在主从服务器之间的执行延时,若是主服务器压力很大,则可能致使从服务器延时较大。
从服务器有2个线程,一个是IO线程,负责读取主服务器的二进制日志,并将其保存为中继日志。另外一个线程是SQL线程,复制执行中继日志。MySQL4.0版本以前,从服务器只有1个线程,既负责读取二进制日志,又复制执行二进制日志中的SQL语句。这样不符合高性能的要求,已淘汰。SHOW FULL PROCESSLIST能够看见相关内容。
SHOW SLAVE STATUS和SHOW MASTER STATUS能够观察一下延迟。主要是观察从服务器的read_master_log_pos和主服务器的当前二进制偏移量position,知道两者的差距。
复制能够用来做为备份,但功能不只限于备份,主要功能以下:
1.数据分布。因为MySQL数据库提供的复制并不须要很大的带宽要求,所以能够在不一样的数据中心之间实现数据的复制。
2.读取的负载平衡。经过创建多个从服务器,能够将读取平均地分布到这些从服务器中,而且减小主服务器的压力。通常经过DNS的Round-Robin和Linux的LVS功能实现
3.数据库备份。复制对备份颇有帮助,可是从服务器不是备份,不能彻底代替备份。
4.高可用性和故障转移。经过复制创建的从服务器有助于故障转移,减小故障的停机时间和恢复时间。
建议在从服务器上启用read-only选项,保证从服务器上的数据仅与主服务器进行同步,避免其余线程修改。[mysqld] read-only
启用read-only选项后,若是操做从服务器的用户没有super权限,则对从服务器进行任何的修改都会抛出错误。