MySQL数据库备份与恢复

  在使用MySQL的过程中，我们免不了数据的备份与恢复，数据库的迁移等操作，针对不同的情形，可以选取不同的方案。还记得之前GitLab删库事件吗？在那么多牛逼的工程师力挽狂澜下，最后还是丢失6小时的数据，已经是损失最小了。多么惨痛的教训，也是对运维工程师、数据库管理员等朋友的一次经典案例，所以我们不仅要制定合理的数据备份计划，同时还要保证备份数据的可恢复性，整个过程要适当的演练。避免备份机制出现意外情况。

  本文主要是介绍不同的备份方式的原理和特点，例如物理备份、逻辑备份、联机备份、脱机备份等。相互比较，分析总结，更好的选择适合自己的备份方式与计划。

物理备份

  所谓物理备份就是原始数据在操作系统上呈现什么样的形式，备份出来就是什么样，这种方式纯属I/O型的备份方案，备份形式上就是将组成数据库的数据文件、配置文件、日志文件等相关文件，复制到其他路径或者其他主机上。常用的方法有 （cp、rsync等），一般情况下需要停止mysql服务或者锁表，恢复比较快。
适用场景：大型、重要、出现故障时需要快速恢复的场景
物理备份的特点：
    备份数据中包括完整的数据库目录和数据文件，对于MySQL来说,就是指MySQL的数据目录
    物理备份一般都比较快，因为基本都是I/O复制，不存在数据转换。
    备份时的粒度是整个数据库服务级，某些存储引擎有时也能吃吃更新的表粒度，备份粒度也决定了恢复的粒度，因此对备份策略也会有影响。
    备份数据中可以包含关联文件，例如日志文件、配置文件等
    对于像MEMORY引擎表这类对象，由于其数据并不保存在磁盘中，而是保存在内存中，因此不会备份，仅能备份相关的表结构。但是可以利用工具备份，例如MySQL Enterprise Backup（企业级产品）工具备份内存表中的数据。
    备份能够轻易恢复到配置类似的机器上。
    对于物理备份操作来说，一般是在未启动的状态下进行，如果MYSQL服务已经启动，那就只能对相关的系统对象进行适当的锁定，保证数据库的数据不会不会改变，否则备份的数据可能不是完整数据，恢复后，可能存在丢失数据的情况

 执行物理备份的方式
        操作系统层：cp rsync  scp  tar 
        第三方工具：mysqlbackup   MySQL Enterprise Backup  MyISAM引擎专用 mysqlhotcopy

逻辑备份

  所谓的逻辑备份就是将数据库定义语言和所有的数据转换成SQL文件存储，一般有mysqldump等方式，这种方式比较适合小数据量的库和表，当数据量达到一定量后，备份、恢复时间长，同时会在备份过程中锁表，影响比较大。
适用场景：小型、以便在其他服务器上面进行恢复的情景
逻辑备份特点：
    备份集是基于查询MySQL服务获得数据库的结构和内容信息
    备份速度慢于物理备份
    数据备份文件比物理备份更大，因为是以纯文本报存，数据没有经过任何压缩，一般是采用gzip  或者tar等方式压缩
    备份和恢复的粒度比较灵活，可以是服务级（所有数据库），也可以是某个库中的某些表，甚至可以是某张表中的部分数据
    备份集不包括日志和配置文件或者其他与数据库相关的日志文件，这些文件都需要手动备份
    备份集通用性比较强，不仅仅是针对MySQL数据库，甚至将备份文件拿到其他关系型数据库平台上恢复
    MySQL原始的逻辑备份工具包括mysqldump，甚至 select into  outfile  也可以算在内。这些工具可以支持所有的存储引擎甚至Memory，这种存储在内存中的引擎
    恢复时，备份的SQL文件，可以用mysql 命令导入，也可以在登录mysql后使用source命令加载。对于部分定界文件可以使用 load  data  infile  或者mysqlimport导入。
   除了物理备份与逻辑备份，某些文件系统支持创建快照，但是MYSQL是通过第三方解决方案实现，例如 VEritas LVM 或者ZFS等。