What’s New in Amazon Aurora

Amazon Web Services
Steve Abraham
Principal Solutions Architect
What’s New in Amazon Aurora

Amazon Web Services Confidential - Shared Under NDA
Agenda
Introduction
Performance
Availability
What is Aurora?
Aurora availability architecture
Aurora performance: design and
enhancements
Recent Announcements New features and capabilities

Amazon Aurora ……
Databases reimagined for the cloud
Delivered as a managed service
 Speed and availability of high-end commercial databases
 Simplicity and cost-effectiveness of open source databases
 Drop-in compatibility with MySQL and PostgreSQL
 Simple pay as you go pricing

Re-imagining the relational database
Fully managed service – automate administrative tasks
1
2
3
Scale-out, distributed, multi-tenant design
Service-oriented architecture leveraging AWS services

Scale-out, distributed, multi-tenant architecture
Master Replica Replica Replica
Availability
Zone 1
Shared storage volume
Availability
Zone 2
Availability
Zone 3
Storage nodes with SSDs
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
• Purpose-built log-structured
distributed storage system
designed for databases
• Storage volume is striped across
hundreds of storage nodes
distributed over 3 different
Availability Zones
• Six copies of data, two copies in
each Availability Zone to protect
against AZ+1 failures
• Plan to apply same principles to
other layers of the stack

Leveraging cloud eco-system
AWS Lambda
Amazon S3
IAM
Amazon CloudWatch
Invoke AWS Lambda events from stored procedures/triggers.
Load data or Select into Amazon S3; store snapshots and backups in S3.
Use AWS Identity & Access Management (IAM) roles to manage database
access control.
Upload systems metrics and audit logs to Amazon CloudWatch.

MySQL compatibility
MySQL 5.6 / InnoDB compatible
• No application compatibility issues
reported in last 18 months
• MySQL ISV applications run pretty
much as is
• Back ported 100 fixes from
different MySQL releases
MySQL 5.7 compatibility coming
soon.
Business
Intelligence
Data Integration
Query and
Monitoring
“We ran our compatibility test suites against
Amazon Aurora and everything just worked."
- Dan Jewett, VP, Product Management at Tableau

Who is moving to Aurora and why?
Higher performance - up to 5x
Reduces cost at scale
Better availability and durability
Easy migration; no application change
1/10th of the cost; no licenses
Integration with cloud ecosystem
Comparable performance and availability
Migration tooling and services
Customers using
open source engines
Customers using
commercial engines
Customers using
NoSQL
Improved maintainability – Aurora automatically
manages hotspots
Cost reduction – pay only for used IO; eliminate
read costs for memory bound workloads

Customers
Aurora is used by:
2/3 of top 100 AWS customers
8 of top 10 gaming customers
Fastest growing service in AWS history

Security and compliance
 Amazon Aurora gives each database
instance IP firewall protection
 Aurora offers transparent encryption at rest
and SSL protection for data in transit
 Amazon VPC lets you isolate and control
network configuration and connect
securely to your IT infrastructure
 AWS Identity and Access Management
provides resource-level permission
controls

Aurora performance tenets
Do fewer IOs
Minimize network packets
Cache prior results
Offload the database engine
DO LESS WORK
Process asynchronously
Reduce latency path
Use lock-free data structures
Batch operations together
BE MORE EFFICIENT
DATABASES ARE ALL ABOUT I/O
NETWORK-ATTACHED STORAGE IS ALL ABOUT PACKETS/SECOND
HIGH-THROUGHPUT PROCESSING IS ALL ABOUT CONTEXT SWITCHES

5X more throughput than MySQL 5.6 & 5.7
WRITE PERFORMANCE READ PERFORMANCE
MySQL SysBench results
R3.8XL: 32 cores / 244 GB RAM
Five times higher throughput than stock MySQL
based on industry standard benchmarks.
0
25,000
50,000
75,000
100,000
125,000
150,000
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
Aurora MySQL 5.6 MySQL 5.7

Scaling with instance sizes
WRITE PERFORMANCE READ PERFORMANCE
Aurora scales with instance size for both read and write.

