第八章 备份和恢复

8.1 备份和恢复概述、

根据备份的方法不同可以将备份分为：
Hot Backup（热备）
Cold Backup（冷备）
Warm Backup（温备）

热备是指数据库运行中直接备份，对正在运行的数据库操作没有任何影响。
冷备是指备份操作是在数据库停止的情况下，这种备份最为简单，一般只需复制相关的数据库物理文件即可。
温备是指在数据库运行中进行的，但是会对当前数据库的操作有影响，如加一个全局读锁以保证备份数据的一致性。

根据备份后文件的内容，备份又可以分为：
逻辑备份
裸文件备份

逻辑备份是指备份出的文件内容是可读的，一般是文本文件。内容一般是一条条SQL语句，或者表内实际数据组成，这类方法的好处是可以观察导出文件的内容，一般适用于数据库的升级，迁移等工作，缺点是恢复所需要的时间比较长
裸文件备份是指复制数据库的物理文件，即可以是在数据库运行中的复制，也可以是在数据库停止运行时直接的数据文件复制。这类备份的恢复时间往往较逻辑备份短很多

根据备份数据库的内容，备份又可以分为：

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

完全备份是指对数据库进行一个完整的备份。增量备份是指在上次完全备份的基础上，对于更改的数据进行备份。日志备份是指对MySQL数据库二进制日志的备份，通过对一个完全备份进行二进制日志的重做（replay）来完成数据库的point-in-time的恢复工作。MySQL数据库复制（replication）的原理就是异步实时地将二进制日志重做传送应用到从（slave/standby）数据库

对于MySQL数据库来说，官方没有提供真正的增量备份的方法，大部分都是通过二进制日志完成增量备份的工作。这种备份较之真正的增量备份来说，效率还是很低的。假如有一个100GB的数据库，要通过二进制日志完成备份，可能同一个页需要执行多次的SQL语句完成重做工作。但是对于真正的增量备份来说，只需要记录当前每页最后的检查点的LSN，如果大于之前全备时的LSN，则备份该页，否则不用备份，这大大加快了备份的速度和恢复时间，同时这也是xtrabackup工具增量备份的原理

对于msysqldump备份工具来说，可以通过添加 --single-transaction选项获得InnoDB存储引擎的一致性备份。

8.2 冷备
对于InnoDB存储引擎的冷备非常简单，只需要备份MySQL数据库的frm文件，共享表空间文件，独立表空间文件（*.ibd），重做日志文件。另外建议定期备份MySQL数据库的配置文件，这样有利于恢复操作。在同一台服务器上对数据库进行冷备是远远不够的，至少还需要将本地产生的备份存放到一台远程的服务器中，确保不会因为本地数据库的宕机而影响备份文件的使用。
冷备的优点是：

• 备份简单，只要复制相关文件即可。
• 备份文件易于在不同操作系统，不同MySQL版本上进行恢复。
• 恢复相当简单，只需要把文件恢复到指定位置即可。
• 恢复速度快，不需要执行任何SQL语句，也不需要重建索引。

冷备的缺点是：

• InnoDB存储引擎冷备的文件通常比逻辑文件大很多，因为表空间中存放着很多其他数据，如undo段，插入缓冲等信息。
• 冷备也不总是可以轻易地跨平台的。操作系统，MySQL版本，文件大小写敏感和浮点数格式都会成为问题。

8.3 逻辑备份

8.3.1 mysqldump
通常用来完成转存（dump）数据库的备份及不同数据库之间的移植，如从MySQL低版本升级到MySQL高版本数据库，又或者从MySQL移植到Oracle，SQL Server数据库等。
mysqldump的语法如下
mysqldump [arguments] > file_name
如果想要备份所有的数据库，可以使用--all-databases选项：
mysqldump --all-databases > dump.sql
备份指定数据库，可以使用--databases选项
mysqldump --databases db1 db2 > dump.sql
其他一些比较常用的参数如下

• --single-transaction：在备份开始前，先执行start transaction命令，以此来获取备份的一致性，当前该参数只对InnoDB存储引擎有效。当启动该参数并进行备份时，确保没有其他任何的DDL语句执行，因为一致性读并不能隔离DDL操作。

• --lock-tables：在备份中，以次锁住每个架构下的所有表。一般用于MyISAM存储引擎，当备份时只能对数据库进行读取操作，不过备份依然可以保证一致性。对于InnoDB存储引擎，不需要使用该参数，用--single-transaction即可。并且--lock-tables和--single-transaction是互斥的，不能同时使用，如果数据库中既有MyISAM引擎的表，又有InnoDB存储引擎的表，那么只有选择--lock-tables了。此外，因为--lock-tables选项是依次对每个架构中的表上锁，因此只能保证每个架构下表备份的一致性，而不能保证所有架构下表的一致性。

• --locl-all-tables：在备份的过程中，对所有架构中的所有表上锁。这个可以避免--lock-tables参数不能同时锁住所有表的问题。

• --master-data：取值为1或者2，默认为1，当这个参数的值为1的时候，mysqldump出来的文件就会包括CHANGE MASTER TO这个语句，CHANGE MASTER TO后面紧接着就是file和position的记录，在slave上导入数据时就会执行这个语句，salve就会根据指定这个文件位置从master端复制binlog。默认情况下这个值是1
  当这个值是2的时候，chang master to也是会写到dump文件里面去的，但是这个语句是被注释的状态。
  使用--master-data 参数会忽略--local-tables 参数
  使用--master-data 时，如果没有指定 --single-transaction 参数，则会自动使用 -locl-all-tables参数

