有分组表，结构如下：

CREATE TABLE `member` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`gid` bigint(20) unsigned NOT NULL,
`uid` bigint(20) unsigned NOT NULL,
`touid` bigint(20) unsigned NOT NULL,
`addtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`reason` varbinary(90) NOT NULL DEFAULT ”,
PRIMARY KEY (`id`),
KEY `idx_uid_gid_touid` (`uid`,`gid`,`touid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

uid是用户id,gid是分组id，touid是被分组人的id。

由于历史问题，`uid`,`gid`,`touid`不唯一，现在要将`uid`,`gid`,`touid`变为唯一键，这样就要进行去重工作。
去重有很多方法，方法一就是建一套新的库表，然后堵队列，由开发将历史数据插入库表，使用insert ignore 或者 insert replace的方法去掉重复记录，但这种方法比较慢。
另一种方法就是直接用一个从库，停复制后，将历史数据导出，修改表结构后，然后再用load data infile导入，当然也要使用ignore或者replace参数。此方案需要导入导出，有一定的风险，速度一般。
第三种方法就是用一个从库，停复制后，使用
alter ignore table member drop key `idx_uid_gid_touid` (`uid`,`gid`,`touid`),add unique key `idx_uid_gid_touid` (`uid`,`gid`,`touid`)；
方法，可以直接达到去重的目的。

但测试发现，在5.5.12版上，仍然会报错
ERROR 1062 (23000): Duplicate entry ‘0-0-0′ for key ‘idx_uid_gid_touid’

查询官网，发现是一个bug(http://bugs.mysql.com/bug.php?id=40344),需要添加order by ….，可以正常使用。但此时不是使用fast index creation，而是使用table copy，速度较慢。
注意这只是一个变通的方法，其实order by 并没有实际的效果，执行完成，show warnings如下：
show warnings;
+———+——+————————————————————————————–+
| Level   | Code | Message                                                                              |
+———+——+————————————————————————————–+
| Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table ‘member_01′ |
+———+——+————————————————————————————–+

执行前：
mysql> select count(1) from member;
+———-+
| count(1) |
+———-+
|  8380821 |
+———-+

执行后：
mysql> select count(1) from member;
+———-+
| count(1) |
+———-+
|  8351907 |
+———-+

丢掉了大约3w条重复记录。

此时设想是开启复制，同时设置跳过1062错误（因为master库没有去重）。
但开启复制后，发现以下错误：

Last_Error: Could not execute Delete_rows event on table group_info.member_3e; Can’t find record in ‘member_3e’, Error_code: 1032; handler error
HA_ERR_KEY_NOT_FOUND; the event’s master log mysql-bin.000326, end_log_pos 958589387

去主库上查看日志：
sr/local/mysql55/bin/mysqlbinlog –base64-output=decode-rows  –verbose –start-position=958589290 –stop-position=958589387   mysql-bin.000326
显示
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 958589290
ERROR: malformed binlog: it does not contain any Format_description_log_event. I now found a Delete_rows event, which is not safe to process without a Format_description_log_event.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

怀疑是一个bug，–base64-output=decode-rows和–start-position一起使用的时候。

改为时间查看
/usr/local/mysql55/bin/mysqlbinlog -v –base64-output=decode-rows –start-datetime=’2011-12-24 18:08:22′  mysql-bin.000326|more
显示
#111224 18:08:22 server id 111164240  end_log_pos 958589387     Delete_rows: table id 1520 flags: STMT_END_F
### DELETE FROM group_info.member
### WHERE
###   @1=756175399
###   @2=201112200674529481
###   @3=1734139392
###   @4=1704116960
###   @5=1324388524
###   @6=”
### DELETE FROM group_info.member
### WHERE
###   @1=756312069
###   @2=201112200674529481
###   @3=1734139392
###   @4=1704116960
###   @5=1324721301
###   @6=”
# at 958589387
(注意时间变为unix_timestamp了)
发现有两条记录，分析认为，在主库上执行删除操作的时候是用@2,@3,@4定位删除的，删除了2条记录，但由于从库上已经去重了，只有一条记录，而在row格式时，找不到此行，所以报错。
可以设置跳过1032错误，但此时数据能否保持一致？
分析如果删除记录的时候是用`uid`,`gid`,`touid`定位，可以保持一致，因为主库的2条删除了，从库的唯一1条也删除了。也就是主库删除的1条或者多条记录里一定包含从库保留的那一条。

my.cnf加入
slave-skip-errors       = 1032,1062

开启复制，问题解决。

Unions
4

Subqueries
4.1

R-trees
4.1 (for the MyISAM storage engine)

Stored procedures and
functions
5

Views
5

Cursors
5

XA transactions
5

Triggers
5.0 and 5.1

Event scheduler
5.1

Partitioning
5.1

Pluggable storage engine
API
5.1

Plugin API
5.1

InnoDB Plugin
5.1

[......]