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...
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)
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.
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.
MySQL Scaling Patterns Need more reads?○ Add Replicas via MySQL Replication○ Add Cache Tier○ Tune your ORM
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)
MySQL Scaling Patterns Need more writes?○ Time to shard! Split your data-sets into multiple clusters and scale linearly.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Q&A Laine Campbell, CEO PalominoDBhttp://www.slideshare.net/lainecampbell