Binary Replication error – AWS Aurora 5.6 v.1.19.0

Blog post updated on May 16th 2019 – 1.19.1 update fixed the bug

I’ve recently faced a problem with Binary log replica in AWS (not Aurora Reader) when try to create trigger, function or procedure.

If you upgraded your Aurora 5.6 instance in the last couple of months then you probably have the same problem.

When you try to create trigger, function or procedure at your master server Binlog replica stops the replication with the following error message:

Error 'Access denied; you need (at least one of) the SUPER privilege(s) for this operation' on query. Default database: ''. Query: 'CREATE DEFINER=madroot@% TRIGGER db_mo.madaboutcloud_trigger_after_insert After Insert ON db_mo.madaboutcloud FOR EACH ROW BEGIN END'

The only way to recover is to manually create the trigger/function/procedure on the replica and skip the error on the replica cluster calling:

call mysql.rds_skip_repl_error();

This bug is confirmed to me by AWS support in February 2019 – there is no ETA yet. Tested on 1.19.0 which is the latest version of Aurora for MySql 5.6 at the moment.

I strongly promote the idea of AWS making public list of known issues as I spent more than a month trying to figure out what is going on.

UPDATED on May 16th 2019:

1.19.1 release fixed the bug. You can update using CLI

aws rds modify-db-cluster --db-cluster-identifier CLUSTER_NAME --apply-immediately --engine-version 5.6.mysql_aurora.1.19.1

AWS should post more detailed explanation on bug fixes (well, they didn’t publish the bug after all). 1.19.1 release page says: “Fixed a bug in binlog replication that can cause an issue on Aurora instances configured as binlog slave.” DBAs should know that this exact bug has been fixed instead of being forced to try it.