一次mysql恢复过程中的cm.cm_version记录异常（1032）以及主键冲突（1062）问题

在一次机房搬迁后，大数据人员反映数据异常，应用无法启动。需要恢复数据库，我们生产环境的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的时候，没有出现表不存在和主键冲突的情况。所以这次遇到的问题很奇怪。