拒绝访问;您需要(至少其中一项)此操作的 SUPER 权限

Access denied; you need (at least one of) the SUPER privilege(s) for this operation

所以我尝试将sql文件导入rds(1G MEM,1 CPU)。 sql 文件相当于 1.4G

mysql -h xxxx.rds.amazonaws.com -u user -ppass --max-allowed-packet=33554432 db < db.sql

卡在了:

ERROR 1227 (42000) at line 374: Access denied; you need (at least one of) the SUPER privilege(s) for this operation

实际sql内容为:

/*!50003 CREATE*/ /*!50017 DEFINER=`another_user`@`1.2.3.4`*/ /*!50003 TRIGGER `change_log_BINS` BEFORE INSERT ON `change_log` FOR EACH ROW
IF (NEW.created_at IS NULL OR NEW.created_at = '00-00-00 00:00:00' OR NEW.created_at = '') THEN
        SET NEW.created_at = NOW();
END IF */;;

another_user在rds中不存在,所以我这样做:

GRANT ALL PRIVILEGES ON db.* TO another_user@'localhost';

仍然没有运气。

从您的 sqldump 文件中删除 DEFINER=.. 语句,或者将用户值替换为 CURRENT_USER

RDS 提供的 MySQL 服务器不允许其他用户使用 DEFINER 语法(根据我的经验)。

您可以使用 sed 脚本将它们从文件中删除:

sed 's/\sDEFINER=`[^`]*`@`[^`]*`//g' -i oldfile.sql

只是针对 hjpotter92 答案的 MacOS 额外更新。

要使 sed 识别 MacOS 中的模式,您必须在 = 符号前添加一个反斜杠,如下所示:

sed -i old 's/\DEFINER\=`[^`]*`@`[^`]*`//g' file.sql

问题

下面的语句或行你的转储文件创建问题

