Running MySQL in AWS


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Running MySQL in AWS

  1. 1. Laine Campbell, CEO PalominoDBRunning MySQL in AWS The next generation in RDBMS
  2. 2. Why Amazon Web Services? Infrastructure as a Service● No more waiting for hardware.● No more managing hardware.● No more aged out hardware.
  3. 3. Why Amazon Web Services? Elasticity
  4. 4. Why Amazon Web Services? Financial Considerations● Cloud expenses are opex, not capex - fully deductible the first year.● Eliminate hardware inventory.● Reduce costs of administrators, facilities, network, etc...
  5. 5. Why MySQL? A Known Quantity● Easy to find developers and operators.● Extensive documentation, community and tribal knowledge.● Well documented knowledge of bugs, with multiple vendors supporting, improving and operating. (slowing down on Oracle front)
  6. 6. Why MySQL? But is it Web Scale?● Scaling patterns are well understood.● With proper tuning and knowledge, can support the vast majority of workloads.● Relational data is often the right tool for the right workload.● Data consistency and recoverability isnt as optional as many believe.
  7. 7. MySQL Scaling Patterns Need more transactions?Vertical Scaling○ Tune your SQL.○ Manage your configs.○ Add MOAR RAM○ Add MOAR DISK○ Add MOAR CPU○ Add of all the things.
  8. 8. MySQL Scaling Patterns Need more reads?○ Add Replicas via MySQL Replication○ Add Cache Tier○ Tune your ORM
  9. 9. MySQL Scaling Patterns Replication Lagging?○ Functional Partitioning - Break out workloads into separate clusters.○ Split database schema into multiple schemas - use parallel replication. (5.6, or Tungsten)○ Stop abusing MySQL! Some workloads dont belong in a relational database! (logs, queues, massive non- transactional reads)
  10. 10. MySQL Scaling Patterns
  11. 11. MySQL Scaling Patterns Need more writes?○ Time to shard! Split your data-sets into multiple clusters and scale linearly.
  12. 12. Options for Running MySQL Amazon Relational Database Service (RDS)● Choose your instance size.● Choose your major MySQL Version.● Choose from a few topology options.● Choose your parameter configuration.● Choose your region and availability zone.
  13. 13. Your RDS MySQL Master Stand-Alone or Multi-AZ● Stand-Alone: ○ If it goes away, you must use backups to recover. ○ Less expensive than multi-AZ, good for prototyping. ○ With replicas, you can use standard failover/replica promotion. ○ Storage up to 1 TB. (auto striping over 300 GB for higher performance) ○ Provisioned IOPs allow for predictable I/O performance. ○ Choose your region and availability zone.
  14. 14. Multi-AZ Failover● A Highly Available Master: ○ Uses synchronous data replication to keep a failover ready. ○ Auto-failover. ○ Redundancy for less than 2x the cost.● The Problems: ○ Failover happens more often than you might think. ○ Failovers are impacting for up to 30 seconds. ○ If relaxing binlog flushes, failovers can disrupt your replication topology. ○ Synchronous replication reduces write capacity.
  15. 15. Multi-AZ FailoverFrom AWS Blog
  16. 16. MySQL Replicas● Push Button Replicas ○ Rapid deployment of replicas via snapshot. ○ Promotion to masters: ■ For non-multi AZ failover. ■ For standalone dev/test environments.● The Problems: ○ Builds can cause some load issues on your master. ○ Only one built at a time. ○ All must be identical. ○ No complex replication topologies.
  17. 17. RDS Gotchas● Parameter Groups ○ Must change from Default to use dynamic variables. ○ Configuration changes become more complex.● Limited Access ○ No root/super-user access. ○ No direct management of replication. ○ No access to error logs or binlogs.● Other Concerns ○ Minimal visibility to system issues ○ No OS access for diagnostics
  18. 18. Options for Running MySQL Amazon Elastic Compute Cloud (EC2)● Not Database As a Service● Build your own instances, choosing your Operating system, compute resources and RAM.● Multiple Regions, and availability zones within a region for redundancy.
  19. 19. Running MySQL in EC2Storage Options● EC2 comes with ephemeral storage by default. ○ If your instance restarts, you lose the data. ○ SSD options available.● Use Elastic Block Storage (EBS) for persistence. ○ EBS volumes can be RAIDed for higher IO throughput. (not for higher availability) ○ Snapshots are a highly desirable backup mechanism.
  20. 20. Running MySQL in EC2Choosing MySQL● Unlike RDS, you can choose your binaries. ○ MySQL 5.1, 5.5, 5.6, MariaDB, Percona XtraDB, Drizzle.● Unlike RDS, you can choose your replication topology: ○ Standard master/slave ○ Master/master ○ Tiered replication● Unlike RDS, you can replicate across regions for disaster recovery.
  21. 21. Running MySQL in EC2● Options for reducing management overhead ○ Roll your own config mgmt via Chef, Puppet, Ansible ○ Script it yourself (really?) ○ Continuent Tungsten can provide full cluster management with similar cost of RDS, and none of the RDS gotchas.
  22. 22. Pros of MySQL in EC2● Advanced configurations (topologies, heterogenous instance types or storage types) allow DBAs to build truly custom solutions.● Access to the OS, all logs, root user and full management.● Fewer RDS gotchas (rds specific admin tasks, surprises mid-operation, etc...)● DBA overhead not as high as you might think for commoditized tasks.
  23. 23. Pros of MySQL in EC2● EC2 Reserved instances can be reused by non-DB tiers (cache, app, file, etc...) vs. RDS reserved instances which must be MySQL.● Snapshots allow for easy building of test environments.● Access to advanced topologies means much less downtime for rolling migrations and upgrades.● Multi-region disaster recovery.
  24. 24. Pros of MySQL in RDS● RDS push button tasks are super easy and useful.● Allows DBAs to focus immediately on high value tasks (sql tuning, data modeling, scaling plans)● Can help enable developers (can also help them shoot themselves in the foot!)● No need to build out your own failover mechanisms.
  25. 25. Q&A Laine Campbell, CEO PalominoDB