View
0
Download
0
Category
Preview:
Citation preview
High Availability Database Architecture
Ray Bradford, Principal Product Manager
Overview
General High Availability (HA) Database Principles
HA Database Options on AWS
Amazon Relational Database Service
Architecting for Availability and Durability
Logical Corruption
Compute Node Failure
Storage Failure
Network Disruption
Data Center or Availability Zone Disruption
Database Maintenance (Scaling, Patching)
Technologies for HA - Backups
Logical corruption
Restore operations after storage volume or AZ disruption
Technologies for HA - Replication
Faster than reboot in case of failure
Don’t Forget: Multi-AZ architecture
X Availability
Zone Availability
Zone
Don’t Forget: Backups still have value
Advanced: replication/failover for maintenance
Make changes to replica, failover to it
Practice
Tale of Two Companies
Single-AZ
Nightly Backup Only
Multi-AZ
Backups from Standby
Maintenance on Standby
Online DDL on Replica
Company A Company B
Replication Options
Synchronous vs. Asynchronous
Logical vs. Physical
Asynchronous vs. Synchronous Replication
Asynchronous Replication
Acknowledged as soon as written to the local storage
Lower durability than synchronous
Can fall behind on shipping
Synchronous Replication
Write is not committed until it is written on both replicas
Highest durability
Higher transaction latency
Asynchronous
insert into person values (‘ray’);
Primary Secondary
commit;
Replication Log Relay Log
ray
ACK ACK
DURABLE in ONE LOCATION DURABLE in TWO LOCATION
Synchronous
insert into person values (‘ray’);
Primary Secondary
commit;
Replication Log Relay Log
ray
ACK ACK DURABLE in TWO LOCATION
Logical vs. Physical
Logical
Standard MySQL Replication
Logical statement or transaction is shipped
With MySQL, enables operations on standby (reads, DDL)
Physical
Shipping the physical block changes
• Oracle Dataguard
• Filesystem or block layer replication
• Physical SAN device replication
May not allow operations on standby
Primary
Logical Replication
Buffer
Data
insert into person values(‘ray’);
commit;
Parse
Recovery
Log
Replication
Log
Replica
Buffer
Data
Parse
Recovery
Log
Replication
Log
Relay Log
Single
Threaded
Primary
Physical Replication
Buffer
Data
insert into person values(‘grant’);
commit;
Parse
Recovery
Log
Replication
Log
Replica
Buffer
Data
Parse
Recovery
Log
Replication
Log
Relay Log
Popular Database Engines on EC2
Native, asynchronous
(Semi)-synchronous
Data Guard, RMAN, Oracle Secure Backup Cloud Module
Oracle Database Machine Image (AMI)
Log shipping and DB mirroring
What is Amazon RDS
Managed Relational Database Service
Goals
Make it easy to set up, operate, and scale relational databases in the cloud.
Maintain compatibility with applications and tools.
Supported Engines
MySQL, Oracle
Amazon RDS Features
Pre-configured deployments in minutes with console
DB Instance type scaling (cpu, memory)
Online storage scaling
Amazon CloudWatch integration
Automatic software patching with user control
Backups
Replication
Amazon RDS Backups
Automated Backups
Nightly system snapshots + transaction backup
Enables point-in-time restore to any point in retention period, up to the last 5 minutes
Max retention period = 8 days
DB Snapshots
User-driven snapshots of database
Kept until explicitly deleted
Multi-AZ Deployments for Amazon RDS
Managed fault-tolerance solution for production databases
What is a Multi-AZ deployment?
Amazon RDS creates and maintains a hot standby in a different Availability Zone
In the event of an unplanned or planned outage, Amazon RDS automatically fails over to the standby
MySQL DB Instance
Things to know about Multi-AZ
Replication Type
Synchronous - designed for high data durability
Physical - standby cannot be accessed directly
What events result in automatic failover?
Unplanned (instance failure, storage volume failure)
Planned (instance scaling, patching)
1-2 minute average failover time
Highly Available, Durable, & Scalable MySQL Deployments
Multi-AZ Deployments Read Replicas
THANK YOU
Recommended