MySQL性能调优与架构设计(四)—— 备份与恢复

前言

1. 数据库的备份和恢复一直是DBA工作中最为重要的一部分，也是基本工作之一。
2. 任何正式环境的数据库都必须有完整的备份计划和恢复测试，本章内容将主要介绍 MySQL数据库的备份与恢复相关内容。

数据库备份使用场景

1. 数据库的备份很大程度上的作用，就是当我们的数据库因为某些原因而造成部分或者全部数据丢失后，方便找回丢失的数据。
2. 但是不同类型的数据库备份，所能应付情况是不一样的，而且，数据库的备份同时还具有其他很多的作用。

3. 下面列举一下需要用到数据库备份的一些比较常见的情况

   （1）数据丢失应用场景：
       【1】人为操作失误造成某些数据被误操作；
       【2】软件BUG造成数据部分或者全部丢失；
       【3】硬件故障造成数据库数据部分或全部丢失；
       【4】安全漏洞被入侵数据被恶意破坏； 
   （2）非数据丢失应用场景 ：
       【1】特殊应用场景下基于时间点的数据恢复； 
       【2】开发测试环境数据库搭建
       【3】相同数据库的新环境搭建； 
       【4】数据库或者数据迁移； 

逻辑备份与恢复测试

一、逻辑备份前言

1. 大家都知道，数据库在返回数据给我们使用的时候，都是按照我们最初设计期望的具有一定逻辑关联格式的形式一条一条数据来展现的，具有一定的商业逻辑属性，而在物理存储的层面上数据库软件却是按照数据库软件所设计的某种特定格式经过一定的处理后存放。
2. 数据库逻辑备份就是备份软件按照我们最初设计的逻辑关系，以数据库的逻辑结构对象为单位，将数据库中的数据按照预定义的逻辑关联格式一条一条生成相关的文本文件，以达到备份的目的。
3. 逻辑备份可以说是最简单，也是目前中小型系统最常用的备份方式。
4. 在mysql中我们常用的逻辑备份主要就是两种，一种是将数据生成可以完全重现当前数据库中数据的INSERT语句，另外一种就是将我们数据库表数据通过逻辑备份软件，以特定分隔符进行分隔后记录在文本文件中。

二、常用的逻辑备份

