误操作引发对日常操作MySQL 的思考

  1. 云栖社区>
  2. 博客>
  3. 正文

误操作引发对日常操作MySQL 的思考

像教授 2017-12-31 20:45:00 浏览715
展开阅读全文

  作为一名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,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
像教授
+ 关注