Real-life data – gaming workload
Aurora vs. RDS MySQL – r3.4XL, MAZ
Aurora 3X faster on r3.4xlarge

Real-life data - read replica latency
“In MySQL, we saw replica lag spike to almost 12 minutes which is
almost absurd from an application’s perspective. With Aurora, the
maximum read replica lag across 4 replicas never exceeded 20 ms.”

IO traffic in MySQL
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W R IT E
MYSQL WITH REPLICA
EBS mirrorEBS mirror
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
Primary
Instance
Replica
Instance
1
2
3
4
5
Issue write to Amazon EBS – EBS issues to mirror, ack when both done
Stage write to standby instance using synchronous replication
Issue write to EBS on standby instance
IO FLOW
Steps 1, 3, 4 are sequential and synchronous
This amplifies both latency and jitter
Many types of writes for each user operation
Have to write data blocks twice to avoid torn writes
OBSERVATIONS
780K transactions
7,388K I/Os per million txns (excludes mirroring, standby)
Average 7.4 I/Os per transaction
PERFORMANCE
30 minute SysBench write-only workload, 100GB dataset, RDS MultiAZ, 30K PIOPS

IO traffic in Aurora
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
AMAZON AURORA
ASYNC
4/6 QUORUM
DISTRIBUTED
WRITES
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W R IT E
IO FLOW
Only write redo log records; all steps asynchronous
No data block writes (checkpoint, cache replacement)
6X more log writes, but 9X less network traffic
Tolerant of network and storage outlier latency
OBSERVATIONS
27,378K transactions 35X MORE
950K I/Os per 1M txns (6X amplification) 7.7X LESS
PERFORMANCE
Boxcar redo log records – fully ordered by LSN
Shuffle to appropriate segments – partially ordered
Boxcar to storage nodes and issue writesReplica
Instance

IO traffic in Aurora Replicas
PAGE CACHE
UPDATE
Aurora Master
30% Read
70% Write
Aurora Replica
100% New Reads
Shared Multi-AZ Storage
MySQL Master
30% Read
70% Write
MySQL Replica
30% New Reads
70% Write
SINGLE-THREADED
BINLOG APPLY
Data Volume Data Volume
Logical: Ship SQL statements to Replica
Write workload similar on both instances
Independent storage
Can result in data drift between Master and Replica
Physical: Ship redo from Master to Replica
Replica shares storage. No writes performed
Cached pages have redo applied
Advance read view when all commits seen
MYSQL READ SCALING AMAZON AURORA READ SCALING

Asynchronous group commits
Read
Write
Commit
Read
Read
T1
Commit (T1)
Commit (T2)
Commit (T3)
LSN 10
LSN 12
LSN 22
LSN 50
LSN 30
LSN 34
LSN 41
LSN 47
LSN 20
LSN 49
Commit (T4)
Commit (T5)
Commit (T6)
Commit (T7)
Commit (T8)
LSN GROWTH
Durable LSN at head-node
COMMIT QUEUE
Pending commits in LSN order
TIME
GROUP
COMMIT
TRANSACTIONS
Read
Write
Commit
Read
Read
T1
Read
Write
Commit
Read
Read
Tn
TRADITIONAL APPROACH AMAZON AURORA
Maintain a buffer of log records to write out to disk
Issue write when buffer full or time out waiting for writes
First writer has latency penalty when write rate is low
Request I/O with first write, fill buffer till write picked up
Individual write durable when 4 of 6 storage nodes ACK
Advance DB Durable point up to earliest pending ACK

Adaptive thread pool
Re-entrant connections multiplexed to active threads
Kernel-space epoll() inserts into latch-free event queue
Dynamically size threads pool
Gracefully handles 5000+ concurrent client sessions on r3.8xl
Standard MySQL – one thread per connection
Doesn’t scale with connection count
MySQL EE – connections assigned to thread group
Requires careful stall threshold tuning
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL

Aurora lock management
Scan
Delete
Scan
Delete
Insert
Scan Scan
Insert
Delete
Scan
Insert
Insert
MySQL lock manager Aurora lock manager
Same locking semantics as MySQL
Concurrent access to lock chains
Multiple scanners allowed in an individual lock chains
Lock-free deadlock detection
Needed to support many concurrent sessions, high update throughput

