![首次尝试将 EC2 MySQL 迁移到 Amazon RDS 进展不顺利 - 超级权限](https://linux22.com/image/621170/%E9%A6%96%E6%AC%A1%E5%B0%9D%E8%AF%95%E5%B0%86%20EC2%20MySQL%20%E8%BF%81%E7%A7%BB%E5%88%B0%20Amazon%20RDS%20%E8%BF%9B%E5%B1%95%E4%B8%8D%E9%A1%BA%E5%88%A9%20-%20%E8%B6%85%E7%BA%A7%E6%9D%83%E9%99%90.png)
我一直在尝试将现有数据库从 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` */;
通过注释掉前两行并在第三行添加“CREATE”,我能够绕过这一行。但是吨像这样的部分。有没有办法解决这个问题而不用进行所有的编辑?比如选择mysqldump
不生成任何需要超级权限的内容?
似乎很多人都遇到过类似的问题,比如必须sed
针对 mysqldump / mysqlbinlog 的输出运行!我也要在 AWS 论坛上发帖 - 我真的认为 RDS 应该有一种更宽容的从 mysqldump 导入的方式,或者一个可以针对现有数据库运行以创建符合 RDS 安全性的转储的特定工具。只是想知道是否有人有其他可能有帮助的秘诀或技巧。
谢谢,
戴夫
答案1
您确实可能需要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 确实很好,这种黑客行为非常合法,而且与我作为 DBA 即使在非 RDS 环境中必须做的事情并没有太大区别。
perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql
...可能不是您所希望的答案,但您可以对您的转储文件运行它,最终会得到一个更可用的文件。
答案2
在我的例子中,转储中的“CHANGE MASTER TO MASTER_LOG_FILE= ... ”行给了我错误。此行由 mysqldump 的“--master-data”选项添加。在 Amazon AWS 中,您需要通过使用“mysql.rds_set_external_master”过程设置主服务器详细信息来启动复制,而不是阅读这里
因此,我只需记下“head 22 backup.dump”这一行,即报告错误的第 22 行。然后在导入之前将其删除,对于我的大文件,我使用:“sed '22d' backup.dump > backup_clean.dump”