mysql binlog恢复

look321

　　mysql binlog恢复
　　数据库恢复流程
　　要恢复的数据库备份及恢复的时间点：
　　将备份的全备数据库s14_61.160.241.195_20120116_04.sql.tar.gz解压缩
　　tar zxvfs14_61.160.241.195_20120116_04.sql.tar.gz
　　若解压后可能为多项数据库表，可先创建一个目录，将全备移动到新目录中
　　cd /data/backup
　　mkdir 20120116
　　mv *_04.sql.gz /data/backup/20120116
　　恢复数据库命令
　　gunzip use cllogunicode;
　　>show tables;
　　binlog还原
　　tar zxvfs14_61.160.241.195_20120116_05.binlog.tar.gz
　　解压缩文件为：
　　将解压出的文件移动到/data/mysql/3306/logs
　　mysqlbinlog mysql-bin.000069 |mysql –uroot
　　mysqlbinlog mysql-bin.000070 |mysql –uroot
　　报错
　　ERROR 1062 (23000) at line 2766: Duplicateentry '4617' for key 'PRIMARY'
　　解决方法
　　mysqlbinlog mysql-bin.000069 |mysql –uroot –f 忽略错误并解决
　　ERROR 1062 (23000) at line 2766: Duplicateentry '4617' for key 'PRIMARY'
　　ERROR 1062 (23000) at line 2818: Duplicateentry '320390-240503' for key 'PRIMARY'
　　ERROR 1062 (23000) at line 3032: Duplicateentry '101014-1326657623' for key 'PRIMARY'
　　ERROR 1032 (HY000) at line 12908: Can'tfind record in 'char_items'
　　ERROR 1062 (23000) at line 12922: Duplicateentry '06623f3c-ec9a-439b-81c5-ba663b2045d6' for key 'PRIMARY'
　　binlog70未报错
　　错误原因探究：
　　主键重复：就是说BINLOG里的部分数据很可能数据库里存在了
　　binlog恢复的POS点一定要精确就是全备后的那个点。可以是时间点，也可以是POST点，
　　一个很重要的问题就是导库时要做BINLOG切割工作，否则，导库的BINLOG会增加没用的BINLOG，造成恢复BINLOG失败
　　mysqlbinlog mysql-bin.000069 --start-date="2012-01-1604:30:00" --stop-date="2012-01-16 05:00:00"|mysql -uroot
　　执行
mysql -u user_name -p db_name < db_name.sql若碰到同样问题时，解决方法：插入数据的时候忽略掉那个重复的项目，即在insert后面增加ignore　　sed -e 's/INSERT INTO/INSERT ignore INTO/g'db_name.sql > db_name_ignore.sql
　　第二种倒库方法
　　解压缩sql.gz
　　gunzip db.sql
　　mysql -uroot -p mysql&lt;mysql.20120116_04.sql
　　mysql -uroot -p ic_farm &lt; ic_farm.20120116_04.sql
　　mysql -uroot -p clunicode &lt; clunicode.20120116_04.sql
　　mysql -uroot -p cllogunicode &lt;cllogunicode.20120116_04.sql
　　正常全备倒库不报错