Using MySQL triggers and views in Amazon RDS_MySQL

i recently had an opportunity to migrate a customer from a physical server into amazon’s rds environment. in this particular case the customers’ platform makes extensive use of mysql triggers and views.  i came across two significant issues that prevented me from following amazon’s documentation, which basically states “use mysqldump” but doesn’t call out a specific method of dealing with mysql triggers and views.

Amazon Relational Database Service (Amazon RDS) is a great platform if you’re looking for complete hands-off management of your MySQL environment, but comes at a cost in the area of flexibility, i.e. you don’t have SUPER privilege and this brings up additional challenges.

1. You need to ensure you set log_bin_trust_function_creators=1 ( by default this is off, 0).
2. You need to clean up your mysqldump syntax.

#1 is easy, you simply make a configuration change within the Amazon RDS GUI on the node’s Parameter Group to set log_bin_trust_function_creators=1 and then a restart of your Amazon RDS node.  The restart is required since without the SUPER privilege you lose access to changing DYNAMIC variables on the fly. #2 is a little more complex.  If you go with vanilla mysqldump (from say a 5.5 mysqldump binary) on a schema that has triggers and views, you will see error 1227, something like this:

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

You’re seeing this message because MySQL in Amazon RDS doesn’t provide the SUPER privilege, and thus you cannot set up a trigger or view to run as a different user — only a user with SUPER can do that.

mysqldump will generate syntax for a trigger like this:

DELIMITER ;;/*!50003 CREATE*/ /*!50017 DEFINER=`root`@`%`*/ /*!50003 TRIGGER `after_insert_lead` AFTER INSERT ON `leads` FOR EACH ROW BEGINUPDATE analytics.mapping SET id_lead = NEW.id_lead WHERE mc_email = NEW.email;END */;;DELIMITER ;

and for a view like this:

/*!50001 CREATE ALGORITHM=UNDEFINED *//*!50013 DEFINER=`web`@`%` SQL SECURITY DEFINER *//*!50001 VIEW `admin_user_view` AS SELECT ...

The problem is in the “DEFINER” lines.

Here’s one method that worked for me:

1. Identify all the DEFINER lines in your schema. I found it helpful to dump out a –no-data and then weed through that to get a unique list of the DEFINER lines
2. Create a sed line for each unique DEFINER line (see my example in a moment)
3. Include this sed line in your dump/load script

Here’s what my sed matches looked like:

sed-e 's//*!50017 DEFINER=`root`@`localhost`*///'-e 's//*!50017 DEFINER=`root`@`%`*///'-e 's//*!50017 DEFINER=`web`@`%`*///'-e 's//*!50017 DEFINER=`cron`@`%`*///'-e 's//*!50013 DEFINER=`cron`@`%` SQL SECURITY DEFINER *///'-e 's//*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER *///'-e 's//*!50013 DEFINER=`root`@`%` SQL SECURITY DEFINER *///'-e 's//*!50013 DEFINER=`web`@`%` SQL SECURITY DEFINER *///'

Note: the example above won’t directly work due to WordPress “helpfully” stripping my text… you need to escape the forward slashes and asterisks.

A big caveat: this method is akin to a brute force method of getting your data into Amazon RDS — you’ve lost the elegance & security of running your triggers and views as separate defined users within the database — they are all now going to run as the user you loaded them in as. If this is a show-stopper for you, contact Percona and I’d be happy to take on your case and develop a more comprehensive solution. 

Now all that’s left is to integrate this into your dump flow.  Something like this should work:

mysqldump--host=source| sed-e ... lots of lines| mysql--host=destination

I hope this helps someone!