我正在尝试对生产数据库进行时间点恢复,但是在还原转储后读取二进制日志时,得到ERROR 1062 (23000) at line x in file: 'binlogs_file.sql': Duplicate entry 'y' for key 'PRIMARY'
。
我已经仔细检查过了,转储文件中似乎已经存在二进制日志中的插入语句,因此新恢复的测试数据库中也已经存在插入语句。
这是我的mysqldump语句,每天早晨在生产服务器上运行:
echo "SET autocommit=0;" >> backup_file.sql
echo "SET unique_checks=0;" >> backup_file.sql
echo "SET foreign_key_checks=0;" >> backup_file.sql
mysqldump --flush-logs --quick --single-transaction --master-data=2 --force -- routines <databese_name> >> backup_file.sql`
echo "COMMIT;" >> backup_file.sql
echo "SET unique_checks=1;" >> backup_file.sql
echo "SET foreign_key_checks=1;" >> backup_file.sql
我将最新的转储复制到测试服务器(这是我们的生产服务器的快照,只有三个星期了)。恢复测试数据库后,我使用以下命令检索要从哪个binlog文件开始:
cat backup_file.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE'
这将返回:
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.006502', MASTER_LOG_POS=154;
我复制mysql-bin.006502
文件以及生产服务器中所有后续的binlog文件,并从其中全部创建一个.sql文件(请注意,该位置是多余的,因为--flush-logs
是mysqldump语句的一部分)
mysqlbinlog mysql-bin.006502 > binlogs_file.sql
mysqlbinlog mysql-bin.006503 >> binlogs_file.sql
mysqlbinlog mysql-bin.006504 >> binlogs_file.sql
下一步是对数据库运行binlogs_file.sql。
mysql -u <db_user> -p -e "source binlogs_file.sql"
然后发生错误:
ERROR 1062 (23000) at line x in file: 'binlogs_file.sql': Duplicate entry 'y' for key 'PRIMARY'
我们在生产服务器和测试服务器(均为Debian 8.10)上都运行MySql 5.7.19。 这些是生产服务器上与binlog相关的变量:
binlog_format = mixed
binlog_group_commit_sync_delay = 0
binlog_group_commit_sync_no_delay_count = 0
我在做什么错?为什么不一致?