Mysqldump throwing error 'Couldn't execute 'ROLLBACK TO SAVEPOINT sp':

Can any one please explain what is happening with our DB dumps?

We are executing dump as below

mysqldump -v --single-transaction --quick --lock-tables=false --skip-triggers -uXXX -pXXX $EXCLUDETABLES dbname -h xxx.xxx.xxx > $FLNM

$EXCLUDETABLES contains multiple --ignore-table statements

Instance details : AWS RDS MYSQL MULTIAZ 5.6.21 us-east-1c 40GB

Warning: Using a password on the command line interface can be insecure.
-- Connecting to xxx.xxx.xxx...
-- Starting transaction...
-- Setting savepoint...
-- Retrieving table structure for table t_XXX_XXX...
-- Sending SELECT query...
-- Retrieving rows...
-- Rolling back to savepoint sp...
-- Retrieving table structure for table t_XXX...
-- Sending SELECT query...
-- Retrieving rows...
-- Rolling back to savepoint sp...
-- Retrieving table structure for table t_XXX...
-- Sending SELECT query...
-- Retrieving rows...
-- Rolling back to savepoint sp...
-- Retrieving table structure for table t_XXX_XXX...
-- Sending SELECT query...
-- Retrieving rows...
-- Rolling back to savepoint sp...
-- Retrieving table structure for table t_XXX...
-- Sending SELECT query...
-- Retrieving rows...
-- Rolling back to savepoint sp...
mysqldump: Couldn't execute 'ROLLBACK TO SAVEPOINT sp': SAVEPOINT sp does not exist (1305)

RDS error log at the same time

```
2014-11-18 12:59:03 28522 [Note] Plugin 'FEDERATED' is disabled.
2014-11-18 12:59:03 28522 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-11-18 12:59:03 28522 [Note] InnoDB: The InnoDB memory heap is disabled
2014-11-18 12:59:03 28522 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-11-18 12:59:03 28522 [Note] InnoDB: Memory barrier is not used
2014-11-18 12:59:03 28522 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-11-18 12:59:03 28522 [Note] InnoDB: Using Linux native AIO
2014-11-18 12:59:03 28522 [Note] InnoDB: Using CPU crc32 instructions
2014-11-18 12:59:03 28522 [Note] InnoDB: Initializing buffer pool, size = 5.3G
2

Sounds like a bug from a year ago (mysqldump creates useless metadata locks)

This bug was fixed for MySQL 5.5 and I see you are using MySQL 5.6.21
SUGGESTIONS

• Don't use --lock-tables=false with --single-transaction because MySQL Documentation says "The --single-transaction option and the --lock-tables option are mutually exclusive because LOCK TABLES causes any pending transactions to be committed implicitly."

• Don't do any DDL from other DB Session while the mysqldump is in progress

GIVE IT A TRY !!!

StackExchange Database Administrators Q#82955, answer score: 3