mysqlbinlog恢复单个库特定时间段内的记录
mysql 5.0.xx ，一主一从，若干天以后，发现由于没有指定
replicate-wild-do-table=stastics.%
有一个库stastics 的数据没有从主库上同步过来。
由于该库的记录仅顺序记录登陆信息，可以在尾部加上，所以先打开在线复制，再把截断的数据记录补上。
1. 从库，加上replicate-wild-do-table=stastics.% ，重启生效。
2.导出sql。 根据频繁插入的表, 查询被截断的数据准确时间
select add_time,count(*) from stastics_click_user group by date(add_time);
根据mysql-bin日志的修改时间，可以判断.00014x是这个期间生成的二进制日志文件，导出sql
$ mysqlbinlog -d stastics --start-datetime="2011-06-03 00:03:23" --stop-datetime="2011-06-07 23:06:44" mysql-bin.00014* > load.data.20110603.20110607.sql
more load.data.20110603.20110607.sql
可以看到生成的sql文件，按时间顺序排列。
file load.data.20110603.20110607.sql
ANSCII文件，可以直接编辑。
sed -i -e "s%^SET INSERT_ID=%#SET INSERT_ID=%g" load.data.20110603.20110607.sql
去掉INSERT_ID设定，以免冲突。
导入数据记录
mysql --default-character-set=utf8 stastics < load.data.20110603.20110607.sql
3.大功告成。
此解决办法是建立在对表的增删改查逻辑有一定了解 ，保证导入数据既不会覆盖打开在线复制期间的修改，又保证数据记录能正常使用。
replicate-wild-do-table=stastics.%
有一个库stastics 的数据没有从主库上同步过来。
由于该库的记录仅顺序记录登陆信息，可以在尾部加上，所以先打开在线复制，再把截断的数据记录补上。
1. 从库，加上replicate-wild-do-table=stastics.% ，重启生效。
2.导出sql。 根据频繁插入的表, 查询被截断的数据准确时间
select add_time,count(*) from stastics_click_user group by date(add_time);
根据mysql-bin日志的修改时间，可以判断.00014x是这个期间生成的二进制日志文件，导出sql
$ mysqlbinlog -d stastics --start-datetime="2011-06-03 00:03:23" --stop-datetime="2011-06-07 23:06:44" mysql-bin.00014* > load.data.20110603.20110607.sql
more load.data.20110603.20110607.sql
可以看到生成的sql文件，按时间顺序排列。
file load.data.20110603.20110607.sql
ANSCII文件，可以直接编辑。
sed -i -e "s%^SET INSERT_ID=%#SET INSERT_ID=%g" load.data.20110603.20110607.sql
去掉INSERT_ID设定，以免冲突。
导入数据记录
mysql --default-character-set=utf8 stastics < load.data.20110603.20110607.sql
3.大功告成。
此解决办法是建立在对表的增删改查逻辑有一定了解 ，保证导入数据既不会覆盖打开在线复制期间的修改，又保证数据记录能正常使用。