1. 生成INSERT语句备份

   （1）在mysql中，我们一般都是通过mysql数据库软件自带工具程序中的mysqldump来实现生成INSERT语句的逻辑备份文件。
   （2）基本使用方法：Dumping definition and data mysql database or table
   mysqldump [OPTIONS] database [tables] 
   OR   mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...] 
   OR   mysqldump [OPTIONS] --all-databases [OPTIONS] 
   （3）由于mysqldump的使用方法比较简单，大部分需要的信息都可以通过运行“mysqldump --help”而获得。
   （4）这里我只想结合MySQL数据库的一些概念原理和大家探讨一下当我们使用mysqldump来做数据库逻辑备份的时候有些什么技巧以及需要注意一些什么内容。
   （5）我们都知道，对于大多数使用数据库的软件或者网站来说，都希望自己数据库能够提供尽可能高的可用性，而不是时不时的就需要停机停止提供服务。
   （6）因为一旦数据库无法提供服务，系统就无法再通过存取数据来提供一些动态功能。
   （7）所以对于大多数系统来说如果要让每次备份都停机来做可能都是不可接受的，可是mysqldump程序的实现原理是通过我们给的参数信息加上数据库中的系统表信息来一个表一个表获取数据然后生成INSERT语句再写入备份文件中。
   （8）这样就出现了一个问题，在系统正常运行过程中，很可能会不断有数据变更的请求正在执行，这样就可能造成在ymsqldump备份出来的数据不一致。
   （9）也就是说备份数据很可能不是同一时间点的数据，而且甚至可能都没办法满足完整性约束。
   （10）这样的备份集对于有些系统来说可能并没有太大问题，但是对于有些对数据的一致性和完整性要求比较严格系统来说问题就大了，就是一个完全无效的备份集。
   （11）对于如此场景，我们该如何做？我们知道，想数据库中的数据一致，那么只有两种情况下可以做到：
       【1】同一时刻取出所有数据
            「1」对于第一种情况，我们可能会问，这可能吗？不管如何，只要有两个以上的表，就算我们如何写程序，都不可能做到完全一致的取数时间点。
            「2」是的，我们确实无法通过常规方法让取数的时间点完全一致，但是大家不要忘记，在同一个事务中，数据库是可以做到所读取的数据是处于同一个时间点的。
            「3」所以，对于事务支持的存储引擎，如Innodb或者BDB等，我们就可以通过控制将整个备份过程控制在同一个事务中，来达到备份数据的一致性和完整性，而且mysqldump程序也给我们提供了相关的参数选项来支持该功能，就是通过“--single-transaction”选项，可以不影响数据库的任何正常服务。
       【2】数据库中的数据处于静止状态。
            「1」此种情况，需要将备份的表锁定，只允许读取而不允许写入。
            「2」让数据库在备份过程中仅提供数据的查询服务，锁定写入的服务，来使数据暂时处于一个一致的不会被修改的状态，等mysqldump完成备份后再取消写入锁定，重新开始提供完整的服务。
            「3」mysqldump程序自己也提供了相关选项如“--lock-tables”和“--lock-all-tables”，在执行之前会锁定表，执行结束后自动释放锁定。
            「4」这里有一点需要注意，“--lock-tables”并不是一次性将需要dump的所有表锁定，而是每次仅仅锁定一个数据库的表，如果你需要备份的表在不同的数据库中，一定要使用“--lock-all-tables”才能确保数据的一致完整性。
   （12）一个非常有用的参数“--master-data[=value]”
       【1】当通过mysqldump生成INSERT语句的备份文件的时候，有一个非常有用的选项可以供我们使用，那就是“--master-data[=value]”。
       【2】当添加了“--master-data=1”的时候，mysqldump会将当前mysql使用到binlog日志的名称和位置记录到dump文件中，并且是以CHANGE_MASTER语句的形式记录，如果仅仅只是使用“--master-data”或者“--master-data=2”，则CHANGE_MASTER语句会以注释形式存在。
       【3】这个选项在实时slave的在线搭建的时候是非常有用的，即使不是进行在线搭建slave，也可以在某些情况下做恢复的过程中通过备份的binlog做进一步恢复操作。
   （13）参数“--where=where-condition”
       【1】在某些场景下，我们可能只是为了将某些特殊的数据导出到其他数据库中，而又不希望通过先建临时表的方式来实现，我们还可以通过mysqldump的“--where=where-condition”来实现；
       【2】此参数只能在只dump一个表的情况下使用
   （14）其他参数：
       【1】“no-data“参数仅仅dump数据库结构创建脚本
       【2】“--no-create-info“去掉dump文件中创建表结构的命令

2. 生成特定格式的纯文本备份数据文件备份

   （1）除了生成INSERT命令来做逻辑备份之外，我们还可以通过另外一种方式将数据库中的数据以特定分隔符将数据分隔记录在文本文件中，以达到逻辑备份的效果。
   （2）这样的备份数据与INSERT命令文件相比，所需要使用的存储空间更小，数据格式更加清晰明确，编辑方便。
   （3）缺点是同一个备份文件中不能存在多个表的备份数据，没有数据库结构的重建命令。
   （4）对于备份集需要多个文件，对我们产生的影响就是文件多了维护和恢复成本增加，但这些基本上都可以通过编写一些简单的脚本来实现。
   （5）生成这样的备份集方法：
       【1】通过执行SELECT ... TO OUTFILE FROM ...命令来实现
            「1」mysql中提供了一种SELECT语法，专供用户通过sql语句将某些数据以指定格式输出到文本文件中，同时也提供了实用工具和相关命令可以方便的将导出文件原样再倒入到数据库中。
            「2」该命令有几个参数需要注意：
                 《1》实现字符转义功能的“FIELDS ESCAPED BY ['name']”将语句中需要转义的字符进行转义；
                 《2》可以将字段的内容包装起来的“FIELDS [OPTIONALLY] ENCLOSED BY 'name'”，如果不使用“OPTIONALLY”则包括数字类型的所有类型数据都会被“包装”，使用“OPTIONALLY”之后，则数字类型的数据不会被指定字符“包装”。 
                 《3》通过"FIELDS TERMINATED BY"可以设定每两个字段之间的分隔符；
                 《4》而通过“LINES TERMINATED BY”则会告诉MySQL输出文件在每条记录结束的时候需要添加什么字符。
       【2】通过mysqldump导出 
            「1」可能我们都知道mysqldump可以将数据库中的数据以INSERT语句的形式生成相关备份文件，其实除了生成 INSERT语句之外，mysqldump还同样能实现上面“SELECT ... TO OUTFILE FROM ...”所实现的功能，而且同时还会生成一个相关数据库结构对应的创建脚本。
            「2」如果一次有多个表需要dump，就会针对每个表都会生成两个相对应的文件。
            「3」mysqldump -uroot -T/tmp/mysqldump test test_outfile --fields-enclosed-by=\" --fields-terminated-by=,

