我已设置了 MySQL 的主从服务器,并配置了 GTID。我取回了主服务器的数据备份,并将其导入到单个测试服务器。导入失败,因为
ERROR 1839 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_MODE = ON
我尝试过--set-gtid-purged=OFF
和AUTO
,但没有成功。
答案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