要么删除DEFINER=.语句，或者将用户值替换为CURRENT_USER。

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

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

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

只是一个MacOS额外更新hjpotter92的答案。

为了让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

我注释了*中所有以SET开头的行。SQL文件，它工作。

如果你的转储文件没有DEFINER，确保下面的这些行也被删除(如果它们存在的话)，或者用——

一开始:

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

最后:

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

注意，注释字符是“破折号空格”，包括空格。

更好的解决方案是通过在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。

问题:你试图导入数据(使用mysqldump文件)到你的mysql数据库，但似乎你没有权限执行该操作。

解决方案:假设你的数据迁移，种子和更新在你的mysql数据库，采取快照使用mysqldump和导出到文件

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容器时，我遇到了错误消息:

拒绝访问;您需要(至少一个)SUPER特权 这个操作

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

sed: RE错误:非法字节序列

最后，该资源的以下命令解决了我的“访问被拒绝”问题。

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

之前，使用以下命令导出.sql.gz格式的数据库。 Mysqldump -u user -p old_db | gzip -9 > path_to_db_exported.sql.gz; 使用以下命令导入导出的数据库并删除定义器， zcat path_to_db_exported.sql.gz | sed - e ' s /定义者 [ ]*=[ ]*[^*]*\*/\*/' | 用户- p new_db mysql - u

当您恢复备份时，请确保对旧备份和新备份尝试使用相同的用户名。

完整的解决方案

以上所有的解决方案都是好的。这里我要把所有的解结合起来这样它就适用于所有的情况。

固定的定义者

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

删除3条线 从转储文件中删除所有这3行。您可以使用sed命令或在Atom编辑器中打开该文件，搜索每一行，然后删除该行。 示例:打开Dump2020。sql在Atom，按ctrl+F，搜索SET @@会话。SQL_LOG_BIN= 0，删除该行。

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

生成的文件有问题 如果您生成的转储文件可能会遇到一些问题。SQL文件不正确。但在这里，我不打算解释如何生成转储文件。但是你可以问我(_)

需要在服务器端设置“on”服务器参数“log_bin_trust_function_creators”。这一个你可以很容易地找到左侧刀片，如果它是蔚蓝玛丽亚db。

当我们创建一个新的RDS DB实例时，默认的主用户不是根用户。但仅获得该DB实例的某些特权。该权限不包括SET权限。现在，如果你的默认主用户试图执行mysql SET命令，那么你将面临这个错误:访问被拒绝;您需要(至少一个)SUPER或system_variable_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上恢复一个DB转储时，我得到了这个错误:

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或删除/注释行。我刚刚做了:

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

以上的方法对我来说都没用。我必须做到以下几点:

在mysqldump中使用以下标志: Mysqldump——databases <db1> <db2>——master-data=1——single-transaction——order- By-primary, force -r all。SQL -h<主机> -u<用户> -p<密码> 删除如下一行: 更改MASTER为MASTER_LOG_FILE='binlog..... 在我的文件中，这是第22行，所以我运行:sed -i '22d' all.sql 将数据导入RDS: Mysql -h<主机> -u<用户> -p<密码> $ source all.sql

在我的情况下(试图执行一个SQL文件到AWS RDS)，我的SQL语句的开头是这样的:

DROP VIEW IF EXISTS `something_view`;
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`%` SQL SECURITY DEFINER VIEW `something_view`...

我所要做的就是删除上面语句中的ALGORITHM=UNDEFINED DEFINER='root'@'%' SQL SECURITY DEFINER部分。

所以新的语句是这样的:

CREATE VIEW 'something_view' ...