RDS provides fully managed MySQL, MariaDB, and Aurora database engines. It handles common database tasks to reduce management overhead and allows focusing on applications. Key features include automatic failover, backups/snapshots, scaling, security, compliance support, and integration across AWS services. Best practices involve leveraging multi-AZ, read replicas, monitoring, and storage optimization based on workload needs. Migration options include the Database Migration Service and Schema Conversion Tool.

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
September 14, 2017
Deep Dive on MySQL
Databases on AWS
Chayan Biswas
Sr. Product Manager
Amazon Web Services
Steve Abraham
Principal Specialist SA
Amazon Web Services

2. What to expect?
• RDS and MySQL databases
• Best practices
• Performance tuning
• Demo migration

3. Offering you a broad choice of fully-managed,
MySQL-compliant engines
Standard
Open source
standard MySQL
Community
Popular community
choice
Aurora
Performance
Fastest MySQL
compatible engine

4. How is Database Practitioner time spent with
RDS?
Schema design
Query construction
Query optimization
Automatic fail-over
Backup & recovery
Isolation & security
Industry compliance
Push-button scaling
Automated patching
Advanced monitoring
Routine maintenance
RDS takes care of your time-
consuming database management
tasks, freeing you to focus on your
applications and business
You AWS
Application
Optmization
Installation, Upgrades,…
Licensing, Training,
Documentation,
Security

5. Amazon RDS Key Features
• Highly Available
• Durable, Point-In-Time-Recovery, Snapshots
• Scalable
• Compute and Storage
• Secure & Compliant
• Encryption in transit and at rest
• Compliance realms
• Integration across AWS
• ... and a lot more

6. High availability

7. Enterprise-grade fault tolerance
solution for production
databases
Automatic failover
Synchronous replication
Inexpensive & enabled with one click
High Availability Multi-AZ Deployments

8. Cross-Region Read Replicas
• Bring data close to your
customer’s applications in
different regions
• Relieve pressure on your
master node for supporting
reads
• Promote a Read Replica to a
master for faster recovery in
the event of disaster
• Supports encrypted read
replicas too

9. Backups and snapshots

10. Automated Backups
MySQL, MariaDB
• Scheduled daily volume backup of
entire instance
• Archive database change logs
• Maximum 35-day retention
• Taken from standby when running
Multi-AZ
Aurora
• Automatic, continuous, incremental
backups
• No impact on database performance
• 35-day retention
Every day during your
backup window, the
RDS service creates a
storage volume
snapshot of your
database
Every five minutes,
RDS backs up the
transaction logs of
your database

11. Scaling on RDS

12. Scaling Instances
AWS Management Console

13. Security

14. Amazon VPC and Security Groups
• Amazon RDS gives each database
instance IP firewall protection (Security
Groups)
• Amazon VPC lets you isolate and
control network configuration and
connect securely to your IT
infrastructure
• AWS Identity and Access Management
(AWS IAM) provides resource-level
permission controls Availability Zone
AWS Region
10.1.0.0/16
10.1.1.0/24

15. AWS KMS for RDS standard encryption
RDS offers transparent encryption at rest and
SSL protection for data in transit
Two-tiered key hierarchy using envelope
encryption:
• Unique data key encrypts customer
data
• AWS KMS master keys encrypt data
keys
Benefits:
• Limits risk of compromised data key
• Easier to manage small number of
master keys than millions of data
keys
• Centralized access and audit of key
activity
Data Key 1 Data Key 2 Data Key 3 Data Key 4
Customer Master
Key(s)
DBDB DB DB

16. Compliance
Singapore MTCS
27001/9001
27017/27018

17. Compliance
Aurora
SOC 1, 2, 3
ISO 20001/9001
ISO 27107/27018
PCI
HIPAA BAA
MySQL
SOC 1, 2, 3
ISO 20001/9001
ISO 27107/27018
PCI
FedRamp
HIPAA BAA
UK Gov. Programs
Singapore MTCS
MariaDB
 SOC 1, 2, 3
 ISO 20001/9001
 ISO 27107/27018
 PCI
 New! HIPAA BAA

