①为什么要备份：
1) 灾难恢复(如硬件故障，失手删库等)
2) 人们想法改变，想恢复回原来的
3) 审计，需要知道某个时间点这部分数据是否有bug
4) 测试，删了测，测了删
②定义恢复需求：
注：复制不是备份，只有备份才能满足备份要求。
③设计MySQL备份方案：
-- 在线备份还是离线备份： 关闭MySQL做备份是最简单 最安全的，但让服务器停机代价过大
在热备份中，往往要执行 FLUSH TABLES WITH READ LOCK 锁定，导致MySQL关闭并锁定所有的表(MyISAM下会有该问题，但用 InnoDB能避免)
-- 逻辑备份还是物理备份：
优点：可用编辑器查看文件结构、恢复简单，直接导入、可用mysqldump之类工具导入、与存储引擎无关、有助于避免数据损坏
缺点：需要更多 CPU周期、比数据库本身 文件更大、无法保证导出还原是同样数据、需要mysql加载会很慢(需要不少恢复时间)。
物理备份：更易出错，体积更轻量
-- 备份什么：
日志文件、代码(存储过程和触发器)、复制配置(二进制文件、中继日志)、服务器配置(my.cnf)、选定的系统文件(cron文件、脚本等)
部分备份，可能会导致所有备份无效。
建议：使用 MySQL Enterprise Backup中的增量备份特性。
二进制日志，每次备份后使用FLUSH LOGS 开始一个新的日志(这样每次都备份新的)
没有改变的表/行
所有数据，考虑到简便性，建议尽量做 全备(至少 一周一次)
-- 存储引擎和一致性：
还没插就备份好了
如果使用的非事务型(如InnoDB是)，则只能在备份时用 LOCK TABLES来 锁住所有的备份表
文件一致性：文件复制可能存在不一致性如MyISAM中.MYD和.MYI，要保证MyISAM的一致性必须：LOCAK TABLES、FLUSH TABLES。
线程设计是 并发，部分异步与 LOCK TABLES 无关。
④管理和备份二进制日志文件：
-- 用途：二进制日志有助于时间点恢复，数据回滚
-- 安全的清除过老的二进制日志： expire_log_days 告诉MySQL 定期清理日志
mysql4.1做法：
新版做法：
⑤备份数据：
-- 生成逻辑备份：逻辑备份有 SQL导出和符号分隔文件
SQL导出；phpMyAdmin,Navicat、mysqldump等工具都可以做
缺点：巨大的sql语句、单个巨大文件，成本高
符号分隔文件备份(比上面更优)：
缺点：仅用于MySQL、写权限(一般root不担心)、不覆盖存在文件
-- 文件快照：使用LVM规划快照
注：快照不等同于备份
⑥从备份中恢复：
-- 恢复物理备份：InnoDB有诸多限制，而MyISAM则可直接将物理备份复制粘贴过去。
注：准备物理备份时需 同时准备逻辑备份。
-- 还原逻辑备份：
SQL文件命令导入：
$ mysql < sakila-backup.sql
---------------------------------------------------
mysql中： SET SQL_LOG_BIN = 0;
SOURCE sakila-backup.sql
SET SQL_LOG_BIN = 0;
注：上面两种方法均性可，相比较source 报错不强退，不严谨。
压缩过，则：
$ gunzip -c sakila-backup.sql.gz | mysql
单个表则：
$ grep 'INSERT INTO `actor`' sakila-backup.sql | mysql sakila 或 $ gunzip -c sakila-backup.sql.gz | grep 'INSERT INTO `actor`' | mysql sakila
加载符号分隔文件：
优化技巧：创建一个命名管道并将解压数据流流向里面
-- 基于时间点的恢复：只要有二进制日志文件，就可以恢复任何希望的时间点。
