《高性能mysql》之备份与恢复(第十五章)

①为什么要备份：

     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。     

                              而对于InnoDB的文件一致性更难，因为其 线程设计是 并发，部分异步与 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

          加载符号分隔文件：

               优化技巧：创建一个命名管道并将解压数据流流向里面

               

     -- 基于时间点的恢复：只要有二进制日志文件，就可以恢复任何希望的时间点。