原文转载:
MYSQL主从结构灾难恢复策略机制设想
当数据库服务器建立好以后，我们一般为了安全以及性能考虑，对数据库建立一个主从结构配置。但是这样做了以后查询性能是得到了提高，但是数据库的安全性真的像我们想的那样，主库坏掉了可以使用从库顶上使用吗？
考虑如下一种情况：
数据库服务器不是发生故障，而是被黑客黑了，黑客将其中一个数据表删除了，只时候我们建立的从库还有作用吗？
答案是：
没有用，因为从库上也会执行主库上所执行的操作，将这个表删除了，这个表的数据在主库和从库上都不存在了，里面的数据再也回不来了。
由此我们在建立了主从服务器后还要做好数据库的备份策略，保障在数据库遭到破坏后(物理损坏或黑客破坏)，可以迅速恢复到最后一次正常的状态，使得数据的损失达到最小，同时要考虑做恢复操作所需要花费的时间（1分钟，10分钟，1小时，1天?)。
备份策略考虑
- 1. 在主库的机器上做物理备份
a.) 定期全量备份(每天，每周)
b.) 在全量备份的基础上，做每小时的增量备份。
- 2. 将主数据服务上做的数据备份拷贝传输到其他机器上。
- 3. 将备份的数据定期压缩刻盘备份。
- 4. 以上备份策略可以考虑在从库上处理，节约备份操作时对主库的资源占用。
恢复策略考虑
1. 主服务器数据被黑客篡改破坏
这个时候从库备份的数据无效，因为从库的数据也被破坏，需要重备份的数据中恢复。
情况一: 主库的机器未被黑，只是数据库被黑，数据破坏
处理方法: 停止主库服务，修改主库的my.cnf 文件使其数据库文件目录指向到备份的数据库目录，根据备份的数据重做从库数据库。
情况二: 主库的机器被黑，整个机器失去控制，同时数据被破坏。
处理方法: 启动利用其他机器上最近备份的全量数据，建立新的数据库服务。
2. 主库数据由于意外原因丢失，但是未发生数据篡改
比如主数据库机器虽未被黑客攻击，但是只是停了相关服务，未对数据做篡改破坏。
或机器由于意外原因发生物理损坏不可用，但是未有发生数据被篡改。
处理方法1: 直接使用从库切换
将从库中的一台变更为主库，更改其他从库的主库连接设置，使他们从这台新设的主库机器上复制数据。
处理方法2: 安装数据被篡改的方式处理。
策略原则
鸡蛋不能放在一个篮子中，当一个篮子坏掉了，还有其他篮子可用。
所以数据要在多处以及多种方式做备份恢复处理。
参考:
1. Mysql Slave群切换Master (from alidba)
2. 数据库的自动备份与数据库被破坏后的恢复（mysqlhotcopy）