RDS for MySQL on AWS allows you to restore to any point in time for your backup retention period, minus the last 5 minutes or so. Restoration creates a new instance, it does not overwrite whatever instance you’re restoring. AWS’s use of the word restore is a bit confusing because restore often means “take your production database server and overwrite it with data from a backup”. As far as I can tell, Amazon never means this. When you restore, AWS creates another database server and writes all the data to the new instance, both when you’re using restoring to a point-in-time or from a DB snapshot. If you needed to switch servers, you’d have to point your database to the new instance.

Reference

One of the most common engagements I do is working with firms in and around the NYC startup sector. I evaluate AWS infrastructures & applications built in the Amazon cloud. Join 32,000 others and follow Sean Hull on twitter @hullsean. I’ve seen some patterns in customers usage of Amazon. Below is a laundry list of … Continue reading 5 core pieces of the Amazon Cloud puzzle to get your project off the ground → …

Recently, I happened to have an onsite engagement and the goal of the engagement was to move a database service to RDS Aurora. Like probably most of you, I knew the service by name but I couldn’t say much about it, so, I Googled, I listened to talks and I read about it. Now that my onsite engagement is over, here’s my first impression of Aurora.

First, let’s describe the service itself. It is part of RDS and, at first glance, very similar to a regular RDS instance. In order to setup an Aurora instance, you go to the RDS console and you either launch a new instance choosing Aurora as type or you create a snapshot of a RDS 5.6 instance and migrate it to Aurora. While with a regular MySQL RDS instance you can create slaves, with Aurora you can add reader nodes to an existing cluster. An Aurora cluster minimally consists of a …

Today I received about five emails with the subject: 3 Big Announcements from MariaDB. Maybe you did as well (else, read it online). October has brought on some very interest announcements, and I think my priority for the big announcements vary a little:

1. MariaDB Server is now available on Amazon RDS – you wouldn’t believe how many people ask for this, as many now deploy using Amazon …

There’s a strong trend to automation across the cloud. That’s a great thing for startups because it reduces operational headaches & lets them focus on building products. Join 31,000 others and follow Sean Hull on twitter @hullsean. But as that trend begins to touch the database tier, all sorts of complications emerge. Let’s take a … Continue reading When hosting data on Amazon turns bloodsport →

I spent the last 4 years at SkySQL/MariaDB working on versions of MySQL that could be “suitable for the cloud”. I strongly believed that the world needed a version of MySQL that could work in the cloud even better than its comparable version on bare metal. Users and administrators wanted to benefit from the use of cloud infrastructures and at the same time they wanted to achieve the same performance and overall stability of their installations on bare metal. Unfortunately, ACID-compliant databases in the cloud suffer from the issues that any centrally controlled and strictly persistent system can get when hosted on highly distributed and natively stateless infrastructures.
In this post I am not going to talk about the improvements needed for MySQL in the cloud - I will tackle this topic in a future post. Today I'd like to focus on the business side of RDS and Aurora. 
In the last 4 years I had endless discussions over …

If you’ve used relational databases for more than ten minutes, I hope you’ve heard of slow queries. Those are those pesky little gremlins that are slowing down your startup, and preventing scalability you so desperately need. Luckily there’s a solution. What I’ve found is if I send a report to developers every week, it keeps […]

Troubleshooting MySQL on Amazon can be a real test of patience. There are quite a few different things to watch out for in terms of connectivity & networking. Sometimes a checklist can help. Join 16,000 others and follow Sean Hull on twitter @hullsean. Here’s my exhaustive list of things that can block you. 1. Be […]

Amazon recently announced support for 5.6, unfortunately, direct upgrade from lower versions is not yet supported. On a recent migration work – running mysqldump flat out would’ve meant 6+hrs of downtime. How did we cut it off to 1h45m? Simple, run dump per table and pipe it directly to the new 5.6 instance in parallel using Percona Server’s mysqldump utility to take advantage of –innodb-optimize-keys.

Here’s the base script we used – of course, YMMV and make sure to optimize the destination instance as well!

#!/bin/bash
# export-run.sh
# This is the wrapper script which builds up the list of tables to split into $parallel parts and calls export-tables.sh

parallel=6
dblist="db1 db2 db3"
smysql="mysql -hsource-55.us-east-1.rds.amazonaws.com"
dmysql="mysql -hdest-56.us-east-1.rds.amazonaws.com" …

"Amazon to add Postgres to its most-favored database list" says GigaOM:
http://gigaom.com/2013/11/12/amazon-to-add-postgres-to-its-most-favored-database-list/"To many this is no-brainer. Amazon wants to support the databases that its developer audiences want to use. This is simply a  case of Amazon responding to user demand and oh-by-the-way making its cloud infrastructure more attractive to a specific target audience. Some say Postgres has gained traction since Oracle’s acquisition of MySQL via its Sun buyout a few years back."
Some people I know said "yea, the writing was on the wall...". Well, was it?? Really? 
AWS finally got the time to "plan" for supporting Postgres now? After supporting MySQL, Oracle and SQL Servers for almost 3 years?! Writing was on the wall? Where can I find a wall …