|  |      1qsun      2012-11-08 05:19:28 +08:00  1 如果是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; | 
|  |      2qsun      2012-11-08 05:21:43 +08:00 我仔细看了一下你的思路,我觉得在现在这个情况下,应该把master-master拆掉,然后建立一台slave,搭在剩下的master上,然后用 start slave until master_log_file 恢复,接着在确认server-id的情况下,重新设置master-master。 | 
|  |      3qsun      2012-11-08 05:23:41 +08:00 另外,你说   "我不是很明白二进制日志的工作原理,显然两台机器上的日志文件肯定是不一样的。" 这是不对的,是一样的。所以master-master可以在往下接slave。 | 
|      4BOYPT      2012-11-08 10:05:47 +08:00  1 binlog是原始操作数据,自增id是要写进去库时候才开始的,所以你的id怎么自增关系不大。 2楼的思路应该对的了。 | 
|  |      5fire9      2012-11-08 10:26:16 +08:00  1 @feiandxs 需要的话我可以帮你。gtalk [email protected] | 
|  |      6kernel1983      2012-11-08 18:17:38 +08:00 长知识了, 第一次听说master-master备份, 果然群众的智慧是无限的 |