作为一名DBA需要有着严谨的工作态度。
两台测试DB Server A, Server B， 默认存储引擎InnoDB.有这样一个需求：需要将A中所有的表结构同步到B中。当时是这样做的： mysqldump -no-data......
导出mysql表的文件后结果又将这些文件应用到了Server A 中，可想而知A中的 data已经被清空啦。由于是测试DB，数据量不大，用备份+binlog完全可以恢复的过来。但处于谨慎，得出第一个总结：对于新增加的表或者修改表结构的情况，要应用到其他DB的话，最好使用上 --skip-add-drop-table(宁原有重复表的报错，也不要产生删除数据的情况)
这时候我们另一个热心长的同学，将MySQL重启啦。少了一个binlog日志文件。当时心想，数据肯定会丢失一部分。丢失binlog日志的原因是由于设置了expire_logs_days(binlog在多久之后没有改动的话会被删除)。由此得出第二个总结：由于设置expire_logs_days 无法确定文件删除的具体日期，改为purge binary logs 方式进行手动删除。对于线上主从复制的情况，更应如此，原先设置的expire_logs_days=15（需要检查 各个slave应用binlog 的具体位置）
在将binlog应用到DB中时，报duplicate key的错误而中断。引起的原因是 原来的表中某个字段只是普通索引，后来改为非唯一索引。没有办法只好手动修改从binlog解析出的文件。由此得出第三个结论：为了防止在 有schema 变更之后 恢复数据时发生错误，可以考虑每天进行flush logs 一次。将范围缩减到最小。mysqlbinlog 进行解析的时候 可以单个文件进行解析。 可以利用 confluence 类西的工具将 对表的变更做实时更新记录。对自己的DB有充分的掌握。
最终还是我们需要多总结，态度很重要，形成一个良好的规范。
2012-10-24 15：40
对于误删除表空间的情况，可以参考：
http://hcymysql.blog.51cto.com/5223301/1004810
误删除数据可以参考使用taobao 数据闪回方案！
http://www.penglixun.com/tech/database/mysql_flashback_feature.html
http://www.taobaodba.com/html/1430_mysql%E7%9A%84%E6%95%B0%E6%8D%AE%E6%81%A2%E5%A4%8D.html
本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/1035828，如需转载请自行联系原作者
