What is Amazon RDS?

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. That means that you can have your MySQL database operate on Amazon’s cloud computers located all over the world. Just like they say:

Amazon RDS gives you access to the full capabilities of a familiar MySQL database. This means the code, applications, and tools you already use today with your existing MySQL databases work seamlessly with Amazon RDS. Amazon RDS automatically patches the database software and backs up your database, storing the backups for a user-defined retention period. You also benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your relational database instance via a single API call.

According to Amazon there is no need to make any changes to your application in order to use Amazon RDS. Well, at least for WordPress and WordPress-MU they are right.

A standard WordPress installation, using Amazon RDS, is located at WordPressRDS.com and a WordPress-MU (the kind of WordPress that wordpress.com uses) is located at mu.WordPressRDS.com. I will keep this installation alive for a few days and then take it down since the use of Amazon RDS is not free.

If you would like to help me finance this demo please consider a donation via PayPal.

Amazon RDS is charged by the hour + storage + I/O requests and in and out data transfer (see full pricing). The smallest database instance you can get is with 1.7GB RAM with the cost of 0.11$ per hour. If you run a full month it sums up to about 82$/month. The next level is a huge jump to a large instance of 7.5GB RAM with the cost of 0.44$ per hour (~330$/month). However, for those who are seeking a multi-db solution for WordPress MU may consider testing two or three small instances.

So lets get started!

The first thing you will have to do is setup an Amazon RDS instance. If you don’t have an account with Amazon you should creat an AWS account. Once you have an account you may signup for Amazon RDS.

To set up the RDS instance read some of the resources available. If you use WordPress you probably would start with the PHP sample code. I may give specific code samples at a later time but you will have to use the following APIs (in this order):

1. CreateDBSecurityGroup – setup a database security group.
2. AuthorizeDBSecurityGroupIngress – authorize access from your servers IP for the above group.
3. CreateDBInstance – set up the instance and first database (including root user, password and database name).

If all goes well you may check the instance using the DescribeDBInstances API call and look for the ‘Status‘ field making sure it is in ‘Available‘ state. In the results of this call you will also see the unique host name of the database. Amazon calls it ‘endpoint address‘. If you got it your are done!

Now setup WordPress (or WordPress Mu)

The final step is to run a regular setup of WordPress (or WordPress MU). You are probably familiar with the setup screen (click on the image to enlarge):

See the ‘DataBase Host‘ field? That is where the ‘endpoint address‘ goes. I guess this is one of those other 1% cases. Now just continue the installation as usual.

A WordPress MU installation is just the same:

I have installed WordPress and WordPress-MU on Amazon RDS at WordPressRDS.com. Check it out and please consider a donation via PayPal to keep these installation running.

<?php
function new_blogs_setting( $blog_id )  {
//set your options here:
add_option('gmt_offset', 2);
// stop editing here
return;
}
add_action('populate_options', 'new_blogs_setting');
?>

Download here.

Some of the new features in this release of MU:

1. Version number is 2.6 rather than 1.6 because it just makes sense to synchronise the major version numbers.
2. Signup page now has a nonce which should help in the fight against spammers, for a short while anyway.
3. Redirecting to the signup page for 404s and for unknown blogs is not enabled by default. Check out wp-config-sample.php for instructions.
4. “allowed_themes” filter, much like the plugins filtered added previously.
5. New functions: get_id_from_blogname(), is_main_blog().
6. get_blog_details() can now take a blogname as well as a blog_id.
7. Custom first posts didn’t always work. Now they do.
8. Blognames in the “Add blog” form in wpmu-blogs.php are now sanitized.
9. Added “pre_site_option_*” and “site_option_*” filters like the similar option filters.
10. Meta fields will be passed on signup again.
11. Added an “admin_header_navigation” filter so the top right navigation in the backend can be customised.
12. The signup page uses “blogname” instead of “blog_id” to avoid confusion with the global variable of the same name. Plugins will break if not updated!

Grab it here.

The version number is being bumped to 2.6 rather than 1.6 because of version confusion.

Signup page now has a nonce to help defeat spammers.

Plugins in wp-content/plugins/ are version checked like in WordPress. mu-plugins isn’t covered just yet.

Major object cache changes.

And many more bug fixes. Check the timeline for a list of changes.

Download wordpress-mu-2.6-beta1.zip

Here are the instructions:

This script checks the WPMU database for blogs that have not been updated for X days, then sends a notice to the blogowner that the blog will be deleted after Y days.

It also automatically deletes blogs that have not been updated for Y days, then sends an email to the blog owner.

On both occasions, the script will send a report with details on warned and deleted blogs to the administrator.

This script has *NOT* been programmed as a plugin since it is intended to be executed by a cronjob. As it is now it should be run once every 7 days, but you can configure it to do otherwise.

This script is *NOT* a final version and should be used with caution and only if you know what you are doing. I recommend testing it on a testsite rather than a livesite.