DEFINER=username@`%

简单的解决方案

您可以解决的解决方案是从 SQL 转储文件中删除所有条目并从 GCP 控制台导入数据.

 cat DUMP_FILE_NAME.sql |  sed -e 's/DEFINER=`<username>`@`%`//g' > NEW-CLEANED-DUMP.sql

以上命令将有助于从转储文件中删除所有这些行,并创建新的新转储文件,无需 Definer.

尝试导入新文件(NEW-CLEANED-DUMP.sql).

如果您使用的是 AWS RDS

您可能会看到面部问题,如果您的转储文件较大,您可以使用

检查前 20 行
head -30 filename

一旦您可以看到输出,请查找行和行号

SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN; 

我们将按行号删除这些行,例如 17、18、24 行号

sed -e '24d;17d;18d' file-name.sql > removed-line-file-name.sql

我在 *.sql 文件中注释了所有以 SET 开头的行,它起作用了。

如果您的转储文件没有 DEFINER,请确保下面的这些行也被删除(如果它们存在),或者用 -- :

注释掉

开头:

-- SET @@SESSION.SQL_LOG_BIN= 0;
-- SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';

最后:

-- SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

请注意,注释字符为“破折号 space”,包括 space。

更好的解决方案是通过在 mysqldump 命令中包含选项 --set-gtid-purged=OFF 来完全阻止将这些行写入转储文件。

另一个有用的技巧是使用选项 --set-gtid-purged=OFF 调用 mysqldump,它不会将以下行写入输出文件:

SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

不确定 DEFINER 那个。

问题:您正在尝试将数据(使用 mysql转储文件)导入到您的 mysql 数据库,但您似乎没有这样做有权执行该操作。

解决方案:假设您的数据已在您的mysql数据库中迁移、播种和更新,使用mysql转储拍摄快照并将其导出到文件

mysqldump -u [username] -p [databaseName] --set-gtid-purged=OFF > [filename].sql

From mysql documentation:

GTID - A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup. There is a 1-to-1 mapping between all transactions and all GTIDs.

--set-gtid-purged=OFF SET @@GLOBAL.gtid_purged is not added to the output, and SET @@SESSION.sql_log_bin=0 is not added to the output. For a server where GTIDs are not in use, use this option or AUTO. Only use this option for a server where GTIDs are in use if you are sure that the required GTID set is already present in gtid_purged on the target server and should not be changed, or if you plan to identify and add any missing GTIDs manually.

然后使用 root 用户连接到您的 mysql,授予权限,刷新它们,并验证您的用户权限是否已正确更新。

mysql -u root -p
UPDATE mysql.user SET Super_Priv='Y' WHERE user='johnDoe' AND host='%';
FLUSH PRIVILEGES;
mysql> SHOW GRANTS FOR 'johnDoe';
+------------------------------------------------------------------+
| Grants for johnDoe                                               |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `johnDoe`                                  |
| GRANT ALL PRIVILEGES ON `db1`.* TO `johnDoe`                     |
+------------------------------------------------------------------+

现在重新加载数据,应该允许操作

mysql -h [host] -u [user] -p[pass] [db_name] < [mysql_dump_name].sql

* 答案可能只适用于 MacOS *

尝试将 .sql 文件导入 docker 容器时,我遇到错误消息:

Access denied; you need (at least one of) the SUPER privilege(s) for this operation

然后在尝试其他一些建议时,我在 MacOS 上收到以下错误 (osx)

sed: RE error: illegal byte sequence

最后,resource 中的以下命令解决了我的 "Access Denied" 问题。

LC_ALL=C sed -i old 's/\DEFINER\=`[^`]*`@`[^`]*`//g' fileName.sql

所以我可以导入 docker 数据库:

docker exec -i dockerContainerName mysql -uuser -ppassword table < importFile.sql

希望对您有所帮助! :)

要以 .sql.gz 格式导入数据库文件,删除定义器并使用以下命令导入

zcat path_to_db_to_import.sql.gz | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | mysql -u user -p new_db_name
  1. 之前,使用以下命令以 .sql.gz 格式导出数据库。

    mysqldump -u user -p old_db | gzip -9 > path_to_db_exported.sql.gz;

  2. 使用以下命令导入导出的数据库并删除定义器,

    zcat path_to_db_exported.sql.gz | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | mysql -u user -p new_db

恢复备份时,请务必尝试使用相同的新旧用户名。

完整解决方案

以上解决办法都可以。在这里,我将结合所有解决方案,使其适用于所有情况。

  1. 固定定义器

对于Linux和Mac

sed -i old 's/\DEFINER\=`[^`]*`@`[^`]*`//g' file.sql

对于Windows
下载 atom 或 notepad++,用 atom 或 notepad++ 打开转储 sql 文件,按 Ctrl+F
搜索单词 DEFINER,然后删除行 DEFINER=admin@%(或者对您来说可能略有不同) 并保存文件。
比如
在删除该行之前:CREATE DEFINER=admin@% PROCEDURE MyProcedure
删除该行后: CREATE PROCEDURE MyProcedure

  1. 删除 3 行 从转储文件中删除所有这 3 行。您可以使用 sed 命令或在 Atom 编辑器中打开文件并搜索每一行,然后删除该行。
    示例:在 Atom 中打开 Dump2020.sql,按 ctrl+F,搜索 SET @@SESSION.SQL_LOG_BIN= 0,删除该行。
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
  1. 您生成的文件有问题 如果您生成的 dump.sql 文件不正确,您可能会遇到一些问题。但在这里,我不会解释如何生成转储文件。不过你可以问我(_)

需要在服务器端设置“on”服务器参数“log_bin_trust_function_creators”。如果它是 azure maria db,您可以在左侧轻松找到 blade。

当我们创建一个新的RDS数据库实例时,默认的主用户不是root用户。但只能获得该数据库实例的某些特权。该权限不包括SET权限。现在,如果您的默认主用户尝试执行 mysql SET 命令,那么您将面临此错误: Access denied;您需要(至少其中之一)此操作的 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限

解决方案 1

注释掉或删除这些行

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 1;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';

解决方案 2

您也可以通过使用 -f 选项加载转储文件的其余部分来忽略错误。

mysql -f <REPLACE_DB_NAME> -u <REPLACE_DB_USER> -h <DB_HOST_HERE> -p < dumpfile.sql

如果有帮助,当我尝试在我的 AWS MySQL RDS 上恢复数据库转储时,我收到了这个错误:

ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER, 
SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

我不必更改 DEFINER 或 remove/comment out 行。我刚刚做了:

GRANT SESSION_VARIABLES_ADMIN ON *.* TO myuser@'myhost';
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO myuser@'myhost';

而且我能够进行恢复。

转储中的问题。

请尝试通过以下方式获取转储:

mysqldump -h databasehost --user=databaseusername --password --single-transaction databasename  | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | gzip > /tmp/database.sql.gz

然后,尝试通过以下方式导入:

zcat /tmp/database.sql.gz | mysql -h database_host -u username -p databasename

None 以上解决方案对我有用。我必须执行以下操作:

  • 将以下标志与 mysqldump 一起使用:

    mysqldump --databases <db1> <db2> --master-data=1 --single-transaction --order- 
    by-primary --foce -r all.sql -h<host> -u<user> -p<password>
    
  • 删除如下所示的行:

    CHANGE MASTER TO MASTER_LOG_FILE='binlog.....
    
    • 在我的文件中,那是第 22 行,所以我 运行:sed -i '22d' all.sql
  • 将数据导入您的 RDS:

    mysql -h<host> -u<user> -p<password>
    $ source all.sql