mysql二进制日志恢复数据库遇到了一点疑问

[feiandxs]

今天发现数据库被人侵入web，然后drop database了。
mysql两台，主主结构。

不要问为什么没有冷备份，世事无常。
之前有冷备份，因为发现同步出错，于是从A机器导出一份sql到B机器，从B机器导入，然后根据A的master位置进行了slave同步，一切ok。
现在恢复数据，我只能create database后，从冷备份导入sql文件，然后试图根据当时的做slave的记录处开始，start，打算到日志里的drop database前一步就stop，然后跳过去重新开始。
然后遇到错误
Duplicate entry '89b2dddbdce21f6c4f9c724bbff77be6' for key 'hashid'
主键错误了。。。
自增字段出现了问题。因为是主主结构，两边都有写入数据，所以我在my.cnf里做了类似
A
auto_increment_offset = 1
auto_increment_increment = 2

B
auto_increment_offset = 2
auto_increment_increment = 2
这样的设置，两边写入的自增字段是不一样的。我不是很明白二进制日志的工作原理，显然两台机器上的日志文件肯定是不一样的。在我的理解里，日志文件不一样，实现的同步只是传输了sql的操作，而并不是把每一步操作都会在两边的日志里记录一下？一台机器上的日志只会记录这台机器自己的操作。。。因为一台机器的日志里有drop database，另外一台就没有，但两台机器上的库可是都没了的。
我不知道是不是我理解有问题。
但总之现在在恢复的时候，从提示上来看，显然日志并没能完全记录操作，不然怎么会提示主键 自增字段的错误呢。

难道说，需要我在两台机器上都先导入冷备份数据，做好同步设定，然后再开始分别执行对应机器上的binlog恢复吗？然后我只需要在有drop database记录的机器上，跳过drop database这一步，它也不会对另外一台机器发送这个操作，然后再跳过去就可以？

或者假如有人可以帮忙解决的话，这边我可以和客户协商下，稍微付一些劳务费用。谢谢了。

mail: [email protected]


唉，学艺不精的报应啊。

[qsun]

如果是statement based replication的话，
master-master备份两边的binlog是一样的，根据server-id跳过对应的binlog statement。所以drop database肯定两边的binlog都是有的，

回复的时候从一个server恢复就可以了，不用管太多。

你如果有之前的全备份就简单了（尤其是有--master-data=1的时候）。你可以找一下，有一个工具叫做mysqlbinlog(http://dev.mysql.com/doc/refman/5.0/en/mysqlbinlog.html)可以把binary log解析成SQL，这样你可以人工找到drop database的binlog ID，然后START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

[qsun]

我仔细看了一下你的思路，我觉得在现在这个情况下，应该把master-master拆掉，然后建立一台slave，搭在剩下的master上，然后用 start slave until master_log_file 恢复，接着在确认server-id的情况下，重新设置master-master。

[qsun]

另外，你说
"我不是很明白二进制日志的工作原理，显然两台机器上的日志文件肯定是不一样的。"
这是不对的，是一样的。所以master-master可以在往下接slave。

[BOYPT]

binlog是原始操作数据，自增id是要写进去库时候才开始的，所以你的id怎么自增关系不大。
2楼的思路应该对的了。

[fire9]

@feiandxs 需要的话我可以帮你。gtalk [email protected]

[kernel1983]

长知识了, 第一次听说master-master备份, 果然群众的智慧是无限的