mysql 开发进阶篇系列 44 物理备份与恢复( 热备份xtrabackup 工具介绍)
一.概述
物理备份和恢复又分为冷备份和热备份。与逻辑备份相比，它最大优点是备份和恢复的速度更快。因为物理备份的原理都是基于文件的cp。
1.1 冷备份
冷备份就是停掉数据库服务。这种物理备份一般很少使用，因为很多应用是不允许长时间停机的。恢复操作大概是：首先停掉mysql服务， 在操作系统级别恢复mysql的数据文件，然后重启mysql服务， 使用mysqlbinlog工具恢复自备份以来的所有binlog。估计这种方法跟sql server的分离附加库类似。由于会停机，冷备份就不在深入。
1.2 热备份
对于热备份有很多方法，本质其实就是将要备份的表加读锁，然后再cp数据文件到备份目录。对于热备份有很多第三方工具。使用最为广泛的好像是 xtrabackup 工具,该工具是用来备份mysql数据库的开源工具。
点击查看xtrabackup 用户指南
二. precona xtrabackup 介绍
下面翻译来自官方文档 2.4版本，有些地方翻译后不是很懂，在后面继续学习xtrabackup中，一边实战一边理解，在回头把该介绍文档修正。
2.1 xtrabackup介绍
Percona XtraBackup是一个开源的MySQL服务器热备份工具，在备份期间不会锁定数据库。是一个编译好的C二进制文件，提供了用MyISAM、InnoDB和XtraDB表备份整个MySQL数据库实例的功能。现是最新版本是2.4，目前只支持在linux系统上。
它可以在MySQL 5.1、5.5、5.6和5.7服务器上备份InnoDB、XtraDB和MyISAM表的数据，也可以用XtraDB备份Percona服务器的数据。
无论是24x7高负载的服务器还是低事务量的环境，Percona XtraBackup的设计目的是使备份成为一个无缝的过程，而不会破坏生产环境中服务器的性能。
2.2 支持的备份类型
(1)增量备份
(2)部分备份
(3)紧凑的备份
2.3 高级特征
(1)使用xtrabackup脚本备份
(2)统计分析表
(3)处理二进制日志
(4)恢复单个表
(5)LRU转储备份
2.4 XtraBackup备份功能
下面介绍下XtraBackup工具的主要特征，功能中讲到的Drizzle、MariaDB和Percona Server等是MySQL分 支。
|
Supported MySQL flavors |
支持mysql分支类型 MySQL, PerconaServer, MariaDB, Percona XtraDB Cluster, MariaDB Galera Cluster |
|
Supported operating systems |
支持的操作系统: linux |
|
Non-blocking InnoDB backups |
非阻塞InnoDB备份。在复制非InnoDB数据时，InnoDB表仍然是锁定的。 |
|
Blocking MyISAM backups |
阻塞MyISAM备份 |
|
Incremental backups |
增量备份 |
|
Full compressed backups |
完全压缩备份 |
|
Incremental compressed backups |
增量压缩备份 |
|
Fast incremental backups |
快速增量备份。 Percona服务器支持快速增量备份，支持XtraDB更改页面跟踪 |
|
Incremental backups with archived logs feature in Percona Server |
Percona服务器里带有归档日志特性的增量备份 |
|
Incremental backups with REDO log only |
仅使用重做日志的增量备份 |
|
Backup locks |
备份锁是Percona Server 5.6+中具有读锁的表的轻量级替代方法。Percona XtraBackup自动使用它们复制非InnoDB数据，以避免阻塞修改InnoDB表的DML查询。 |
|
Encrypted backups |
加密备份 |
|
Streaming backups |
流备份 |
|
Parallel local backups |
并行的本地备份 |
|
Parallel compression |
并行压缩 |
|
Parallel encryption |
并行加密 |
|
Parallel apply-log |
并行apply-log |
|
Parallel copy-back |
并行copy-back |
|
Partial backups |
部分备份 |
|
Partial backups of individual partitions |
各种分区的部分备份 |
|
Point-in-time recovery support |
时间点恢复支持 |
|
Safe slave backups |
安全的从库备份 |
|
Compact backups |
紧凑备份。Percona XtraBackup在准备紧凑备份时跳过二级索引页并重新创建它们。MySQL企业备份跳过未使用的页面并重新插入到准备阶段。 |
|
Buffer pool state backups |
缓冲池状态备份 |
|
Individual tables export |
各种表导出 |
|
Individual partitions export |
各种分区导出 |
|
Restoring tables to a different server |
将表还原到另一台服务器。使用Percona XtraBackup导出的表可以导入Percona Server 5.1、5.5或5.6+或MySQL 5.6+。使用MySQL企业备份创建的可传输表空间只能导入Percona Server 5.6+、MySQL 5.6+或MariaDB 10.0+。 |
|
Data & index file statistics |
数据和索引文件统计 |
|
InnoDB secondary indexes defragmentation |
InnoDB二级索引整理 |
|
support to minimize lock time |
支持最小化锁的时间 |
|
Backup history table |
备份历史表 |
|
External graphical user interfaces to backup/recovery |
用于备份/恢复的外部图形用户界面 |
2.5 备份工作原理
Percona XtraBackup基于InnoDB的崩溃恢复功能, 它会复制InnoDB数据文件，这会导致内部不一致的数据, 然后，它对文件执行崩溃恢复，使它们再次成为一致的、可用的数据库。
它的工作是因为InnoDB维护一个重做日志，也称为事务日志。这包含对InnoDB数据的每次更改的记录。当InnoDB启动时，它检查数据文件和事务日志，并执行两个步骤。它将提交的事务日志条目应用于数据文件，并对任何修改了数据但没有提交的事务执行撤销操作。
Percona XtraBackup的工作原理是在日志序列号(LSN)启动时记住它，然后复制数据文件。这样做需要一些时间，所以如果文件正在更改，那么它们就会在不同的时间点反映数据库的状态。同时，Percona XtraBackup运行一个后台进程来监视事务日志文件，并从中复制更改。Percona XtraBackup需要不断地这样做，因为事务日志是以循环方式编写的，并且可以在一段时间后重用。自从Percona XtraBackup开始执行以来，对数据文件的每次更改都需要事务日志记录。
Percona XtraBackup将使用备份锁作为具有读锁的表的轻量级替代。这个特性在Percona Server 5.6+中可用。Percona XtraBackup自动使用此功能复制非InnoDB数据，以避免阻塞修改InnoDB表的DML查询。当服务器支持备份锁时，xtrabackup首先复制InnoDB数据，运行锁表进行备份，然后复制MyISAM表和.frm文件。一旦完成，文件的备份将开始。它将备份.frm， . mrg， . myd， . myi， . trg， . trn， . arm， . arz， . csm， . csv， .par和.opt文件。
在此之后，xtrabackup将使用LOCK BINLOG进行备份，以阻止显示主/从状态所报告的所有可能更改二进制日志位置或Exec_Master_Log_Pos或Exec_Gtid_Set(即与复制从库上的当前SQL线程状态对应的主库二进制日志坐标)的操作。然后xtrabackup将完成重做日志文件的复制，并获取二进制日志坐标。完成此操作后，xtrabackup将解锁二进制日志和表。
最后，将二进制日志位置打印到STDERR，如果一切正常，xtrabackup将退出返回0
注意，xtrabackup的STDERR没有写在任何文件中。您必须将其重定向到一个文件，例如，xtrabackup 选项2> backupout.log。
它还将在备份目录中创建以下文件：
在准备阶段，Percona XtraBackup使用复制的事务日志文件对复制的数据文件执行崩溃恢复。完成之后，数据库就可以恢复和使用了。
备份后的MyISAM表和InnoDB表最终会保持一致，因为在准备(恢复)过程之后，InnoDB的数据会向前滚到备份完成的地方，而不是回滚到备份开始的地方。这个时间点与具有读锁的flush tables表匹配，因此MyISAM数据和准备好的InnoDB数据是同步的。
xtrabackup和innobackupex工具都提供了前面解释中没有提到的许多特性。每个工具的功能在手册中有更详细的说明。简单地说，这些工具允许您使用各种组合的数据文件复制、日志文件复制和对数据应用日志来执行流备份和增量备份等操作。
2.6 恢复还原工作
要使用xtrabackup恢复备份，您可以使用xtrabackup—copy-back或xtrabackup—move选项。
Xtrabackup将从my.cnf中读取datadir、innodb_data_home_dir、innodb_data_file_path、innodb_log_group_home_dir变量，并检查目录是否存在。
它将首先复制MyISAM表、索引等(.frm、. mrg、. myd、. myi、. trg、. trn、. arm、. arz、. csm、. csv、par和.opt文件)，然后复制InnoDB表和索引，最后复制日志文件。它将保留文件的属性，当复制它们时，您可能不得不在启动数据库服务器之前，将文件的所有权更改为mysql用户，因为它们将属于创建备份的用户。
可以使用xtrabackup—move-back选项恢复备份。这个选项类似于xtrabackup——copy-back，唯一的区别是它将文件移动到目标位置，而不是复制文件。由于此选项删除了备份文件，因此必须谨慎使用。当没有足够的空闲磁盘空间来容纳数据文件和它们的备份副本时，它非常有用。
(1) innodb_data_home_dir：是InnoDB表的目录共用设置。如果没有在 my.cnf 进行设置，InnoDB 将使用MySQL的 datadir 目录为缺省目录。如下所示value是空字符串。如果value是一个空字串,可以在 innodb_data_file_path 中设定绝对路径
(2) innodb_data_file_path：单独指定数据文件的路径与大小。数据文件的完整路径由 innodb_data_home_dir 与这里所设定值的组合。 文件大小以 MB 单位指定。因此在文件大小指定后必有“M”。 InnoDB 也支持缩写“G”。系统会默认在 MySQL 的 datadir 目录下创建一个 12MB 自扩充(auto-extending)的数据文件 ibdata1。
例如：创建一个数据文件sales，初始大小为100MB，并希望在每次达到当前大小限制时，自动增加8MB,但是文件不超过1GB，可以使用如下配置：
innodb_data_home_dir =
innodb_data_file_path = /data/sales:100M:autoextend:8M: max:1GB
(3) innodb_log_group_home_dir：InnoDB 日志文件的路径。必须与 innodb_log_arch_dir 设置相同值。 如果没有明确指定将默认在 MySQL 的 datadir 目录下建立两个 5 MB 大小的 ib_logfile... 文件。