18. Engine Specifics
Amazon Aurora

19. RDS MySQL
• Most popular open-source database engine
• Support for MySQL Community Edition versions 5.5, 5.6
and 5.7
• InnoDB and MyISAM storage engines
• Version 5.7 - New Features
• JSON support
• Query optimizer improvements
• GIS extensions
• Improved parallel replication
• Dynamic buffer pool resizing
• Version 8.0 coming soon

20. RDS MariaDB
• Support for versions 10.0 and 10.1
• Same instance, regions, pricing as RDS MySQL
• Differences from RDS MySQL
• XtraDB and Aria storage engines only
• Thread Pooling
• GTID
• Version 10.1 - New Features
• XtraDB page compression, data scrubbing, and defragmentation
• Optimistic in-order parallel replication
• ORDER BY optimization
• Version 10.2 coming soon

21. Amazon Aurora
• Performance and availability of commercial databases
• Simplicity and cost-effectiveness of open-source
databases
• Drop-in compatibility with MySQL/InnoDB
• Scale-out, distributed, multi-tenant architecture
• Integrations:
 Invoke AWS Lambda functions from SPs and triggers
 Load from, Select into, and backups in S3
 IAM role for database access control
• MySQL 5.7 compatibility coming soon
Amazon Aurora

22. MariaDB Audit Plug-in for MariaDB and MySQL
• Provides customer configurable event logging for
database activity
• Auditable events include logins, queries, and tables accessed
• Individual users can be included or excluded from the audit
• The MariaDB audit plug-in is supported on the following
RDS versions
• MySQL 5.6.29
• MySQL 5.7.11
• MariaDB 10.0.24
• MariaDB 10.1.14
• Available via RDS option group
• May impact performance

23. New! Stop and Start instances
• Ideal when you don’t need the database
running all the time
• Think DevTest
• Pay only for storage, backups, and snapshots
• Retain configuration: endpoint, parameter
group, security group…
• Automatically starts in 7 days

24. MySQL / MariaDB Best Practices
Leverage Multi-AZ Configurations
• Pros: High availability for planned and unplanned events
• Cons: Additional hourly charge, increased latency
Leverage Read Replicas
• Pros: Read scalability, disaster recovery, upgrades
• Cons: Application must handle asynchronous behavior, watch
log storage on master
Leverage Enhanced Monitoring
• Pros: Additional information for tuning and troubleshooting
• Cons: CloudWatch Logs charge (small)
* Excluding micro instance classes

25. Enhanced Monitoring (All Engines)
50+ system/OS metrics | sorted process list view | 1-60 sec granularity
alarms on specific metrics | egress to CloudWatch Logs | integration with 3rd-party tools

26. MySQL / MariaDB Best Practices
Use RDS provided stored procedures for managing
sessions, queries, and read replicas
• mysql.rds_kill(processID) to terminate a connection
• mysql.rds_kill_query(queryID) to terminate a query
• mysql.rds_stop_replication to manually stop replication
• mysql.rds_skip_repl_error to skip the current replication error
• mysql.rds_next_master_log to change the master log position on
the replica

27. MySQL / MariaDB Logging Best Practices
Enable MySQL general and slow query logs for
troubleshooting
• The logs can be written to a CSV table or file
• The long_query_time database parameter sets the threshold for
slow queries
• Avoid large CSV table logs by using the following stored
procedures to rotate these logs
• mysql.rds_rotate_general_log
• mysql.rds_rotate_slow_log
• Disable the general and slow query logs if they are not actively
being used for diagnosis or troubleshooting
• The general and slow query logs can impact database
performance, especially if long_query_time is set to a low value

