The cool stuff:

• It is well documented, and pretty easy to set up an instance.
• You can dynamically change the class (CPU power and Memory) of a database instance – this means you can give it more power without shutting it down, and easily scale it without having to do complex MySQL proxy configuration and synchronisation.

What’s still missing:

• Not available in EU yet (it should be soon) – I set up a few instances in the US, but can’t really test what the performance is in the EU between EC2 instances and RDS instances, and that’s what I’m really interested in…
• I takes a long time for the instance to become available!  I was waiting between 5 and 30 minutes.  I guess that’s not such an issue if you are just creating it once and leaving it running as the data hub for an application, but it’s annoyingly slow for testing/playing.  At least they don’t seem to start billing for time until it is online.

Other interesting notes

• If you start the instance without any parameters, it will have a typical configuration for the machine used (memory allocation spread between InnoDB and MyISAM).  It is however possible to specify parameters when the instance is started, or even during run time – this gives a lot of room for optimisation: it’s not just a dumb service, you can tune it to your requirements.
• Just for kicks and giggles, I tried scaling a small instance to a large instance, without any custom parameters: the only change was allocating all the additional memory to innodb_buffer_pool_size.  I guess that’s what most people want…

Most operating systems have a user privilege granting system where privileges are given to groups, and users are asigned to groups, thereby inheriting all the privileges of this group. Unfortunately this is not currently (using MySQL server version 5.1) natively possible: the privileges must be defined for every user. Managing a MySQL installation with many users can become a very laborious, and non transparent process, and many admins opt to have fewer MySQL users, with many real users using one MySQL user with the desired privileges. This increases difficulty in managing the server, because you never have just the right set of privileges for a given person, nor can you quickly determine which processes are being carried out by which person.

Following is a work around to implement a kind of group privilege management in MySQL.

Setup

See attached procedure and creates to set it up the tables on your system.

Two additional tables must be defined to hold the groups.  These are created in a new `mysql_meta` database (must be created first). The first table contains a list of the users which should be managed, and the groups which they are in. The second table contains a list of the privileges given for each group.

After entering the users, groups, the procedure updateMysqlUserPrivileges when called will first revoke all privileges from all users listed, and then proceed to grant the privileges anew. This is not very elegant… but if it was, I wouldn’t call it a workaround!

It should be noted at this point that every user listed will be processed. That means that if a user is defined, but he has no group, or no privileges defined, all his privileges will be revoked, and he will be left with nothing but USAGE on the server.

Adding users

Users must be defined manually before adding them to the mysql_meta tables:

CREATE USER newuser@localhost IDENTIFIED BY 'password';

You can then add your user to the mysql_meta.user_groups table. If the user should belong to multiple groups, make multiple entries in this table, one for each group.

In the mysql_meta.user_group_privileges you can now define the privileges which should be given to each group. Please note that I have simplified by using one column `schema` to contain the database/table definition. As a result, it is not currently possible to grant permissions to specific columns. For example:

INSERT INTO `mysql_meta`.`user_groups` (`user`,`host`,`user_group`)
   VALUES( 'newuser','localhost','newgroup');
INSERT INTO `mysql_meta`.`user_group_privileges`
  (`user_group`,`schema`,`privilege_type`,`isa`)
  VALUES ( 'newgroup','mydb.*' ,'SELECT','TABLE'),
  ('newgroup','mydb.*','UPDATE'),
  ('newgroup','mydb.*','INSERT','TABLE'),
  ('newgroup','mydb.fancyProcedure','EXECUTE','PROCEDURE');

Would be equivalent to:

GRANT UPDATE, INSERT, SELECT ON mydb.* TO newuser@localhost;
GRANT EXECUTE PROCEDURE ON mydb.fancyProcedure TO newuser@localhost

Committing new privileges

Once the new privilege tables are completed, simply call the procedure to update:

CALL mysql_meta.updateMysqlUserPrivileges;

And here we stumble on another shortcoming of MySQL: there is no real way to do error handling in procedures or functions… I have opted to return a row with two columns: “Errors” and “Warnings”. If any users are defined in the user_groups table, but are not yet created as MySQL users, these will be listed as Errors, and if there are users which are defined, but which have no privileges, they will be listed in the Warnings column.

What I wanted: keep archive data in a compact, non modifiable table (I chose packed MyISAM tables), and live data in a transactional table (I chose InnoDB), possibly even on two different machines.  I was thrilled when I found the article linked above, with the sweet idea how to create a view which would combine both, and imagined that while it would make a performance hit, it shouldn’t be that bad, because the data in the packed, optimised MyISAM tables should have much faster access than the InnoDB, and given that the volume of the data is in there, and all select conditions are on indexed columns, it should be pretty fast.

WRONG!

Views using a UNION are very poorly optimised, and create complete temporary tables before matching any where conditions.  Even on a COUNT(*) which should not even require /any/ data to be retreived, it took significantly longer.

Here by example:

Get the sample employees database here, and load it.

Create a test database, and a salaries table in it:

