导入 MySQL 数据失败，错误 1839

Question

我已经配置了 GTID 的 MySQL 主从设置。我取回了 master 的数据备份并将其导入到单个测试服务器。它无法导入为

ERROR 1839 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_MODE = ON

我试过--set-gtid-purged=OFFand AUTO，但没有运气。

Answer 1

如果你运行一个

SHOW MASTER STATUS\G

你会看到这样的：

mysql> show master status\G
*************************** 1. row ***************************
         File: mysql-bin.000299
         Position: 780437462
         Binlog_Do_DB:
         Binlog_Ignore_DB:
         Executed_Gtid_Set: 075d81d6-8d7f-11e3-9d88-b4b52f517ce4:1-616637650,
         e907792a-8417-11e3-a037-b4b52f51dbf8:1-25385296642
         1 row in set (0.00 sec)

因为当启用 GTID 时，所有服务器都有自己的 uuid，并且有事务。我想您使用 mysqldump 创建了转储，如果您查看该文件的开头，您会发现类似以下内容：

--
-- GTID state at the beginning of the backup 
--

 SET @@GLOBAL.GTID_PURGED='075d81d6-8d7f-11e3-9d88-b4b52f517ce4:1-616648986,
 e907792a-8417-11e3-a037-b4b52f51dbf8:1-25385296642';

这是无法执行的命令。

您有以下选择：

• 从 mysql 转储文件中删除此命令。只需删除它。所有插入都将出现在从属设备上，因为它是本地事务

• 如果你想防止这种情况发生，你也可以在 slave 上重置 master

  mysql> RESET MASTER;

  这个命令会清理slave上的'Executed_Gtid_Set'变量，这样就可以直接导入dumpfile了，前面提到的set_global_gtid_purged变量就会起作用

• 创建 mysqldump 时，可以跳过 GTID 设置部分，--set-gtid-purged=OFF为 mysqldump添加参数。

笔记：

如果 GTID 子集在 master 和 slave 之间的 master 上不同（如果您想在复制设置中使用它），那么复制将不起作用，我建议进行二进制转储和恢复，因为将 slave 的 GTID 完全设置为 master 的。

使用 GTID 会出现很多新问题，但您的副本设置将更加一致。值得与之合作。

Answer 2

如果您像我一样并且不想重新运行转储，因为这是一个非常长的操作，您可以在事后删除这些行。

find . -name '*.sql' -type f -exec perl -0 -i.bak -pe 's/SET \@\@GLOBAL\.GTID_PURGED=\x27.*?\x27;//gs' {} +

在包含 .sql 文件的文件夹中运行此命令。它将把旧版本保存为.bak。

这对我有用。