第一次尝试将 EC2 MySQL 迁移到 Amazon RDS 不顺利 - 超级特权

dsl*_*101 12 mysql amazon-web-services amazon-rds

我一直在尝试将现有的 db 从运行在 EC2 上的 MySQL 移动到新的 Amazon RDS 实例(一个实验,看看我们是否可以移动)。到目前为止,进展并不顺利。在设置复制之前,我被困在初始导入(此处的说明)。

我已经按照描述准备了 RDS 实例,并且可以使用 mysql 从 EC2 实例连接到它。我将 mysqldump 命令运行为:

mysqldump --master-data --databases db1 db2 > dump.sql

然后尝试使用以下命令将其上传到 RDS:

mysql -h RDSHost -P 3306 -u rdsuser --password=rdspassword < dump.sql

第一个问题是在转储的第 22 行:

将 MASTER 更改为 MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=106;

此行导致错误ERROR 1227 (42000) at line 22: Access denied; you need (at least one of) the SUPER privilege(s) for this operation。没问题,只是注释掉该行,希望稍后通过 mysql.rds_set_external_master() 修复它。重试上传,并得到一个非常相似的错误:ERROR 1227 (42000) at line 7844: Access denied; you need (at least one of) the SUPER privilege(s) for this operation。7844 行周围的部分如下所示:

/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`dev`@`localhost` SQL SECURITY DEFINER */
/*!50001 VIEW `jos_contributor_ids_view` AS select `jos_resource_contributors_view`.`uidNumber` AS `uidNumber` from `jos_resource_contributors_view` union select `jos_wiki_contributors_view`.`uidNumber` AS `uidNumber` from `jos_wiki_contributors_view` */;
Run Code Online (Sandbox Code Playgroud)

通过注释掉前两行并向第三行添加“CREATE”,我能够通过这一行。但也有这样的部分。在没有所有编辑的情况下,有没有办法解决这个问题?喜欢mysqldump不生产任何需要超级特权的选项吗?

似乎很多人都遇到过类似的问题,比如不得不sed针对 mysqldump / mysqlbinlog 的输出运行!我也将在 AWS 论坛上发帖 - 我真的认为 RDS 应该有一种更宽容的方式从 mysqldump 导入,或者可以针对现有数据库运行的特定工具来创建一个与 RDS 安全性有关的转储。只是想知道是否有人有任何其他可能对这里有帮助的食谱或技巧。

谢谢,

戴夫

Mic*_*bot 27

log_bin_trust_function_creators在 RDS 上您可能需要= 1 但这不是问题,在这里。

DEFINER 仅当您有权SUPER 限时,您才能指定除您自己的帐户以外的 值 。

http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html

当存储的程序(proc、函数、事件或触发器)正在运行时,它所做的一切都具有定义它的用户或使用DEFINER声明明确声明的用户的权限。这允许存储程序允许其他用户对他们没有直接操作权限的数据执行操作,只要他们有权使用存储程序本身。

如果非SUPER用户可以使用任意定义者创建过程,这将是一个严重的漏洞,因为用户可以随意升级他或她的权限。

当然,当使用定义器安全上下文时,视图也是如此,如您发布的示例所示。

我对 RDS 的最大抱怨之一是你不能拥有SUPER......现在它也可以成为你的一个:) 因为这个事实是你遇到问题的原因。

当然,如果我运行的是托管 MySQL 服务,我也不会给任何人SUPER,所以他们的安全模型是有道理的,即使它有时很笨拙。

如果您的所有对象都具有相同的定义器,则解决方法是使用该帐户而不是您现在使用的帐户恢复转储,但这似乎不太可能。

仅删除带有DEFINER声明的行应该使转储文件在它自己出现在一行的情况下工作,或者您可以使用 sed 或 perl 来修改文件...我已经知道您不喜欢这个想法,但是对于 MySQL 来说,这样的黑客行为非常合法,这确实是一件好事,即使在非 RDS 环境中,也与我作为 DBA 必须做的事情相去甚远。

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql
Run Code Online (Sandbox Code Playgroud)

...可能不是您希望的答案,但您可以针对您的转储文件运行它,并且最终应该会得到一个稍微更有用的文件。

  • 非常感谢你的 perl one liner。这是我能找到的唯一一个真正有效的方法。这些板上的许多其他人根本没有。如果可以,我会再次投票。 (4认同)
  • 很好的解释,很好的答案和很好的解决方案!愚蠢的定义者。 (2认同)