La première tentative de migration de EC2 MySQL vers Amazon RDS ne va pas bien - privilèges SUPER

J'ai essayé de déplacer une base de données existante de MySQL fonctionnant sur EC2 vers une nouvelle instance Amazon RDS (une expérience pour voir si nous pouvons traverser). Jusqu'à présent, ça ne va pas bien. Je suis bloqué à l'importation initiale avant de configurer la réplication (instructions ici ).

J'ai préparé l'instance RDS comme décrit et je peux me connecter depuis l'instance EC2 en utilisant mysql. J'ai exécuté la commande mysqldump en tant que:

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

Ensuite, j'ai tenté de le télécharger sur RDS avec:

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

Le premier problème était à la ligne 22 du dépotoir:

CHANGE MASTER EN MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 106;

Cette ligne a provoqué une erreur ERROR 1227 (42000) at line 22: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Pas de problème, juste commenté cette ligne et j'espère la corriger plus tard via mysql.rds_set_external_master (). Retenté le téléchargement, et a obtenu une erreur très similaire: ERROR 1227 (42000) at line 7844: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. La section autour de la ligne 7844 ressemble à ceci:

/*!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` */;

En commentant les 2 premières lignes et en ajoutant un «CREATE» à la troisième, j'ai pu dépasser celle-ci. Mais il y a des tonnes de sections comme ça. Y a-t-il un moyen de contourner cela sans toute la modification? Comme une option pour mysqldumpne rien produire qui nécessite des privilèges SUPER?

Il semble que beaucoup de gens aient eu des problèmes similaires, comme devoir courir sedcontre la sortie de mysqldump / mysqlbinlog! Je vais également poster sur le forum AWS - je pense vraiment que RDS devrait avoir un moyen plus tolérant d'importer depuis mysqldump, ou un outil spécifique qui peut être exécuté sur une base de données existante pour créer un vidage qui est conforme à la sécurité RDS. Je me demandais simplement si quelqu'un avait d'autres recettes ou astuces qui pourraient aider ici.

Merci,

Dave

Vous avez probablement besoin de log_bin_trust_function_creators= 1 sur RDS, mais ce n'est pas le problème ici.

Vous ne pouvez spécifier une  DEFINER valeur autre que votre propre compte que si vous avez le  SUPER privilège.

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

Lorsqu'un programme stocké (proc, fonction, événement ou déclencheur) est en cours d'exécution, tout ce qu'il fait a les autorisations de l'utilisateur qui l'a défini ou de l'utilisateur explicitement indiqué avec une DEFINERdéclaration. Cela permet, entre autres, aux programmes stockés de permettre à d'autres utilisateurs de faire des choses sur des données qu'ils ne sont pas directement autorisés à manipuler, tant qu'ils sont autorisés à utiliser le programme stocké lui-même.

Ce serait donc une grave vulnérabilité si un non- SUPERutilisateur pouvait créer une procédure avec un définisseur arbitraire, parce que l'utilisateur pouvait augmenter ses privilèges à sa guise.

Cela est également vrai pour les vues, bien sûr, lorsque le contexte de sécurité défini est utilisé, comme dans l'exemple que vous avez publié.

L'une des plus grosses plaintes que j'ai avec RDS est que vous ne pouvez pas avoir SUPER... et maintenant cela peut aussi être l'un des vôtres :) parce que ce fait est la cause du problème que vous rencontrez.

Bien sûr, si j'exécutais un service MySQL géré, je n'en donnerais à personne SUPERnon plus, donc leur modèle de sécurité a du sens, même s'il est parfois difficile à manier.

Si tous vos objets ont le même definer, une solution de contournement serait de restaurer le vidage en utilisant ce compte au lieu de celui que vous utilisez maintenant, mais cela semble peu probable.

Supprimer uniquement la ligne avec la DEFINERdéclaration devrait faire fonctionner le fichier de vidage dans les cas où il apparaît sur une ligne seule, ou vous pouvez utiliser sed ou perl pour modifier le fichier ... une idée que je sais déjà que vous n'aimez pas, mais c'est vraiment une bonne chose à propos de MySQL qu'un tel piratage soit tout à fait légitime, et pas vraiment loin du genre de choses que je dois faire en tant que DBA même dans un environnement non RDS.

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql

... peut-être pas la réponse que vous espériez, mais vous pouvez l'exécuter avec votre fichier de vidage et vous devriez vous retrouver avec un fichier légèrement plus utilisable.

Dans mon cas, la ligne "CHANGE MASTER TO MASTER_LOG_FILE = ..." du vidage me donnait l'erreur. Cette ligne a été ajoutée par l'option "--master-data" de mysqldump. Dans Amazon AWS, vous devez démarrer la réplication en définissant les détails principaux avec la procédure "mysql.rds_set_external_master" à la place, lisez ici

Je viens donc de prendre des notes de cette ligne "head 22 backup.dump" où la ligne 22 a signalé l'erreur. Ensuite, supprimez-le avant d'importer, pour mon gros fichier, j'utilise: "sed '22d' backup.dump> backup_clean.dump"