三、逻辑备份的恢复方法

1. 仅仅有了备份还不够，我们得知道如何去使用这些备份，现在我们就看看上面所做的逻辑备份的恢复方法。
2. 由于所有的备份数据都是以我们最初数据库结构的设计相关的形式所存储，所以逻辑备份的恢复也相对比较简单。
3. 针对两种不同的逻辑备份形式，恢复方法也稍有区别。

4. 两种逻辑备份的恢复方法：

   （1）INSERT语句文件的恢复：
       【1】对INSERT语句形式的备份文件的恢复是最简单的，我们仅仅只需要运行该备份文件中的SQL命令即可。
       【2】如果需要做完全恢复，那么我们可以通过使用“mysql < backup.sql”直接调用备份文件执行其中的所有命令，将数据恢复到备份时候的状态。
       【3】如果已经连接上了mysql，那么也可以通过在mysql中执行“source/path/backup.sql”或者“\./path/baclup.sql”来进行恢复。
   （2）纯数据文本备份的恢复：
       【1】如果是上面第二种形式的备份，恢复起来稍微麻烦一点。
       【2】需要一个表一个表通过相关命令来进行恢复，当然如果通过脚本来实现自动多表恢复也是比较方便的。
       【3】恢复方法也有两个，一是通过“LOAD DATA INFILE”命令来实现，另一种方法就是通过mysql提供的工具mysqldump来恢复。

四、逻辑备份能做什么？不能做什么？

1. 通过逻辑备份，我们可以通过执行相关sql或者命令将数据库中的相关数据完全恢复到备份时候所处的状态，而不影响不相关的数据。
2. 通过全库的逻辑备份，我们可以在新的mysql换进行完全重建出一个与备份时候完全一样的数据库，并且不受mysql所处平台的限制。
3. 通过特定条件下的逻辑备份，我们可以将某些特定数据轻松迁移（或者同步）到其他的mysql或者另外的数据库环境。
4. 通过逻辑备份，我们可以仅仅恢复备份集中的部分数据而不需要全部恢复。
5. 逻辑备份无法让数据恢复到备份时刻以外的任何一个时刻。

五、逻辑备份恢复测试

1. 周期性的进行模拟恢复测试，校验我们的备份集是否真的有效，是否确实能够按照我们的备份预期进行相应的恢复。
2. 恢复测试该如何做？总不能真的将线上的数据进行恢复？是的，线上的数据确实不能恢复，但是我们可以在测试环境或者其他地方做，校验我们的备份是否有效，是否能达到我们的预期，恢复后抽查数据人工校验即可。

物理备份与恢复测试

一、什么样的备份是数据库物理备份？

1. 既然是物理备份，那么肯定是和数据库的物理对象相对应的。就如同逻辑备份根据由我们根据业务逻辑所设计的数据库逻辑对象所做的备份一样，数据库的物理备份就是对数据库的物理对象所做的备份。
2. 数据库的物理对象主要是由数据库的物理数据文件、日志文件以及配置文件等组成。
3. 在mysql数据库中，除了mysql系统共有的一些日志文件和系统表的数据文件之外，每一种存储引擎自己还会有不太一样的物理对象。
4. 接下来我们将详细列出集中常用的存储引擎各自所对应的物理对象（物理文件），以便能够清楚的知道各种存储引擎在做物理备份的时候到底哪些文件需要备份哪些又是不需要备份的。