(root@127.0.0.1) [employees]>CREATE DATABASE `test`;
(root@127.0.0.1) [employees]>CREATE TABLE `test`.`salaries` (
  `emp_no` int(11) NOT NULL,
  `salary` int(11) NOT NULL,
  `from_date` date NOT NULL,
  `to_date` date NOT NULL,
  PRIMARY KEY (`emp_no`,`from_date`),
  KEY `emp_no` (`emp_no`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Then split the table salaries:

(root@127.0.0.1) [employees]>INSERT INTO `test`.`salaries` SELECT * FROM `employees`.`salaries` WHERE emp_no<242293;

(root@127.0.0.1) [employees]>DELETE FROM `employees`.`salaries` WHERE emp_no<242293;

How long does it take to count each one?

(root@127.0.0.1) [employees]>SELECT SQL_NO_CACHE COUNT(*) FROM `employees`.`salaries`;

+----------+

| COUNT(*) |

+----------+

|  1492975 |

+----------+

1 row in set (0.30 sec)

(root@127.0.0.1) [employees]>SELECT SQL_NO_CACHE COUNT(*) FROM `test`.`salaries`;

+----------+

| COUNT(*) |

+----------+

|  1351072 |

+----------+

1 row in set (0.29 sec)

That’s ok, and we see from the explain that it is indeed using a SIMPLE select, using the index on epm_no:

(root@127.0.0.1) [employees]>EXPLAIN SELECT SQL_NO_CACHE COUNT(*) FROM `test`.`salaries`;

+----+-------------+----------+-------+---------------+--------+---------+------+---------+-------------+

| id | select_type | table    | type  | possible_keys | key    | key_len | ref  | rows    | Extra       |

+----+-------------+----------+-------+---------------+--------+---------+------+---------+-------------+

|  1 | SIMPLE      | salaries | index | NULL          | emp_no | 4       | NULL | 1351439 | Using index |

+----+-------------+----------+-------+---------------+--------+---------+------+---------+-------------+

1 row in set (0.01 sec)

So let’s make a view and join the tables, and try that again on the view:

(root@127.0.0.1) [employees]>CREATE VIEW salaries_all AS SELECT * FROM `employees`.`salaries` UNION ALL SELECT * FROM `test`.`salaries`;

(root@127.0.0.1) [employees]>EXPLAIN SELECT SQL_NO_CACHE COUNT(*) FROM `employees`.`salaries_all`;
+----+--------------+------------+------+---------------+------+---------+------+---------+------------------------------+
| id | select_type  | table      | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+----+--------------+------------+------+---------------+------+---------+------+---------+------------------------------+
|  1 | PRIMARY      | NULL       | NULL | NULL          | NULL | NULL    | NULL |    NULL | Select tables optimized away |
|  2 | DERIVED      | salaries   | ALL  | NULL          | NULL | NULL    | NULL | 2713588 |                              |
|  3 | UNION        | salaries   | ALL  | NULL          | NULL | NULL    | NULL | 1351439 |                              |
| NULL | UNION RESULT | <union2,3> | ALL  | NULL          | NULL | NULL    | NULL |    NULL |                              |
+----+--------------+------------+------+---------------+------+---------+------+---------+------------------------------+
4 rows in set (9.85 sec)

Oh my god!

Even a query with sub-queries is faster by a factor of 20!

(root@127.0.0.1) [employees]>SELECT SQL_NO_CACHE ( SELECT COUNT(*) FROM `test`.`salaries` ) + ( SELECT COUNT(*) FROM `employees`.`salaries` );

+----------------------------------------------------------------------------------------------+

| ( SELECT COUNT(*) FROM `test`.`salaries` ) + ( SELECT COUNT(*) FROM `employees`.`salaries` ) |

+----------------------------------------------------------------------------------------------+

|                                                                                      2844047 |

+----------------------------------------------------------------------------------------------+

1 row in set (0.56 sec)

(root@127.0.0.1) [employees]>EXPLAIN SELECT SQL_NO_CACHE ( SELECT COUNT(*) FROM `test`.`salaries` ) + ( SELECT COUNT(*) FROM `employees`.`salaries` );

+----+-------------+----------+-------+---------------+--------+---------+------+---------+----------------+

| id | select_type | table    | type  | possible_keys | key    | key_len | ref  | rows    | Extra          |

+----+-------------+----------+-------+---------------+--------+---------+------+---------+----------------+

|  1 | PRIMARY     | NULL     | NULL  | NULL          | NULL   | NULL    | NULL |    NULL | No tables used |

|  3 | SUBQUERY    | salaries | index | NULL          | emp_no | 4       | NULL | 2713588 | Using index    |

|  2 | SUBQUERY    | salaries | index | NULL          | emp_no | 4       | NULL | 1351439 | Using index    |

+----+-------------+----------+-------+---------------+--------+---------+------+---------+----------------+

3 rows in set (0.00 sec)

I guess for now I’ll have to wait till views are optimised before I can use them like this…