RDS restore from dump time

Doing recovery test for one of my clients. I think recovery times might be useful to not-so-general public 🙂

TLDR version

.sql.gz file size: 829M
DB size after restoring: 6.2G
RDS instance: db.m1.small, MySQL 5.5.20, 50G, us-east-1b, not Multi-AZ.
Recovery tests date: 2012-08-14
Network: MySQL client in same AZ
Instance provisioning time: 8 minutes
Dump loading time: 58 minutes

More info

RDS parameter group: default.mysql5.5

RDS backups configuration: 35 days of backups

Restore command: time pv X.2.sql.gz | gunzip | mysql X

Restore command exact times:

real 57m35.001s
user 2m27.085s
sys 0m22.113s

Backup command: mysqldump --add-drop-table --add-locks --create-options --create-options --extended-insert --single-transaction --quick

Backup time: about 28 minutes.

Client: m1.small

Load on client when restoring: about 0.01, above 90% CPU idle.

Tables sizes info after recovery: SELECT data_length / 1024 / 1024 as "data", index_length / 1024 / 1024 as "index" FROM information_schema.TABLES where table_schema = 'MASKED' :

+---------------+---------------+
| data          | index         |
+---------------+---------------+
|    0.01562500 |    0.03125000 |
|    0.01562500 |    0.01562500 |
|    0.01562500 |    0.00000000 |
|    0.01562500 |    0.00000000 |
|    0.01562500 |    0.00000000 |
|    0.01562500 |    0.01562500 |
|    0.01562500 |    0.01562500 |
|    0.01562500 |    0.00000000 |
|    0.00000000 |    0.00000000 |
|    3.51562500 |    0.00000000 |
|    0.01562500 |    0.04687500 |
|    0.01562500 |    0.03125000 |
|    0.01562500 |    0.01562500 |
|    0.01562500 |    0.01562500 |
|    0.19713211 |    0.01269531 |
|    0.20276260 |    0.04687500 |
|    0.01562500 |    0.00000000 |
|    0.12012100 |    0.03613281 |
|    0.00007629 |    0.00195313 |
|    0.01562500 |    0.00000000 |
|    1.51562500 |    1.51562500 |
| 2053.00000000 | 1946.00000000 |
|   28.56250000 |   31.09375000 |
|    0.01562500 |    0.00000000 |
|    0.26562500 |    0.12500000 |
|    0.01562500 |    0.01562500 |
|    0.00000000 |    0.00000000 |
|    0.00000000 |    0.00000000 |
|    0.00000000 |    0.00195313 |
|   12.56250000 |    0.00000000 |
|    0.34375000 |    0.00000000 |
|    0.46875000 |    0.00000000 |
|    0.01562500 |    0.00000000 |
| 2139.00000000 |    0.00000000 |
+---------------+---------------+

Graphs from AWS RDS console

Screenshots were taken few minutes after restore finished.

HTH, Ilya.

Stop thinking, start doing.

Backgound

I could not find a “todo” software that would staisfy my needs so I decided to create one. The decision was also backed up by the fact that my good friend, Guy Egozy, was also very frustrated by the existing solutions.

The story

I started thinking about my “todo” software that I wanted to create. What it should include, how it should behave, etc… I was thinking for months. The important part is to realize when thinking becomes mental masturbation. Yes it is fun but it’s not productive. I admit I was slow to recognize the situation. When I did, I decided to start writing the code. It was a throw-away code, a protoype. When I had something that worked, I finally understood the following advantages:

  1. You learn a lot when implementing. No thinking + reading + analyzing will take you there. Of course you should but don’t over-do it.
  2. It’s much easiear to collaborate on. I can tell my friend all day about what I think but showing working application is a totally different story. Also he was finally able to participate by adding more code. Which he does till this day. (Thanks!)
  3. Makes possible to get any meaningful feedback from people, possible feature users.
  4. And of course you make steps toward the goal of having a good working version of the application (which we named Tagoholic), something you can share with the world, after few throw away versions.

Conclusion

Stop thinking, start doing — it’s way more productive.

P.S.

We are still working on Tagoholic. Collaboration (sharing) and mobile version are the two top requested features that are not there yet. We will let you know via Twitter when these are ready.