mysql binlog恢复
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<mysql.20120116_04.sql
mysql -uroot -p ic_farm < ic_farm.20120116_04.sql
mysql -uroot -p clunicode < clunicode.20120116_04.sql
mysql -uroot -p cllogunicode <cllogunicode.20120116_04.sql
正常全备倒库不报错
页:
[1]