我正在尝试对生产数据库进行时间点恢复，但是在恢复转储后读取二进制日志时，我发现 ERROR 1062 (23000) at line x in file: 'binlogs_file.sql': Duplicate entry 'y' for key 'PRIMARY' . 我仔细检查了一下，似乎二进制日志中的insert语句已经存在于转储文件中，因此也存在于新恢复的测试数据库中。
这是我每天早上在生产服务器上运行的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\u 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'

我们在生产服务器和测试服务器（都是Debian8.10）上运行MySQL5.7.19。以下是生产服务器上与binlog相关的变量：

binlog_format                   = mixed
binlog_group_commit_sync_delay   =   0                                                                                                                              
binlog_group_commit_sync_no_delay_count = 0

我做错什么了？为什么不一致？