Mysql备份与还原

数据的备份和还原的重要性是不言而喻，高效安全的备份恢复方案能在关键时刻帮你渡过难关。

备份
备份使用的场景
灾难还原：
  硬件故障，恶意bug，或其他原因导致数据无法继续使用。
人们改变原先的想法：
  在某个时段，人们删除了他们认为没用的数据，但是过后又发现需要用到这些数据
审查:
   你可能在应用在发现某个bug，想看看这段代码在过去运行时产生什么样的结果，或者你们公司卷入异常官司。
测试:
   在你应用需要变动时，需要搭建真是数据环境进行测试。
 等等……………..

在指定备份策略时要结合以下几个方面考虑
1. 你能承受的损失有多大： 如果需要还原到即时故障点，这个就要考虑到结合binlog来进行差异备份了
2. 在线还是离线进行备份：最简单安全的方案当然是把应用停下然后进行备份了，但是在线应用在大多数情况下是不能容忍的。在线备份才是最符合客户需求的方案
3. 逻辑备份还是裸备份：逻辑备份是数据库可以识别的格式，缺点是需要更多的CPU，有时可能比原来数据文件更大，浮点数可能产生丢失，备份数来的数据需要mysql加载并解释声明给服务器带来更多的工作量。裸备份就是原来存储在磁盘上的文件，缺点有：裸备份通常比逻辑备份更大，裸备份受限于跨平台应用。
4. 要备份什么： 不要忘记一些不显眼的数据 如binlog和事务日志。代码，配置信息（服务器，复制），相关操作系统的配置（如cron任务，用户信息）
5. 增量备份： 对于大数据量的应用来说，全备加增量备份通常是个不错的解决方案。
6. 存储引擎的一致性：一个数据无法保持的一致的备份在很多时候会变得毫无意义。如果没有采用事务性的存储引擎，你只能采用锁住所有表然后进行备份来保证一致性。Innodb引擎显得相对高明一些，MVCC功能通过记录即使点的事务ID能保证通过开启一个事务（--single-transaction）来完成一致性备份过程。文件一致性则要注意到操作系统或数据引擎采用的异步写带来的问题。
7. 复制：复制在我们眼里往往是提供冗余和应用扩展的一个工具，它同样也能协助进行备份，比如为了不影响主服务器的性能我们往往可以将备份移到备份服务器上来，当然你要确保读取到主服务器的日志的位置，并且还要排除临时表的影响。
8. 管理和备份二进制文件：要保留多长时间的二进制文件，是否需要改变参数以避免出问题时数据库和操作系统的缓写带来的数据丢失的隐患
9. 二进制日志格式： 除了以前版本语句级别的二进制日志外，在mysql5.1版本还提供了行级别日志和混合级别日志。
10. 安全清理旧日志：指定日志作废计划，这需要在磁盘空间占用和数据保存的中进行权衡

常用的备份方式
Mysqldump
Select into outfile
MK-parallel-dump（多线程dump）
文件系统快照：结合lvm，进行快照后结合写时备份来提高备份效率

 

还原

应该在平时就反复进行还原演练，以验证备份的有效性，并在关键时刻能高效的派上用场

还原方式
   裸备份文件
   逻辑备份文件
   加载定界符的文件

高级还原的方式
  用延迟复制来进行快速还原：通过slave延迟执行来使你在错误的sql在slave上执行之前来解决问题。
日志服务器还原： 日志服务器对于还原单张或者个别表是个不错选择，通过两台服务器相互配合，在还原的服务器上设置replicate-do-table 来还原指定的表。
权限限制还原：  和上面日志服务器还原有些接近，如果只还原某些库或表可以只给还原帐号写入权限，来保证备份文件中的其他数据不会被写入
  Innodb 还原： 通过innodb-force-recovery的设置可以实现有损的数据修复和恢复

常用备份工具的特点