一.概述
物理备份和恢复又分为冷备份和热备份。与逻辑备份相比,它最大优点是备份和恢复的速度更快。因为物理备份的原理都是基于文件的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... 文件。