二、物理备份所需文件

1. MyISAM存储引擎：

   （1）MyISAM存储引擎的所有数据都存放在MySQL配置中所设定的“datadir”目录下。
   （2）实际上不管我们使用的是myisam存储引擎还是其他引擎，每一个数据库都会在“datadir”目录下有一个文件夹。
   （3）在每个数据库中每一个MyISAM存储引擎表都会有三个文件存在，分别为记录表结构元数据的“.frm”文件，存储表数据的“.MYD”文件，以及存储索引数据的“.MYI”文件。
   （4）由于MyISAM存储引擎是非事务性存储引擎，所以他没有自己的日志文件。
   （5）所以MyISAM存储引擎的物理备份，除了备份mysql系统的共有物理文件之外，就只需要备份上面的三种文件即可。

2. InnoDB存储引擎：

   （1）Innodb存储引擎是事务性存储引擎，而且存放数据的位置也可能与MyISAM存储引擎有所不同，这主要取决于我们对Innodb的相关配置所决定。
   （2）决定Innodb存放数据位置的配置为“innodb_data_home_dir”、“innodb_data_file_path”和“innodb_log_group_home_dir”这三个目录位置指定参数，以及另外一个决定innodb的表空间存储方式的参数“innodb_file_per_table”。前三个参数指定了数据和日志文件的存放位置，最后一个参数决定innodb是以共享表空间存放数据还是以独享表空间方式存储数据。
   （3）如果我们使用了共享表空间的存储方式，那么Innodb需要备份“innodb_data_home_dir”和“innodb_data_file_path”参数所设定的所有数据文件，“datadir”中相应数据库目录下的所有Innodb存储引擎表的“.frm”文件。
   （4）而如果我们使用了独享表空间，那么我们除了上面共享表空间方式所需要备份的所有文件之外，我们还需要备份“datadir”中相应数据库目录下的所有“.idb”文件，该文件存放的才是独享表空间方式下Innodb存储引擎表的数据。
   （5）这里可能有人问，既然是使用独享表空间，那么我们为什么还要备份共享表空间“才使用到”的数据文件呢？
   （6）其实这是很多人的一个共性误区，以为使用独享表空间的时候Innodb的所有信息都存放在“datadir”所设定数据库目录下的“.idb”文件中。
   （7）实际上并不是这样的，“.idb”文件中存放的仅仅是我们的表数据而已，大家都很清楚，Innodb是事务性存储引擎，他是需要undo和redo信息的，而不管Innodb是使用共享表空间还是独享表空间的方式来存储数据，与事务相关的undo信息以及其他的一些元数据信息，都是存放在“innodb_data_home_dir”和“innodb_data_file_path”这两个参数所设定的数据文件中。
   （8）除此之外，Innodb还有自己存放redo信息和相关事务信息的日志文件在“innodb_log_group_home_dir”参数所设定的位置。所以想要innodb物理备份能够有效，我们还需要备份“innodb_log_group_home_dir”参数所设定的所有日志文件。

3. NDB Cluster存储引擎：

   （1）NDB Cluster存储引擎的物理备份需要备份的文件主要有三类：
       【1】元数据（Metadata）：包含所有的数据库以及表的定义信息；
       【2】表数据（Table Records）：保存实际数据的文件；
       【3】事务日志数据（Transtaction Log）：维持事务一致性和完整性，以及恢复过程中所需要的事务信息。
   （2）不论是通过停机冷备份，还是通过NDB Cluster自行提供的在线联机备份工具，或者是第三方备份软件来进行备份，都需要备份以上三种备份物理文件才能构成一个完整有效的备份集。当然，相关的配置文件，尤其是管理节点上面配置文件，也需要备份。

三、各存储引擎常用物理备份方法