Faster index build
 MySQL 5.6 leverages Linux read ahead – but
this requires consecutive block addresses in
the btree. It inserts entries top down into the
new btree, causing splits and lots of logging.
 Aurora’s scan pre-fetches blocks based on
position in tree, not block address.
 Aurora builds the leaf blocks and then the
branches of the tree.
• No splits during the build.
• Each page touched only once.
• One log record per page.
2-4X better than MySQL 5.6 or MySQL 5.7
0
2
4
6
8
10
12
r3.large on 10GB
dataset
r3.8xlarge on
10GB dataset
r3.8xlarge on
100GB dataset
Hours RDS MySQL 5.6 RDS MySQL 5.7 Aurora

Hot row contention
Scan
Delete
Scan
Delete
Insert
Scan Scan
Insert
Delete
Scan
Insert
Insert
MySQL lock manager Aurora lock manager
Highly contended workloads had high memory and CPU
• Lock compression (bitmap for hot locks)
• Replace spinlocks with blocking futex – up to 12x reduction in CPU, 3x improvement in throughput
• Use dynamic programming to release locks: from O(totalLocks * waitLocks) to O(totalLocks)
Throughput on Percona TPC-C 100 improved 29x (from 1,452 txns/min to 42,181 txns/min)

Hot row contention
MySQL 5.6 MySQL 5.7 Aurora Improvement
500 connections 6,093 25,289 73,955 2.92x
5000 connections 1,671 2,592 42,181 16.3x
Percona TPC-C – 10GB
* Numbers are in tpmC, measured using release 1.10 on an R3.8xlarge, MySQL numbers using RDS and EBS with 30K PIOPS
MySQL 5.6 MySQL 5.7 Aurora Improvement
500 connections 3,231 11,868 70,663 5.95x
5000 connections 5,575 13,005 30,221 2.32x
Percona TPC-C – 100GB

Spatial indexes in Aurora
Z-index used in Aurora
Challenges with R-Trees
Keeping it efficient while balanced
Rectangles should not overlap or cover empty space
Degenerates over time
Re-indexing is expensive
R-Tree used in MySQL 5.7
Z-index (dimensionally ordered space filling curve)
Uses regular B-Tree for storing and indexing
Removes sensitivity to resolution parameter
Adapts to granularity of actual data without user declaration
e.g. GeoWave (National Geospatial-Intelligence Agency)

Spatial Index Benchmarks
Sysbench – points and polygons
* r3.8xlarge using Sysbench on <1GB dataset
* Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS
0
20000
40000
60000
80000
100000
120000
140000
Select-only (reads/sec) Write-only (writes/sec)
Aurora
MySQL 5.7

High-performance auditing
MariaDB server_audit plugin Aurora native audit support
We can sustain over 500K events/sec
Create event string
DDL
DML
Query
DCL
Connect
DDL
DML
Query
DCL
Connect
Write
to File
Create event string
Create event string
Create event string
Create event string
Create event string
Latch-free
queue
Write to File
Write to File
Write to File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance

Fast DDL: Aurora vs. MySQL
 Full Table copy; rebuilds all indexes – can take
hours to complete.
 Needs temporary space for DML operations; table
lock for DML changes.
 DDL operation impacts DML throughput.
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
 Add entry to metadata table - use schema versioning
to decode the block.
 Modify-on-write to upgrade the block to latest schema
when it is modified.
MySQL Amazon Aurora
Support NULLable column at the end; other add column, drop/reorder,
modify data types

Fast DDL performance
DDL performance on
r3.large
DDL performance on
r3.8xlarge
10GB table 0.27 sec 3,960 sec 1,600 sec
10GB table 0.06 sec 900 sec 1,080 sec

6-way replicated storage
Survives catastrophic failures
Six copies across three Availability Zones
4 out 6 write quorum; 3 out of 6 read quorum
Peer-to-peer replication for repairs
Volume striped across hundreds of storage nodes
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availabilityRead availability