• --tab=path（-T path）：产生TAB分隔的数据文件。对于每张表，mysqldump创建一个包含 create table 语句的table_name.sql文件，和包含数据的tbl_name.txt 文件。

• --events： 备份事件调度器

• --routines：备份存储过程和函数

• --triggers：备份触发器。

• --hex-blob：将BINARY，VARBINARY，BLOG和BIT列类型备份为十六进制的格式。

• --where = 'where_condition'：导出给定条件的数据。

8.3.2 select...into outfile
select...into outfile 也是一种逻辑备份的方法，更准确地说是导出一张表中的数据。
例如：select * into outfile '/dir/file1.txt' from a where...

8.3.3 逻辑备份的恢复
mysqldump的恢复操作比较简单，因为备份的文件就是导出的SQL语句，一般只需要执行这个文件就可以了。mysqldump可以导出存储过程，导出触发器，导出事件，导出数据，但是却不能导出视图。因此，如果用户的数据库还是用了视图，那么在用mysqldump备份完数据库后还需要导出视图的定义或者备份视图定义的frm文件，并在恢复时进行导入，这样才能保证mysqldump数据库的完全恢复。

8.3.4 load data infile
若通过mysqldump -tab ，或者通过select into outfile 导出的数据需要恢复，这是可以通过命令 load data infile来进行导入。load data infile的语法如下：
load data into table a ignore 1 lines infile '/dir/file1.txt'
要对服务器文件使用load data infile，必须拥有file权限。
为了加快InnoDB存储引擎的导入，可能希望导入过程忽略对外键的检查，因此可以先关闭外键检查，set @@foreign_key_checks = 0，然后导入数据，再开启开启外键检查 set @@foregin_key_checks = 1

8.3.5 mysqlimport
语法如下：mysqlimport [options] db_name textfile1 [textfile2 ...]
和load data infile不同的是，mysqlimport命令可以用来导入多张表。并且通过 --user-thread 参数并发地导入不同的文件，这里的并发是指并发的导入多个文件，而不是值并发的导入一个文件。

8.4 二进制日志备份与恢复
在默认情况下并不启用二进制日志，要使用二进制日志首先必须启用它。在配置文件中进行设置：
[mysqld]
log-bin=mysql-bin
但是只简单的开启二进制日志是不够的，还需要启动一些其他参数来保证最为安全和正确的记录二进制日志，因此对于InnoDB引擎，推荐的二进制日志的服务器配置是：
[mysqld]
log-bin=mysql-bin
sync_binlog=1
innodb_support_xa=1
通过 mysqlbinlog 恢复二进制日志，使用方法如下
mysqlbinlog [options] log_file
还可以通过--start-position 和 --stop-position选项来指定从二进制日志的某个偏移量来进行恢复
可以通过--start-datetime 和 --stop-datetime 选项来指定从二进制日志某个时间点来进行恢复。

8.5 热备

8.5.1 ibbackup
ibbackup 是InnoDB存储引擎官方提供的热备工具，可以同时备份MyISAM存储引擎和InnoDB存储引擎。其备份原理是：
1.记录备份开始时，InnoDB存储引擎重做日志文件检查点的LSN
2.复制共享表空间文件以及独立表空间文件
3.记录复制完表空间文件后，InnoDB存储引擎重做日志文件坚持点的LSN
4.复制在备份时产生的重做日志文件。

ibbackup的优点是：

• 在线备份，不阻塞任何的SQL语句
• 备份性能好，备份的实质是复制数据库文件和重做日志文件
• 支持压缩备份，通过选项，可以支持不同级别的压缩
• 跨平台支持，ibbackup可以运行在Linux，Windows以及主流的UNIX系统平台上。

ibbackup对InnoDB存储引擎表的恢复步骤为：
1.恢复表空间文件
2.应用重做日志文件

ibbackup是收费的，但是开源的XtraBackup热备工具，它实现所有ibbackup的功能，并支持真正的增量备份。

8.5.3 XtraBackup实现增量备份
MySQL数据库本省提供的工具并不支持真正的增量备份，更准确的说，二进制日志的恢复应该是point-in-time的恢复而不是增量备份。而XtraBackup 工具支持对于InnoDB存储引擎的增量备份，其工作原理如下：
1.首选完成一个全备，并记录下此时检查点的LSN
2.在进行增量备份时，比较表空间中每个页的LSN是否大于上次备份时的LSN，如果是，则备份该页，同时记录当前检查点的LSN。

8.7 复制
8.7.1 复制的工作原理
复制（replication）是MySQL数据库提供的一种高可用高性能的解决方法，一般用来建立大型的应用。总体来说，replication的工作原理分为以下3个步骤：
1.主服务器（master）把数据更改记录到二进制日志（binlog）中。
2.从服务器（slave）把主服务器的二进制日志复制到自己的中继日志（relay log）中
3.从服务器重做中继日志中的日志，把更改应用到自己的数据库上，以达到数据的最终一致性。

8.7.2 快照 + 复制的备份架构
复制可以用来备份，但功能不仅限于备份，其主要功能如下：

• 数据分布。由于MySQL数据库提供的复制并不需要很大的带宽要求，因此可以在不同的数据中心之间实现数据的复制。
• 读取的负载平衡。通过建立多个从服务器，可将读取平均地分布到这些从服务器中，并且减少了主服务器的压力。一般通过DNS的Round-Robin和Linux的LVS功能都可以实现负载平衡
• 数据库备份。复制对备份很有帮助，但是从服务器不是备份，不能完全替代备份
• 高可用性和故障转移。通过复制建立的从服务器有助于故障转移，减少故障的停机时间和恢复时间