导入 MySQL 数据失败,错误 1839

导入 MySQL 数据失败,错误 1839

我已设置了 MySQL 的主从服务器,并配置了 GTID。我取回了主服务器的数据备份,并将其导入到单个测试服务器。导入失败,因为

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

我尝试过--set-gtid-purged=OFFAUTO,但没有成功。

答案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 转储文件中删除此命令。只需删除它即可。所有插入都将作为本地事务出现在从属服务器上

  • 如果你想防止这种情况发生,你也可以在从机上重置主机

    mysql> RESET MASTER;

    此命令将清理从属上的“Executed_Gtid_Set”变量,因此您可以直接导入转储文件,并且前面提到的 set_global_gtid_purged 变量将起作用

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

笔记:

如果主服务器和从服务器之间的 GTID 子集不同(如果您想在复制设置中使用它),那么复制将不起作用,我建议进行二进制转储和恢复,并将从服务器的 GTID 设置为与主服务器完全相同。

使用 GTID 会出现很多新问题,但您的副本设置将更加一致。值得为此努力。

答案2

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

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

在包含 .sql 文件的文件夹中运行此程序。它会将旧版本保存为 .bak。

这对我有用。

答案3

我有一个巨大的数据库,因此,像@Goddard一样,我的备份/转储分布在多个文件中。我的磁盘空间不足,因此我以压缩格式(即.sql.gz)导出转储。@Goddard 的解决方案对我很有吸引力,但是,由于我的磁盘空间不足,我无法将这些文件提取到 .sql 然后应用更改。相反,我将执行以下改编自@Goddard 的答案来导入.sql.gz文件,并在过程中删除 GTID 查询。

find "$DIR" -name "*.sql.gz" | while read table
do
    echo "$table"
    zcat "$table" | perl -pe 's/SET \@\@GLOBAL\.GTID_PURGED=\x27.*?\x27;//gs' | \
                    mysql -h "$HOST" -u "$USER" -p"$PASS" -P "$PORT" "$DB"
done

相关内容