AWS BD Summit 2011

Replication for Availability & Durability with MySQL and Amazon RDS

Grant McAlister

OverviewWhy replicate?What are the options?What are the issues?What do we do.Why Replicate?DurabilityAvailabilityScalingDurability

Replicate

Location 1Location 2AvailabilityWhen disaster or failure happensRead availability from readable replicas Read/Write availability by promoting a replica

Can be faster than waiting for a reboot

Online DDL operations (create index, alter table)Make changes on a replicaFailover to itRequires Logical ReplicationRead ScalingMasterReplica1R/WClientR/WClientReadClientReplica2Replica3ReadClientReadClientReadClientReplication OptionsLogical vs. PhysicalSynchronous vs. AsynchronousLogical vs. PhysicalLogicalStandard MySQL ReplicationLogical statement or transaction is shippedNon-deterministic? (Statement vs. Mixed vs. Row)

PhysicalShipping the physical block changesOracle DataguardFilesystem or block layer replicationPhysical SAN device replicationDeterministic (physically exactly the same)

PrimaryLogical ReplicationBufferDatainsert into person values(grant); commit;ParseRecovery LogReplication LogReplicaBufferDataParseRecovery LogReplication LogRelay LogSingle ThreadedPrimaryPhysical ReplicationBufferDatainsert into person values(grant); commit;ParseRecovery LogReplication LogReplicaBufferDataParseRecovery LogReplication LogRelay LogSynchronous vs. Asynchronous ReplicationSynchronous ReplicationWrite is not committed until it is written on both replicasGuarantees high durability (almost no data loss)Higher transaction latencyPay penalty now (maybe)

Asynchronous ReplicationAcknowledged as soon as written to the local storage Some level of durability (possible data loss)Can be far behind on shipping

About LOG SHIPPING NOT APPLY

Asynchronous insert into person values (grant); PrimarySecondarycommit;Replication LogRelay LoggrantACKACKDURABLE in ONE LOCATIONDURABLE in TWO LOCATIONSynchronous insert into person values (grant); PrimarySecondarycommit;Replication LogRelay LoggrantACKACKDURABLE in TWO LOCATIONPerformanceMax Apply Rate-MySQL 5.5 -0.4 millisecond latency between master and replica15Read Scaling ChallengesEventual ConsistencyRead to Write RatioEventual Consistency = Replication Lag PrimaryReplicaWriterReaderLarge Commit = Replication Delay500,000 rows100,000 rowsReasons for Replication LagLarge transactionsSingle apply thread on replicaNetwork problemsOverloaded replica

DONT ASSUME THE BEST CASEReads10%Reads10%Reads10%Reads10%Reads10%Reads10%Reads10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Reads10%Writes10%Reads10%Writes10%Reads10%Reads90%Writes10%Read to Write RatioPrimaryWrites10%Replica1Writes10%Replica2Writes10%Replica3Writes10%Replica41X2X3XSCALEWrites 20%Writes 20%Writes 20%Writes 20%Reads80%Reads 20%Reads 20%Reads 20%Reads 20%Reads 20%Writes 20%Reads 20%Writes 20%Reads 20%Writes 20%Reads 20%Writes 20%Writes 20%Writes20%Read to Write Ratio - More WritesPrimaryReplica1Replica2Replica3Replica41X2XSCALEWhat is RDS MySQLManaged Relational Database Service (RDS)Automated Backups and Point in Time RecoveryCan Scale CPU & Memory up and downOnline storage scalingUser controlled patchingMulti-AZ replicationRead Replicas

RDS MySQL - ReplicationMulti-AZSynchronous ReplicationAcross Availability Zones (AZ) for increased durabilityStandby is not usable for readsAutomated rebuilding of failed replica

Read ReplicaStandard Asynchronous MySQL replicationReadable by default but also writeableCan have multiple per masterHighly Available, Durable, & Scalable MySQL Deployments

Multi-AZ DeploymentsRead Replicas25Demo of RDS Multi-AZ failoverTHANK YOU