The “Too many connections” problem is a common issue with applications using excessive permissions (and those that grant said global permissions). MySQL will always grant a user with SUPER privileges access to a DB to investigate the problem with a SHOW PROCESSLIST and where you can check the limits. I however found the following.

mysql> show global variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 2000  |
+-----------------+-------+
1 row in set (0.00 sec)

mysql> show global status like 'max%';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 6637  |
+----------------------+-------+
1 row in set (0.00 sec)

How can the max_used_connection exceed max_connections? This is possible because you can dynamically change max_connections in a normal MySQL environment. However …

To expand on Jervin’s Default RDS Account Privileges, RDS for MySQL provides a number of routines and triggers defined the the ‘mysql’ meta schema. These help in various tasks because the SUPER privilege is not provided.

SELECT routine_schema,routine_name
FROM information_schema.routines;
+----------------+-----------------------------------+
| routine_schema | routine_name                      |
+----------------+-----------------------------------+
| mysql          | rds_collect_global_status_history |
| mysql          | rds_disable_gsh_collector         |
| mysql          | rds_disable_gsh_rotation          |
| mysql          | rds_enable_gsh_collector          |
| mysql          | rds_enable_gsh_rotation           |
| mysql          | rds_kill                          |
| mysql          | rds_kill_query                    |
| mysql          | …

I was searching looking for the PRIVILEGES that comes with the primary MySQL account on RDS, but it looks like this is not documented anywhere nor blogged about yet. So for the sake of other users, here it is:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'revin'@'%' IDENTIFIED BY PASSWORD '*xxxxxxxxxxxxxxxxxxx' WITH GRANT OPTION

In case you ask, for what, I was looking for what privileges I can grant other users via the primary account.

Tungsten Replicator 2.0.7 enables new MySQL versions, provides better support for multi-master and parallel replication, and improves setup of advanced topologies. In the MySQL area, we have added the ability to replicate from MySQL into Amazon RDS instances, as well as initial certification for MySQL 5.6. 

There are several important new features for multi-master replication, including better

TempoDB’s timely DBaaS for the Internet of Things. ScaleBase 2.0. And more

For 451 Research clients: TempoDB has timely database service for the Internet of Things bit.ly/YcQuqA

— Matt Aslett (@maslett) February 13, 2013

For 451 Research clients: ScaleBase provides centralized management of distributed MySQL databases bit.ly/YcQTcs

— Matt Aslett (@maslett) February 13, 2013

For 451 Research clients: XtremeData turns its attention to cloud-based data warehousing bit.ly/XB7MLY

— Matt Aslett (@maslett) …

There have been a number of comments that Amazon RDS does not allow users access to MySQL replication capabilities (for example here and here).  This is a pity. Replication is one of the great strengths of MySQL and the lack of it is a show-stopper for many users.  As of the latest build of Tungsten Replicator half of this problem is on the way to being solved. You can now set up real-time replication from an external MySQL master into an Amazon RDS instance.

In the remainder of this article I will explain how to set up Tungsten replication to an Amazon RDS slave, then add a few thoughts …

RDS has created some basic tooling for looking at the internal status variables within MySQL called Global Status History or "GoSH" though unfortunately the tooling is broken.

The tooling, detailed at the following link here is meant to snapshot the output of "show status" and squirt the data into a table in the MySQL schema called mysql.rds_global_status_history.

The issue is that the bootstrapped event called 'ev_rds_gsh_collector' is missing and therefore the procedures to enable the snapshotting fail.

It appears that whenever an RDS instance is started (or bounced) the contents of the 'mysql' schema is re-created - therefore the injection of the row into the event table is missing from whatever init script AWS has.

To 'fix' GoSH you can …

RDS instance details

• sysbench seeded 100Gb database and then snapshotted
• 1Tb of RDS storage for the database
• RDS MySQL 5.5.27
• Default my.cnf RDS configuration except (find the full 'show global variables' output at the end of this post)
  • performance_schema is enabled
  • innodb_flush_logs_at_trx_commit = 0
• provisioning an RDS instance for each instance size / PIOPS configuration from the seeded database. (10 in total) 

Test details

• Amazon RDS 
• Within an AWS VPC
• US-East

First warm up innodb by running sysbench with options

• oltp table size 1000000000
• max-requests 0
• max-time 300 (5 minute warm up)
• oltp test mode complex
• oltp index …

We are doing a migration from Amazon RDS to EC2 with a customer. This, unfortunately, involves some downtime – if you are an RDS user, you probably know you can’t replicate an RDS instance to an external server (or even EC2). While it is annoying, this post isn’t going to be a rant on how RDS can make you feel locked in. Instead, I wanted to give you a quick tip.

So here’s the thing – you can’t stop replication on RDS read replica, because you don’t have (and won’t get) privileges to do that:

replica> STOP SLAVE;
ERROR 1045 (28000): Access denied for user 'usr'@'%' (using password: YES)

Normally, you don’t want to do that, however we wanted to run some pt-upgrade checks before we migrate and for that we needed the read replica to stop replicating. Here’s one way to do it:

WARNING! …

I recently came across a dev VM running MySQL 5.0.77 (an old release, 28 January 2009) that didn’t have InnoDB available. skip-innodb wasn’t set, SHOW VARIABLES LIKE '%innodb%' looked as expected, but with one exception: the value of have-innodb was DISABLED.

I confirmed this with SHOW ENGINES:

(root@localhost) [(none)]> show engines;
+------------+----------+----------------------------------------------------------------+
| Engine     | Support  | Comment                                                        |
+------------+----------+----------------------------------------------------------------+
| MyISAM     | DEFAULT  | Default engine as of MySQL 3.23 with great performance         |
| MEMORY     | YES      | Hash based, stored in memory, useful for temporary tables      |
| InnoDB     | DISABLED | Supports transactions, row-level locking, and …