Amazon Web Services offer new challenges and flexibility for database admins -- here's how to avoid the pitfalls and tune for performance

For many MySQL database admins, Amazon Web Services represents the brave new world of cloud computing -- one fraught with disappearing servers, disk I/O variability, and other shared resource challenges, not to mention questions regarding the security of data.

But for those seeking to tap the powerful flexibility that cloud computing affords MySQL database deployments, AWS should be viewed simply as the next natural step in data center evolution -- one in which virtualization and commodity hardware are a given, and scalability, performance, and high availability are readily attained.

To help DBAs take advantage of what Amazon.com offers, we've compiled the following primer on managing MySQL databases in Amazon's cloud. Along the way, you'll find essential tools and techniques for migrating databases to AWS, tuning them for high performance and high availability, and avoiding the pitfalls of computing in the cloud.

Demystifying deployment and disappearing servers

Of all the steps to ensure a successful AWS deployment, spinning up a basic instance is the simplest. More challenging is dealing with the new reality of disappearing servers.

To get started, download the Amazon API tools and install. Next set up your environment variables (EC2_HOME, EC2_PRIVATE_KEY, EC2_CERT; you may also need to set JAVA_HOME and PATH), spin up your instance, fetch the name of your new instance, and connect:

Set the root password on your new MySQL instance, and you're ready to begin.

Perhaps the most difficult shift you'll make in adapting your thinking to cloud computing is around virtual machines themselves. AWS instances are built on virtualization technology, and although they sit on top of physical hardware that behaves much like the servers you're used to, the virtual machines are not as reliable as physical ones. These machines can disappear out from under you and your application without notice. As such, redundancy, high availability, and scripted automation are key. Such pressures also put disaster recovery front and center. Now no longer relegated to a best practices list of tasks you'll get to when other pressing problems are resolved, disaster recovery becomes an urgent priority.

Take, for example, what the operations team at Netflix decided to do. They wanted to meet this server reliability question head on, so they built a piece of software that would play Russian roulette with their servers. The resulting Chaos Monkey randomly knocks out servers in their production environment in the middle of the day. What's more incredible is how this illustrates two sides to the AWS cloud coin. On one hand, the servers aren't as reliable; on the other, Amazon provides the tools with which to build in all the redundancy you need.

For example, Amazon makes using multiple data centers seamless. They organize the objects (AMIs, snapshots, instances, and so forth) around the availability zones and regions in the environment. There are currently seven regions to choose from outside of AWS GovCloud, including Virginia, Oregon, California, Ireland, Singapore, Japan, and Brazil. Each region includes multiple data centers. Replicate your database data between these regions, build and keep fresh your server images, and automate push-button rebuilds to run with the most robust and fault-tolerant infrastructure possible.