Replication for Availability & Durability with MySQL and Amazon RDS Grant McAlister

Overview Why replicate? What are the options? What are the issues? What do we do.

Why Replicate? Durability Availability Scaling

Durability Replicate Location 1Location 2

Availability When disaster or failure happens  Read 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 replica  Failover to it  Requires Logical Replication

Read Scaling Master Replica1 R/W Client R/W Client R/W Client R/W Client Read Client Read Client Replica2 Replica3 Read Client Read Client Read Client Read Client Read Client Read Client

Replication Options Logical vs. Physical Synchronous vs. Asynchronous

Logical vs. Physical Logical  Standard MySQL Replication  Logical statement or transaction is shipped  Non-deterministic? (Statement vs. Mixed vs. Row) Physical  Shipping the physical block changes Oracle Dataguard Filesystem or block layer replication Physical SAN device replication  Deterministic (physically exactly the same)

Primary Logical Replication Buffer Data insert into person values(‘grant’); 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

Synchronous vs. Asynchronous Replication Synchronous Replication  Write is not committed until it is written on both replicas  Guarantees high durability (almost no data loss)  Higher transaction latency  Pay penalty now (maybe) Asynchronous Replication  Acknowledged 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’); Primary Secondary commit; Replication Log Relay Log grant ACK DURABLE in ONE LOCATION DURABLE in TWO LOCATION

Synchronous insert into person values (‘grant’); Primary Secondary commit; Replication Log Relay Log grant ACK DURABLE in TWO LOCATION

Performance Max Apply Rate

Read Scaling Challenges Eventual Consistency Read to Write Ratio

Eventual Consistency = Replication Lag PrimaryReplica Writer Reader

Large Commit = Replication Delay 500,000 rows 100,000 rows

Reasons for Replication Lag Large transactions Single apply thread on replica Network problems Overloaded replica DON’T ASSUME THE BEST CASE

Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Writes10% Reads10% Reads 90% Reads 90% Writes10% Read to Write Ratio Primary Writes10% Replica1 Writes10% Replica2 Writes10% Replica3 Writes10% Replica4 1X2X3XSCALE

Writes 20% Reads 80% Reads 80% Reads 20% Writes 20% Reads 20% Writes 20% Reads 20% Writes 20% Reads 20% Writes 20% Read to Write Ratio - More Writes PrimaryReplica1Replica2Replica3Replica4 1X2XSCALE

What is RDS MySQL Managed Relational Database Service (RDS)  Automated Backups and Point in Time Recovery  Can Scale CPU & Memory up and down  Online storage scaling  User controlled patching  Multi-AZ replication  Read Replicas

RDS MySQL - Replication Multi-AZ  Synchronous Replication  Across Availability Zones (AZ) for increased durability  Standby is not usable for reads  Automated rebuilding of failed replica Read Replica  Standard Asynchronous MySQL replication  Readable by default but also writeable  Can have multiple per master

Highly Available, Durable, & Scalable MySQL Deployments Multi-AZ Deployments Read Replicas

Demo of RDS Multi-AZ failover

THANK YOU