Storage Durability
Storage volume automatically grows up to 64 TB
Quorum system for read/write; latency tolerant
Peer to peer gossip replication to fill in holes
Continuous backup to S3 (built for 11 9s durability)
Continuous monitoring of nodes and disks for repair
10GB segments as unit of repair or hotspot rebalance
Quorum membership changes do not stall writes
AZ 1 AZ 2 AZ 3
Amazon S3

Continuous backup and point-in-time recovery
Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
• Take periodic snapshot of each segment in parallel; stream the redo logs to Amazon S3
• Backup happens continuously without performance or availability impact
• At restore, retrieve the appropriate segment snapshots and log streams to storage nodes
• Apply log streams to segment snapshots in parallel and asynchronously

Instant Crash Recovery
Traditional Databases
Have to replay logs since the last
checkpoint
Typically 5 minutes between checkpoints
Single-threaded in MySQL; requires a
large number of disk accesses
Amazon Aurora
Underlying storage replays redo records
on demand as part of a disk read
Parallel, distributed, asynchronous
No replay for startup
Checkpointed Data Redo Log
Crash at T0 requires
a re-application of the
SQL in the redo log since
last checkpoint
T0 T0
Crash at T0 will result in redo logs being
applied to each segment on demand, in
parallel, asynchronously

Survivable Caches
We moved the cache out of the
database process
Cache remains warm in the event of
database restart
Lets you resume fully loaded
operations much faster
Instant crash recovery + survivable
cache = quick and easy recovery from
DB failures
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
Caching process is outside the DB process
and remains warm across a database restart

Database failover time
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0 - 5s – 30% of fail-overs
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
40.00%
45.00%
50.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0%
10%
20%
30%
40%
50%
60%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0%
5%
10%
15%
20%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35

Faster failover
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MYSQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
AURORA WITH MARIADB DRIVER
5 - 6 s e c
3 - 1 5 s e c
5 - 6 s e c

Up to 15 promotable read replicas
Master Read
Replica
Read
Replica
Read
Replica
Shared distributed storage volume
Reader end-point
 Up to 15 promotable read replicas across multiple Availability Zones
 Re-do log based replication leads to low replica lag – typically < 10ms
 Reader end-point with load balancing; customer specifiable failover order
Writer end-
point

Cross-region read replicas
• MySQL binlog-based disaster
recovery and enhanced data
locality.
• Promote read-replica to a master
for faster recovery in the event of
disaster
• Bring data close to your
customer’s applications in
different regions
• Promote to a master for easy
migration

Zero downtime patching
Networking
state
Application
state
Storage Service
App
state
Net
state
App
state
Net
state
BeforeZDP
New DB
Engine
Old DB
Engine
New DB
Engine
Old DB
Engine
WithZDP
User sessions terminate
during patching
User sessions remain
active through patching
Storage Service

Database cloning
Create a copy of a database without
duplicate storage costs
• Creation of a clone is nearly
instantaneous – we don’t copy data
• Data copy happens only on write – when
original and cloned volume data differ
Typical use cases:
• Clone a production DB to run tests
• Reorganize a database
• Save a point in time snapshot for analysis
without impacting production system.
Production database
Clone Clone
Clone
Dev/test
applications
Benchmarks
Production
applications
Production
applications

Recent announcements (2017)
Manageability
Advanced auditing; Cross-account encrypted snapshot sharing; Encryption support for
cross-region replication; Database cloning; Encrypted migration from RDS MySQL to Aurora
Performance enhancements
Fast DDL for end of table ADD COLUMN operations
Cost reduction
T2.small – cuts cost of entry by half – run Aurora for $1 / day
Ecosystem integration
IAM for Aurora access management; SELECT INTO S3 (LOAD FROM already supported);
Aurora audit activity monitoring with CloudWatch
Growing footprint
Launched in US West (N. California) and EU (Frankfurt) – now available in all 3-AZ regions

Amazon Web Services
Thank you!
Reach out to
abrsteve@amazon.com
for questions

What’s New in Amazon Aurora

More Related Content

What’s New in Amazon Aurora