28. MySQL / MariaDB Replication Tips
Replicas can be made writeable
• Useful for changes like adding an index for reporting
• Think of it as “breaking the warranty”
RDS supports managed replication chaining (source >
target > target)
• Replica in one region and then a cross-region replica in another
region
RDS limits 5 replicas to per master (can be extended upon
request)
RDS instances support non-managed replication
• Useful for on-premises to RDS, EC2 to RDS scenarios
• Uses stored procedures rather than service API for managing

29. MySQL / MariaDB Storage Types
The type of storage can make a big difference for I/O
intensive operations
• Magnetic – Low cost but IOPS and latency can vary
• General Purpose (GP2) – SSD based storage with 3K IOPS burst capability
then a baseline rate of 3 IOPS per GB. Throttled via a credit-based system.
Great for storage below 1 TB especially when you do not deplete credits.
• Provisioned IOPS (PIOPS) – SSD based storage with defined IOPS rates that
are a 3.0-10.0 ratio between IOPS and storage. Great when you need consistent
performance without worrying about running out of credits or when you need
more than 10K IOPS.
For almost all use cases we recommend an SSD-based
storage type
• Magnetic storage has average IOPS and latencies that are an order of
magnitude slower than SSD-based storage.
• GP2 is the default and makes sense until you start to go above 1 TB.

30. MySQL / MariaDB Storage Best Practices
Fast, consistent storage is important since many routine
operations can be heavily I/O dependent
• Crash Recovery – InnoDB/XtraDB needs to scan through certain files as well as
rollback and roll-forward transactions.
• Engine Upgrades – MySQL scans through all tablespaces during a minor or
major engine version upgrade.
• DDL – MySQL can do online DDL which means it is copying a potentially large
table. Index creations and rebuilds also are I/O intensive.
Multi-AZ failovers can be less than a minute with most of
the downtime in DNS propagation
• If MySQL needs to do a crash recovery or other I/O intensive operation before it
can start, the speed of storage could mean downtime is several minutes or even
hours

31. MySQL / MariaDB Storage Tips
GP2 is a great choice but be careful about burst credits on
volumes > 1TB
• Hitting credit depletion results in IOPS drop. Latency and queue depth metrics
will spike until credits are replenished.
• Monitor read/write IOPS to see if average IOPS is greater than the baseline.
Think of GP2 burst rate and PIOPS stated rate as
maximum I/O rates.
• Your application needs to actually run an I/O intensive workload to hit these rates
• Multi-AZ introduces an extra commit
latency so MAZ IOPS will typically be
lower compared to SAZ
Use EBS-optimized instance type
when using either GP2 or PIOPS

32. Migrating onto RDS

33.  Move data to the same or different database engine
 Keep your apps running during the migration
 Start your first migration in 10 minutes or less
 Replicate within, to, or from Amazon EC2 or RDS
AWS Database
Migration Service

34.  Migrate from Oracle and SQL Server
 Move your tables, views, stored procedures,
and data manipulation language (DML) to
MySQL, MariaDB, and Aurora
 Highlight where manual edits are needed
AWS Schema
Conversion Tool

35. Migration Demo

37. Getting started with Amazon RDS for MariaDB
Information
https://aws.amazon.com/rds/mariadb
Pricing
https://aws.amazon.com/rds/mariadb/pricing/
MariaDB user guide
https://docs.aws.amazon.com/AmazonRDS/l
atest/UserGuide/CHAP_MariaDB.html

38. Getting started with Amazon RDS for MySQL
Information
https://aws.amazon.com/rds/mysql/
Pricing
https://aws.amazon.com/rds/mysql/pricing/
MySQL user guide
http://docs.aws.amazon.com/AmazonRDS/la
test/UserGuide/CHAP_MySQL.html

39. Getting started with Amazon Aurora
Information
https://aws.amazon.com/aurora/
Pricing
https://aws.amazon.com/aurora/pricing/
Aurora user guide
http://docs.aws.amazon.com/AmazonRDS/la
test/UserGuide/CHAP_Aurora.html
Amazon Aurora

40. Thank you!