逻辑备份与恢复测试
什么样的备份是数据库逻辑备份
数据库在返回数据给我们使用的时候都是按照我们最初所设计期望的具有一定逻辑关联格式的形式一条一条数据来展现的，具有一定的商业逻辑属性，而在物理存储的层面上数据库软件却是按照数据库软件所设计的某种特定格式经过一定的处理后存放。
数据库逻辑备份就是备份软件按照我们最初所设计的逻辑关系，以数据库的逻辑结构对象为单位，将数据库中的数据按照预定义的逻辑关联格式一条一条生成相关的文本文件，以达到备份的目的。
常用的逻辑备份
逻辑备份可以说是最简单，也是目前中小型系统最常使用的备份方式。在MySQL 中我们常用的逻辑备份主要就是两种，一种是将数据生成可以完全重现当前数据库中数据的INSERT 语句，另外一种就是将数据通过逻辑备份软件，将我们数据库表数据以特定分隔符进行分隔后记录在文本文件中。
生成INSERT 语句备份
在MySQL 数据库中，我们一般都是通过MySQL 数据库软件自带工具程序中的mysqldump来实现声称INSERT 语句的逻辑备份文件。
如何保证在导出insert语句的过程中确保数据不会发生修改？？？？？？
解决方法1：同一时刻取出所有数据。
答：在同一个事物中，数据库是可以做到所读取的数据均处于同一个时间点的，因此，对于事物支持的存储引擎，例如：Innodb或BDB等，通过控制将整个备份过程控制在同一个事物中来达到备份数据的一致性和完整性，通过mysqldump命令的—single-transaction选项来支持该功能。
解决方法2：数据库中的数据处于静止状态。
答：对于第二种情况我想大家首先想到的肯定是将需要备份的表锁定，只允许读取而不允许写入。是的，我们确实只能这么做。我们只能通过一个折衷的处理方式，让数据库在备份过程中仅提供数据的查询服务，锁定写入的服务，来使数据暂时处于一个一致的不会被修改的状态，等mysqldump 完成备份后再取消写入锁定，重新开始提供完整的服务。mysqldump 程序自己也提供了相关选项如“--lock-tables”和“--lock-all-tables”，在执行之前会锁定表，执行结束后自动释放锁定。这里有一点需要注意的就是，“--lock-tables”并不是一次性将需要dump 的所有表锁定，而是每次仅仅锁定一个数据库的表，如果你需要dump 的表分别在多个不同的数据库中，一定要使用“--lock-all-tables”才能确保数据的一致完整性。
生成特定格式的纯文本备份数据文件备份
将数据库中的数据以特定分隔字符将数据分隔记录在文本文件中，以达到逻辑备份的效果。这样的备份数据与INSERT 命令文件相比，所需要使用的存储空间更小，数据格式更加清晰明确，编辑方便。但是缺点是在同一个备份文件中不能存在多个表的备份数据，没有数据库结构的重建命令。对于备份集需要多个文件，对我们产生的影响无非就是文件多了维护和恢复成本增加，但这些基本上都可以通过编写一些简单的脚本来实现
在MySQL 中一般都使用以下两种方法来获得可以自定义分隔符的纯文本备份文件：
A.通过执行SELECT ... TO OUTFILE FROM ...命令来实现
在MySQL 中提供了一种SELECT 语法，专供用户通过SQL 语句将某些特定数据以指定格式输出到文本文件中，同时也提供了实用工具和相关的命令可以方便的将导出文件原样再导入到数据库中。
B. 通过mysqldump 导出
mysqldump 还同样能实现上面“SELECT ... TO OUTFILE FROM ...”所实现的功能，而且同时还会生成一个相关数据库结构对应的创建脚本，即一个数据文件、一个创建数据库结构的脚本文件。
逻辑备份恢复方法
INSERT 语句文件的恢复
如果需要做完全恢复，那么我们可以通过使用“mysql < backup.sql”直接调用备份文件执行其中的所有命令，将数据完全恢复到备份时候的状态。如果已经使用mysql 连接上了MySQL，那么也可以通过在mysql 中执行“source /path/backup.sql”或者“\. /path/backup.sql”来进行恢复。
纯数据文本备份的恢复
恢复起来会稍微麻烦一点，需要一个表一个表通过相关命令来进行恢复，当然如果通过脚本来实现自动多表恢复也是比较方便的。恢复方法也有两个，一是通过MySQL 的“LOAD DATA INFILE”命令来实现，另一种方法就是通过MySQL提供的使用工具mysqlimport 来进行恢复。
物理备份与恢复测试
什么样的备份是数据库物理课备份
数据库的物理备份就是对数据库的物理对象所做的备份。数据库的物理对象主要由数据库的物理数据文件、日志文件以及配置文件等组成。在MySQL 数据库中，除了MySQL 系统共有的一些日志文件和系统表的数据文件之外，每一种存储引擎自己还会有不太一样的物理对象
MySQL物理备份所需文件
MyISAM 存储引擎
MyISAM 存储引擎的所有数据都存放在MySQL 配置中所设定的“datadir”目录下。在各个数据库中每一个MyISAM 存储引擎表都会有三个文件存在，分别为记录表结构元数据的“.frm”文件，存储表数据的“.MYD”文件，以及存储索引数据的“.MYI”文件。由于MyISAM 属于非事务性存储引擎，所以他没有自己的日志文件。所以MyISAM 存储引擎的物理备份，除了备份MySQL 系统的共有物理文件之外，就只需要备份上面的三种文件即可。
Innodb 存储引擎
Innodb 存储引擎属于事务性存储引擎，而且存放数据的位置也可能与MyISAM 存储引擎有所不同，这主要取决于我们对Innodb 的相关配置所决定。决定Innodb 存放数据位置的配置为”innodb_data_home_dir”和”innodb_data_file_path”和”innodb_log_group_home_dir”这三个目录位置指定参数，以及另外一个决定Innodb 的表空间存储方式的参数“innodb_file_per_table”。前面三个参数指定了数据和日志文件的存放位置，最后一个参数决定Innodb 是以共享表空间存放数据还是以独享表空间方式存储数据
如果使用了共享表空间的存储方式， 那么Innodb 需要备份备份“innodb_data_home_dir”和“innodb_data_file_path”参数所设定的所有数据文件，“datadir”中相应数据库目录下的所有Innodb 存储引擎表的“.frm”文件；
如果使用了独享表空间，那么我们除了备份上面共享表空间方式所需要备份的所有文件之外，我们还需要备份“datadir”中相应数据库目录下的所有“.idb”文件，该文件中存放的才是独享表空间方式下Innodb 存储引擎表的数据。
Innodb 是事务性存储引擎，他是需要undo 和redo 信息的，而不管Innodb 使用的是共享还是独享表空间的方式来存储数据，与事务相关的undo 信息以及其他的一些元数据信息，都是存放在”innodb_data_home_dir” 和“innodb_data_file_path”这两个参数所设定的数据文件中的。所以要想Innodb 的物理备份有效，“innodb_data_home_dir”和“innodb_data_file_path”参数所设定的数据文件不管在什么情况下我们都必须备份。
此外，除了上面所说的数据文件之外，Innodb 还有自己存放redo 信息和相关事务信息的日志文件在“innodb_log_group_home_dir”参数所设定的位置。所以要想Innodb 物理备份能够有效使用，我们还比需要备份“innodb_log_group_home_dir”参数所设定的位置的所有日志文件。
NDB Cluster 存储引擎
NDB Cluster 存储引擎（其实也可以说是MySQL Cluster）的物理备份需要备份的文件主要有一下三类：
1、元数据（Metadata）：包含所有的数据库以及表的定义信息；
2、表数据（Table Records）：保存实际数据的文件；
3、事务日志数据（Transaction Log）：维持事务一致性和完整性，以及恢复过程中所需要的事务信息。
当然，相关的配置文件，尤其是管理节点上面的配置信息，同样也需要备份。
各存储引擎常用物理备份方法
由于不同存储引擎所需要备份的物理对象（文件）并不一样，且每个存储引擎对数据文件的一致性要求也不一样所以各个存储引擎在进行物理备份的时候所使用的备份方法也有区别。当然，如果是要做冷备份（停掉数据库之后的备份），我们所需要做的事情都很简单，那就是直接copy 所有数据文件和日志文件到备份集需要存放的位置即可，不管是何种存储引擎都可以这样做。
实际应用环境中，我们只能在数据库提供服务的情况下来完成数据库备份。这也就是我们俗称的热物理备份了：
MyISAM 存储引擎
只要将MyISAM 的物理文件copy 出来即可，虽然MyISAM 存储引擎没有事务支持，对数据文件的一致性要求没有Innodb 之类的存储引擎那么严格，但是MyISAM存储引擎的同一个表的数据文件和索引文件之间是有一致性要求的。当MyISAM 存储引擎发现某个表的数据文件和索引文件不一致的时候，会标记该表处于不可用状态，并要求你进行修复动作，当然，一般情况下的修复都会比较容易。
所以我们自己必须至少保证数据库在备份时候的数据是处于某一个时间点的，这样就要求我们必须做到在备份MyISAM 数据库的物理文件的时候让MyISAM 存储引擎停止写操作，仅仅提供读服务，其根本实质就是给数据库表加锁来阻止写操作。
mysqlhotcopy，这个程序就是专门用来备份MyISAM 存储引擎的。不过如果你有除了MyISAM 之外的其他非事务性存储引擎，也可以通过合适的参数设置，或者微调该备份脚本，也都能通过mysqlhotcopy 程序来完成相应的备份任务，基本用法如下：
mysqlhotcopy db_name[./table_regex/] [new_db_name | directory]
mysqlhotcopy 是一个用perl 编写的使用程序，其主要实现原理实际上就是通过先LOCK住表，然后执行FLUSH TABLES 动作，该正常关闭的表正常关闭，将该fsync 的数据都fsync，然后通过执行OS 级别的复制（cp 等）命令，将需要备份的表或者数据库的所有物理文件都复制到指定的备份集位置。此外，我们也可以通过登录数据库中手工加锁，然后再通过操作系统的命令来复制相关文件执行热物理备份，且在完成文件copy 之前，不能退出加锁的session（因为退出会自动解锁），例如：
FLUSH TABLES WITH READ LOCK;
cp -R test /tmp/backup/test
unlock tables;
Innodb 存储引擎
Innodb 存储引擎由于是事务性存储引擎，有redo 日志和相关的undo 信息，而且对数据的一致性和完整性的要求也比MyISAM 要严格很多，所以Innodb 的在线（热）物理备份要比MyISAM 复杂很多。
需要花钱购买Innodb 存储引擎的开发者（Innobase 公司）开发了一款名为ibbackup 的商业备份软件才能备份。
NDB Cluster 存储引擎
NDB Cluster 存储引擎也是一款事务性存储引擎，和Innodb 一样也有redo 日志。NDB Cluter 存储引擎自己提供了备份功能，可以通过相关的命令实现。当然，停机冷备的方法也是有效的。
各存储引擎常用物理备份恢复方法
MyISAM 存储引擎
如果是通过停机冷备份或者是在运行状态通过锁定写入操作后的备份集来恢复，仅仅只需要将该备份集直接通过操作系统的拷贝命令将相应的数据文件复制到对应位置来覆盖现有文件即可。
如果是通过mysqlhotcopy 软件来进行的在线热备份，而且相关的备份信息也记录进入了数据库中相应的表，其恢复操作可能会需要结合备份表信息来进行恢复。
Innodb 存储引擎
对于冷备份，Innodb 存储引擎进行恢复所需要的操作和其他存储引擎没有什么差别，同样是备份集文件（包括数据文件和日志文件）复制到相应的目录即可。但是对于通过其他备份软件所进行的备份，就需要根据备份软件本身的要求来进行了。比如通过ibbackup来进行的备份，同样也需要通过他来进行恢复才可以。
NDB Cluster 存储引擎
对于停机冷备，恢复方法和其他存储引擎也没有太多区别，只不过有一点需要特别注意的就是恢复的时候必须要将备份集中文件恢复到对应的数据节点之少，否则无法正确完成恢复过程。而通过NDB Cluster 所提供的备份命令来生成的备份集，需要使用专用的备份恢复软件ndb_restore 来进行。