1. 由于不同存储引擎所需要备份的物理对象（文件）不一样，且每个存储引擎对数据文件的一致性要求也不一样，所以各个存储引擎在进行物理备份的时候所使用的备份方法也有区别。
2. 当然，如果我们是要做冷备份（停掉数据库之后的备份），我们所需要做的事情都很简单，那就是直接copy所有数据文件和日志文件到备份集需要存放的位置即可，不管是何种存储引擎都可以这样做。
3. 在我们的实际应用环境中，是很少有能够让我们可以停机做日常备份的情况的，我们只能在数据库提供服务的情况下来完成数据库备份。这就是我们俗称的热物理备份。

4. 各存储引擎最常用的热物理备份方法：

   （1）MyISAM存储引擎：
       【1】上面我们介绍了MyISAM存储引擎文件的物理文件比较集中，而且不支持事务没有redo和undo日志，对数据一致性的要求也并不是那么高，所以MyISAM存储引擎的物理备份也比较简单，只要将MyISAM的物理文件copy出来即可。
       【2】虽然MyISAM存储引擎没有事务支持，对数据文件的一致性没有Innodb之类的存储引擎那么严格，但是MyISAM存储引擎的同一个表的数据文件和索引文件之间是有一致性要求的。
       【3】当MyISAM存储引擎发现某个表的数据文件和索引文件不一致时，会标记该表处于不可用状态，并要求你进行修复动作，当然，一般情况下的修复比较容易。
       【4】但是，即使数据库存储引擎本身对数据文件的一致性要求并不是很严苛，我们的应用也允许数据不一致吗？我想答案肯定是否定的，所以我们必须至少保证数据库在备份时候的数据是处于某一个时间点的，这样就要求我们必须做到在备份MyISAM数据库的物理文件的时候让MyISAM存储引擎停止写操作，仅仅提供读服务，其根本实质就是给数据库表加锁来阻止写操作。
       【5】MySQL自己提供了一个程序mysqlhotcopy，这个程序是专门用来备份MyISAM存储引擎的。
       【6】不过如果你有了除MyISAM之外的其他非事务性存储引擎，也可以通过合适的参数进行设置，或者微调该备份脚本，也能通过mysqlhotcopy程序完成相应的备份任务，基本用法：mysqlhotcopy db_name[./table_regex/] [new_db_name | directory]
       【7】mysqlhotcopy除了可以备份整个数据库，指定某个表，还可以通过正则表达式来匹配某些表名来针对性的备份某些表。备份结果就是指定数据库的文件夹下包括所有指定的表的相应物理文件。
       【8】mysqlhotcopy是一个perl编写的应用程序，其主要实现原理是线LOCK住表，然后执行FLUSH TABLES动作，将该正常关闭的表正常关闭，将该fsync的数据fsyn，然后通过执行OS级别的复制（cp等）命令，将需要备份的表或者数据库的所有物理文件复制到指定的备份集位置。
       【9】此外，我们也可以通过登陆mysql中手工加锁，然后在通过操作系统的命令复制相关文件来进行热物理备份，且在完成文件copy之前，不能退出加锁的session（因为退出会自动解锁）
   （2）InnoDB存储引擎：
       【1】InnoDB存储引擎由于是事务性存储引擎，有redo日志和undo信息，而且对数据的一致性和完整性要求也比MyISAM严格很多，所以InnoDB热物理备份要比MyISAM存储引擎更复杂，一般很难通过简单的几个手工命令完成，大都是通过专门的InnoDB在线物理备份软件来完成。
       【2】InnoDB存储引擎的开发者（Innobase公司）开发了一款名为ibbackup的商业备份软件，专门实现InnoDB存储引擎数据的在线物理备份功能。
       【3】ibbackup软件可以在MySQL在线运行的状态下，对数据库中使用InnoDB存储引擎的表进行备份，不过仅限于使用InnoDB存储引擎的表。
   （3）NDB Cluster存储引擎：
       【1】NDB Cluster存储引擎也是事务性存储引擎，和InnoDB一样有redo日志。
       【2】NDB Cluster存储引擎自己提供了备份功能，可以通过相关的命令实现。当然，停机冷备的功能也是有效的。
       【3】在线联机备份的步骤：
            「1」连接上管理服务器；
            「2」在管理节点上执行“START BACKUP”命令；
            「3」在管理节点上发出备份指令后，管理节点会通知所有数据节点开始进行备份，并反馈通知结果；
            「4」管理节点在发出备份指令之前会生成一个备份号来唯一定位这次备份所产生的备份集。当各数据节点接收到备份指令之后，就会开始进行备份操作。
            「5」当所有数据节点都完成备份操作之后，管理节点才会反馈“备份完成”的信息给客户端。
       【4】由于NDB Cluster的备份，备份指令是从管理节点发起，且并不会等待备份完成就会返回，所以也没办法直接通过“Ctrl + c”或者其他方式来终端备份进程，所以NDB Cluster提供了相应的命令来中断当前正在进行的备份操作。
       【5】中断备份步骤：
            「1」登陆管理节点；
            「2」执行“ABOT BACKUP backup_id”，命令中的backup_id是之前发起备份命令时生成的备份号；
            「3」管理节点会用消息“放弃指示的备份backup_id”确认放弃请求，注意，这时候其实并没有收到数据节点对请求的实际回应。
            「4」然后管理节点才会发出中断备份的指令到所有数据节点上，当各个数据节点都中断备份并删除了当前产生的备份文件之后，才会返回“备份backup_id因***而放弃”。
            「5」至此，中断备份操作完成。
       【6】通过NDB Cluster自己的备份命令备份之后，会将前面所提到的三种文件存放在参与备份的节点上面，且被存放在三个不同的文件中，类似如下：
            「1」BACKUP-backup_id.node_id.ctl，内容包含相关的控制信息和元数据的控制文件。每个节点都会将相同的表定义保存在自己的该文件中。
            「2」BACKUP-backup_id-n.node_id.data，数据备份文件，被分成多个不同的片段来保存，在备份过程中，不同的节点将保存不同的备份数据所产生的片段，每个节点保存的文件都会有信息指明数据所属表的部分，且在备份片段文件中还包含了最后的校验信息，以确保备份能够正确恢复。
            「3」BACKUP-backup_id.node_id.log，事务日志备份文件中仅包含已提交事务的相关信息，且仅保存已在备份中保存的表上的事务，各个阶段所保存的日志信息也不一样，因为仅仅针对各节点所包含的数据记录相关的日志信息。
            「4」上面的backup_id是指备份号，不同的备份集会针对有一个不同的备份号，node_id则是指明该备份文件属于哪个数据节点，而在数据文件的备份文件中的n则是指明片段号。

