对MySQL中误操作的思考

作为一名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有充分的掌握。

最终还是我们需要多总结，态度很重要，形成一个良好的规范。

本栏目更多精彩内容：http://www.bianceng.cn/database/MySQL/

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!