二进制binlog文件恢复数据库出现主键重复的问题

Question

之前修改一个A数据库的配置文件,开启二进制文件功能,然后把A数据库关闭,把mysql目录下的a,b,c数据库文件cp到本地的其他目录,再开启A数据库,这时对A数据库的操作都会写进binlog文件中,再把cp到其他目录a,b,c数据库文件转到其他服务器的B数据库myslq目录下,过一天,A数据库生成了大概20个binlog文件(设置了binlog的max_size) 共200M的数据,把这20个binlog文件转到B的mysql目录下,B对之前A转过来得数据没有做任何操作,在B中执行恢复命令:mysqlbinlog mysql-bin.000001 ......mysql-bin.000020 |mysql -uroot -p123456
发现执行大概4分钟的时候停止,并报错： ERROR 1062 (23000) at line 53294: Duplicate entry '13243693' for key 1 是主键重复的问题,可问题是在A都已经执行成功的sql语句（保存在binlog文件中）,搬到B上做恢复怎么还会主键冲突(B对A传过了来的数据没有做任何操作),要怎么才能解决。谢谢各位朋友了。

Answer 1

清理? 什么意思 
我只把传过了的tar.gz的数据库文件直接解压到mysql目录下,然后就恢复的
要怎么清理

Answer 2

清理? 什么意思 
我只把传过了的tar.gz的数据库文件直接解压到mysql目录下,然后就恢复的
要怎么清理

Answer 3

怎么做的这么复杂啊  完全可以直接mysqldump --single-transaction -F -master-data=2做一个全备然后还原到B上  然后B change master to ..... 接上A 成为A的slave就可以了

Answer 4

把binlog_改成statment模式 就没有自增了

Answer 5

我做这个只是测试一下以后做增量备份时候的binlog恢复速度,但是一测试发现出现这个问题,有办法解决吗 苹果大哥

Answer 6

之前设置配置文件时,没有指定binlog的模式,如果默认的格式不支持自增,那问题是不是出现在这里

Answer 7

 做增量备份你得确定你的binlog确实是增量  而没有和全备有重复的数据
所以全备的时候只要要flush log一下  以产生新的binlog文件用mysqldump备份可以-F  

Answer 8

步骤： 
1.把A库停下来,修改配置文件,cp数据库文件。
2.开启A库,此时对A的操作都会写入binlog文件中,并把之前cp出的数据库文件传到B库的mysql目录下(tar包).
3.一天后,A生成20个binlog文件(200M),把这20个binlog文件cp出并传到B库的mysql目录下.
4.在B库中进行binlog恢复数据. mysqlbinlog mysql-bin.000001 .....|mysql -uroot -p 123456然后过了4分钟  停止下来
报错：ERROR 1062 (23000) at line 53294: Duplicate entry '13243693' for key 1(是不是之前设置A的配置文件时没有指定binlog的模式,查了一下资料,说是RBR模式 能处理很多主键重复的问题,而binlog默认的是SBR的模式)

Answer 9

发现公司的mysql版本是5.0.21 好像5.1.5版本的MySQL才开始支持row level的复制 肿么办解决呀 

Answer 10

你的步骤看不出什么问题，我看你还是重新在线做一个A的slave吧

Answer 11

A的slave之前做好了 虽然同步上没有出现问题,但是我在slave的配置文件中添加了slave-skip-errors=all选项,所以我就但是 表面上没有问题,其实slave是把所有的问题都给跳过忽略了.而同步的数据还是存在问题. 
那我如果把binlog文件用mysqlbinlog做成一个sql文件,然后-f强制导入数据库,对数据文件会造出什么损害吗.