四、各存储引擎常用物理备份恢复方法

1. 和之前的逻辑备份一样，光有备份是没有意义的，还需要能够备份有效的恢复才行。
2. 物理备份和逻辑备份相比最大的优势是恢复速度快，因为主要是物理文件的拷贝，将备份文件拷贝到需要恢复的位置，然后进行简单的操作即可。

3. MyISAM存储引擎：

   （1）MyISAM由于其特性，物理备份的恢复也很简单。
   （2）如果是通过停机冷备份或者是在运行状态通过锁定写入操作后的备份集来恢复，仅仅只需要将该备份集直接通过操作系统的拷贝命令将相应的数据文件复制到对应位置来覆盖现有文件即可。
   （3）如果是通过mysqlhotcopy软件来进行的在线热备份，而且相关的备份信息也记录进入了数据库中相应的表，其恢复操作可能会需要备份表信息来进行恢复。

4. InnoDB存储引擎：

   （1）对于冷备份，Innodb存储引擎进行恢复所需要的操作和其他存储引擎没有什么差别，同样是将备份集文件（包括数据文件和日志文件）复制到相应的目录即可。
   （2）但是对于通过其他备份软件所进行的备份，就需要根据备份软件本身的要求进行了。
   （3）比如通过ibbackup来进行的备份，同样也需要通过它来进行恢复才可以，具体的恢复方法请通过该软件的使用手册来进行。

