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

wdcsx

作为一名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有充分的掌握。
       最终还是我们需要多总结，态度很重要，形成一个良好的规范。

-★出爺;3

学习了，不错，讲的太有道理了

懂ni

很多女明星不红的原因是因为没有张开腿*^_^*

FragranceM

男人有冲动可能是爱你，也可能是不爱，但没有冲动肯定是不爱!

loyalxuan

男人靠的住，母猪能上树!

shenyg

找到好贴不容易，我顶你了，谢了

wuliuwang

自从我变成了狗屎,就再也没有人踩在我头上了。