在一次机房搬迁后，大数据人员反映数据异常，应用无法启动。需要恢复数据库，我们生产环境的msyql采用mysqldump+binlog 的方法进行备份，每天进行一次全备。然后开始恢复
一、恢复dump全备
mysql -uroot -p
mysql > source ./mysqlbak_all_database_2019-11-02.sql
.....
......
....
mysql>exit
真一步很顺利，没有报错（20G的dump文件，恢复了大概45min），本以为很简单，然后乐极生悲啊
二、应用binlog
查看起始位置：
less /mysqlbak_all_database_2019-11-02.sql
1、按照起始位置恢复：
mysqbinlog --start-position=1846294 mysql-master-bin.003775 |mysql -uroot -p
噩梦开始
报错1：
ERROR 1032 (HY000): mysqlbinlog Can't find record in ''cm.cm_version"
咨询开发人员cm.cm_version是记录大数据name节点信息的，其中只有1条记录，可以忽略。
修改配置文件
vim /etc/my.cnf
增加
slave-skip-errors=1032
重启数据库
/etc/init.d/mysql restart
然后继续恢复
mysqbinlog --start-position=1846294 mysql-master-bin.003775 |mysql -uroot -p
报错2：
ERROR 1062 (23000) at line 234326: Duplicate entry '17y47wrjdpqyzqnll9mzpx53j5wp1qxa' for key 'PRIMARY'
神奇的主键冲突，难道是mysqldump备份的时候出现了异常？先解决问题，
mysqlbinlog --base64-output =decode-rows mysql-master-bin.003775 >binlog.bak
vim binlog.bak
查找第234326行的记录
#191102 4:04:14 server id 1 end_log_pos 9486176 CRC32 0x4df8ced6 Query thread_id=46903173 exec_time=0 error_code=0
SET TIMESTAMP=1572638654/*!*/;
INSERT INTO `django_session` (`session_key`, `session_data`, `expire_date`) VALUES ('17y47wrjdpqyzqnll9mzpx53j5wp1qxa', 'NmY1MGYxOGZjYmM2Y2I4NmM5NzVmYWExMjdkNjNjZTJhYzg1ZDM4ZDp7InRlc3Rjb29raWUiOiJ3b3JrZWQifQ==', '2019-11-16 04:04:14')
插入了一张会话信息表，可以忽略，
之后又出现了几次主键冲突，均为web框架的会话信息，加-f忽略
mysqbinlog --start-position=1846294 mysql-master-bin.003775 |mysql -uroot -f -p
然后根据错误提示行，到binlog.bak文件找具体的语句，看是否需要补录。
总结:
此次的恢复，是在生产环境下直接进行的恢复，之前的数据都还在。按理说，mysqldump导出的文件，在恢复时，如果表已存在，会先删除表，然后重建和插入记录，不应该出现主键冲突的情况。而且之后自己在一台新的环境进行同样的恢复，应用binlog的时候，没有出现表不存在和主键冲突的情况。所以这次遇到的问题很奇怪。