5. NDB Cluster存储引擎：

   （1）对于停机冷备，恢复方法和其他存储引擎也没有太多的区别，只不过有一点需要注意的是恢复的时候必须要将备份集中的文件恢复到对应的数据节点之上，否则无法正确完成恢复过程。
   （2）而通过NDB Cluster所提供的备份命令来生成的备份集，需要使用专用的备份恢复软件ndb_restore来进行。
   （3）ndb_restore软件将从备份集中读取备份相关的控制信息，而且ndb_restore软件必须在单独的数据节点上面分别进行。所以当初备份进行过程中有多少数据节点，现在就需要运行多少次ndb_restore。
   （4）而且首次通过ndb_restore来进行恢复的话，还必须恢复元数据，也就是会重建所有的数据库和表。

备份策略的设计思路

1. 备份是否完整，是否满足要求，关键还是要看所设计的备份策略是否合理，以及备份操作是否是按照所设计的备份策略进行了。
2. 针对不同的用途，所需要的备份类型是不一样的，所以需要的备份策略也是不一样的。
3. 如为了应对在线应用的数据丢失的问题，我们的备份就需要快速恢复，而且最好是仅仅需要增量恢复就能找回所需数据。对于这类需求，最好是有在线的、且部分延迟恢复的备份用数据库。
4. 因为这样可以在最短时间内找回所需要的数据，甚至在某些硬件设备出现故障的时候，将备用库直接开发对外提供服务都可以。
5. 当然在资源缺乏的情况下，可能难以找到足够的备用硬件设备来承担这个备份责任的时候，我们也可以通过物理备份来解决，毕竟物理备份的恢复速度比逻辑备份的恢复速度快。
6. 而对于那些非数据丢失的应用场景，大多数时候恢复速度的要求并不是太高，只要可以恢复出一个完整可用的数据库就可以了。所以不论是物理备份还是逻辑备份，影响都不大。

7. 可以根据不同的需求不同的级别通过如下几个思路来设计合理的备份策略：

   （1）对于较为核心的在线应用系统，需要有在线备用主机通过 MySQL 的复制进行相应的备份，复制线程可以一直开启，恢复线程可以每天恢复一次，尽量让备机的数据延后主机在一定的时间段之内。这个延后的时间多长合适主要是根据实际需求决定，一般来说延后一天是一个比较常规的做法。 
   （2）对于重要级别稍微低一些的应用，恢复时间要求不是太高的话，为了节约硬件成本，不必要使用在线的备份主机来单独运行备用 MySQL，而是通过每一定的时间周期内进行一次物理全备份，同时每小时（或者其他合适的时间段）内将产生的二进制日志进行备份。这样虽然没有第一种备份方法恢复快，但是数据的丢失会比较少。恢复所需要的时间由全备周期长短所决定。
   （3）而对于恢复基本没有太多时间要求，但是不希望太多数据丢失的应用场景，则可以通过每一定时间周期内进行一次逻辑全备份，同时也备份相应的二进制日志。使用逻辑备份而不使用物理备份的原因是因为逻辑备份实现简单，可以完全在线联机完成，备份过程不会影响应用提供服务。
   
   （4）对于一些搭建临时数据库的备份应用场景，则仅仅只需要通过一个逻辑全备份即可满足需求，都不需要用二进制日志来进行恢复，因为这样的需求对数据并没有太苛刻的要求。

小结：

1. 总的来说，MySQL 的备份与恢复都不是太复杂，方法也比较单一。姑且不说逻辑备份，对于物理备份来说，确实是还不够完善。缺少一个开源的比较好的在线热物理备份软件，一直是 MySQL 一个比较大的遗憾，也是所有 MySQL 使用者比较郁闷的事情。
2. 当然，没有开源的备份软件使用，非开源的商业软件也还是有的，如比较著名的 Zmanda 备份恢复软件，功能就比较全面，使用也不太复杂，在商业的 MySQL 备份恢复软件市场上有较高的占有率。而且，Zmanda 同时还提供社区版本的免费下载使用。
3. 不过，稍微让人有所安慰的是 MySQL 在实际应用场景中大多是有一台或者多台 Slave 机器来作为热备的。在需要进行备份的时候通过 Slave 来进行备份也不是太难，而且通过暂时停止 Slave 上面的 SQL 线程，即可让 Slave 机器停止所有数据写入操作，然后就可以进行在线进行备份操作了。所以即使买不起商用软件或者不太想买关系也不是太大。

参考链接

https://www.cnblogs.com/jesse...