MySQL Replication: Pros and Cons

Size: px

Start display at page:

Download "MySQL Replication: Pros and Cons"

Peter Gaines
6 years ago
Views:

1 MySQL Replication: Pros and Cons Achieve Higher Performance, Uptime, Reliability and Simplicity for Real-World Use Cases. Darpan VP of Engineering Schooner Information Technology

2 Agenda Quick tour of MySQL asynchronous, semi-synchronous and synchronous replication schemes 20 real-world use cases: which replication mechanisms to choose and why SchoonerSQL Q&A p Schooner Schooner Information Information Technology, Technology. p2 All rights reserved.

3 20 Real- World Use Cases High write rate Read scaling Use of Flash memory High Availability Server sprawl, inefficient HW util. Full and incremental backup WAN, multi-dc deployments Online schema updates Online maintenance & upgrades Minimize administration MySQL Master-Master DRBD Resilience Point-in-time recovery (PITR) Delayed Slave Very large databases Automated replication failover Mixed hardware Virtualized or Cloud env. Elasticity requirements p Schooner Schooner Information Information Technology, Technology. p3 All rights reserved.

Part One Concepts that effect MySQL replication Parallelism Flow control Consistency & Serializability Quick tour of replication schemes for

4 Part One Concepts that effect MySQL replication Parallelism Flow control Consistency & Serializability Quick tour of replication schemes for MySQL Asynchronous Semi-synchronous Synchronous p Schooner Schooner Information Information Technology, Technology. p4 All rights reserved.

Parallelism, or the Lack of Commodity hardware: 4-10 core processors MySQL Slave uses <1

Hard-disks have >5ms latency (random) Single threaded Slave cannot make >200 random

Flash memory offers >50k IOPS Add Flash memory to improve performance of a single thread

5 Parallelism, or the Lack of Commodity hardware: 4-10 core processors MySQL Slave uses <1 core to apply replication Can MySQL Master sustain write transactions using >1 core? Hard-disks have >5ms latency (random) Single threaded Slave cannot make >200 random reads/sec in foreground Can a MySQL Slave use more disk throughput? Flash memory offers >50k IOPS Add Flash memory to improve performance of a single thread At what price/performance? p Schooner Schooner Information Information Technology, Technology. p5 All rights reserved.

6 Answer to Parallelism: SchoonerSQL commit/1800s 6,000,000 5,000,000 4,000,000 3,000,000 2,000,000 1,000,000 Slave commits on Sysbench 0 1,693,476 Percona ,326,066 Schooner ASYNC 5,080,958 1,782,231 Schooner SYNC Stock X throughput on SchoonerSQL Slaves Commit/ 3900 sec 12,000,000 10,000,000 Commits / sec 8,000,000 6,000,000 4,000,000 2,000,000 0 Slave commits on DBT2 3,235,410 3,239,277 11,174,862 9,456,770 Percona Stock Schooner SYNC Schooner ASYNC TPCC- mysql 5000W Master Slave 0 Schooner Async Percona Async p Schooner Schooner Information Information Technology, Technology. p6 All rights reserved.

Flow Control p7 2012 2011 Schooner Schooner Information

8 Flow Control in ReplicaSon No flow control Slave lags the Master Stale reads on Slave Failover onto Slave is tricky Action: make Slave faster (add Flash, more memory) Action: shard database without hitting H/W limits Action: use SchoonerSQL parallel async replication & reduce slave-lag With flow control Slave is in lock-step with Master Reads are near or fully consistent Failover is low or no risk Slave may throttle Master Action: use SchoonerSQL parallel sync replication to eliminate data-loss and slave-lag Action: use similar H/W within a cluster p Schooner Schooner Information Information Technology, Technology. p8 All rights reserved.

9 Serializability and Consistency Serializability: a transaction schedule is serializable if its outcome (e.g., the resulting database state) is equal to the outcome of its transactions executed serially, i.e., sequentially without overlapping in time. MySQL Slave is single threaded, i.e. executes and commits in a serial order, hence serializable. SchoonerSQL Slave (async/semi-sync*/sync) Checks for conflicts Executes in parallel Commits transactions in the same order as the Master Strong consistency, 100% compatibility, Binlog in identical sequence p Schooner Schooner Information Information Technology, Technology. p9 All rights reserved.

10 Things to Watch Out for in Parallel ReplicaSon ImplementaSons TransacSon Ordering (1/2): Master (TransacSons on Master) T2 T5 T3 T1 T4 T1 T3 T2 Commit order T1 T2 T3 T4 T5 (In InnoDB and binary log) p Schooner 2011 Schooner Information Information Technology, Technology. p10 All rights reserved.

T2 T1 T1 T3 T2 Commit order T5 T4 T3 T2 T1 (In InnoDB and binary log) p11 2012 2011

11 Things to Watch Out for in Parallel ReplicaSon ImplementaSons TransacSon Ordering (2/2): Slave or 2 nd Master (order in relay log or sync replicason buffers) T5 T4 T3 T2 T1 T1 T3 T2 Commit order T5 T4 T3 T2 T1 (In InnoDB and binary log) p Schooner Schooner Information Information Technology, Technology. p11 All rights reserved.

12 MySQL ReplicaSon Technology 1. Asynchronous Oldest, most popular and widely deployed 2. Semi-synchronous Introduced in v5.5. Objective: avoid many data-loss situations 3. Synchronous ( Virtual Synchrony, not 2PC) Not available from Oracle/ MySQL SchoonerSQL: >1 year in production XtraDB Cluster: announced last week p Schooner 2011 Schooner Information Information Technology, Technology. p12 All rights reserved.

apply(51) tx=101 tx=101 tx=51 tx=51 DB InnoDB Tx log MySQL Bin log Log events pulled by Slave Relay log InnoDB Tx log DB Last tx=100 Last tx=100 Loosely coupled master/slave relationship Master does

13 #1 MySQL Asynchronous ReplicaSon Master mysqld Tx.Commit(101) Read Stale data on Slave No flow control CorrupPon Master failure = mess Data loss Single- threaded Slave Read version based on tx=50 Slave mysqld Repl.apply(51) tx=101 tx=101 tx=51 tx=51 DB InnoDB Tx log MySQL Bin log Log events pulled by Slave Relay log InnoDB Tx log DB Last tx=100 Last tx=100 Loosely coupled master/slave relationship Master does not wait for Slave Slave determines how much to read and from which point in the binary log Slave can be arbitrarily behind master in reading and applying changes p Schooner 2011 Schooner Information Information Technology, Technology. p13 All rights reserved. Last tx=70 Last tx=50 Read on slave can give old data No checksums in binary or relay log stored on disk, data corruption possible Upon a Master s failure Slave may not have latest committed data resulting in data loss Fail-over to a slave is stalled until all transactions in relay log have been committed not instantaneous

for tx=100 pulled by Slave Slave ACK for tx=100 Read version based on tx=50 Repl.

14 #2 MySQL Semi- synchronous ReplicaSon DB Master mysqld Tx.Commit(101) InnoDB Tx log MySQL Bin log Read Stale data on Slave No flow control CorrupPon Master failure = mess Data loss Single threaded Slave Relay log Slave mysqld tx=101 tx=101 tx=51 tx=51 Log for tx=100 pulled by Slave Slave ACK for tx=100 Read version based on tx=50 Repl.apply(51) InnoDB Tx log DB Last tx=100 Last tx=100 Semi-coupled master/slave relationship On commit, Master waits for an ACK from Slave Slave logs the transaction event in relay log and ACKs (may not apply yet) Slave can be arbitrarily behind master in applying changes Last tx=100 Last tx=50 Read on slave can give old data No checksums in binary or relay log stored on disk, data corruption possible Upon a Master s failure Fail-over to a slave is stalled until all transactions in relay log have been committed not instantaneous p Schooner 2011 Schooner Information Information Technology, Technology. p14 All rights reserved.

#3 SchoonerSQL Synchronous ReplicaSon Read version based on tx=100 DB Master mysqld Tx.

Slave No flow control CorrupPon Master failure = mess Data loss Single threaded Slave Slave mysqld Repl.

commit the change Slave in lock-step with Master p15 2012 Schooner 2011 Schooner Information Information Technology, Technology.

15 #3 SchoonerSQL Synchronous ReplicaSon Read version based on tx=100 DB Master mysqld Tx.Commit(101) tx=101 InnoDB Tx log MySQL Bin log Last tx=100 Last tx=100 Log for tx=100 pushed to Slave Slave ACK for tx=100 Read Stale data on Slave No flow control CorrupPon Master failure = mess Data loss Single threaded Slave Slave mysqld Repl.apply(100) tx=100 InnoDB Tx log Last tx=100 DB Tightly-coupled master/slave relationship After commit, all Slaves guaranteed to receive and commit the change Slave in lock-step with Master p Schooner 2011 Schooner Information Information Technology, Technology. p15 All rights reserved. Read on slave gives latest committed data Checksums in replication paths Upon a Master s failure Fail-over to a slave is fully integrated and automatic Application writes continue on new master instantaneously No data loss

16 QualitaSve Comparison MySQL 5.5 Asynchronous SchoonerSQL Asynchronous MySQL 5.5 Semi- Synchronous SchoonerSQL Semi- Synchronous* XtraDB Cluster Synchronous SchoonerSQL Synchronous Parallel replicason (for same schema) N Y N Y Y Y Throughput Medium High Medium High Medium High High network latency tolerant Y Y N N N N MulS- level failure detecson N Y N Y N Y Global transacpon IDs N Y N Y N Y Capacity with transient failures Y Y Y Y N Y Commit consistency Y Y Y Y N Y Auto recovery with high consistency Medium High Medium High Medium High Auto replicason failover and repair N Y N Y Y Y Large update/ insert/ LOAD INFILE Y Y Y Y N Y Unexpected aborts & deadlocks N N N N Y N MulS- Master Cluster N N N N Y N * Future release p Schooner 2011 Schooner Information Information Technology, Technology. p16 All rights reserved.

p17 2012 Schooner 2011 Schooner Information

18 #1 High Write Rate Async/ semi-sync Issue: Slave lags the Master Issue: Master hits limits (code + H/W) Typical solutions Use more main-memory and/or Flash memory Shard database SchoonerSQL SchoonerSQL is optimized for multi-cores, Flash memory and fast network Master scales vertically with H/W resource (CPU, memory, storage). Async and sync Slave have parallel threads for replication that match the speed of the Master. p Schooner 2011 Schooner Information Information Technology, Technology. p18 All rights reserved.

19 #2 Read Scaling Async/ semi-sync/ sync Issue: Scale read queries for a read intensive application Sysbench Read/Write Reads/s Writes/s Typical solution MySQL replication allows unlimited number of Slaves Nodes in Schooner Cluster SchoonerSQL Schooner sync supports consistent reads from up to 7 Slaves Schooner async allows same unlimited number of Slaves p Schooner 2011 Schooner Information Information Technology, Technology. p19 All rights reserved.

20 #3 Use of Flash Memory Async/ semi-sync/ sync Issue: MySQL/InnoDB is IO latency sensitive, adding dozens of hard disks does not scale well Issue: Slave is unable to keep-up with Master Issue: InnoDB flushing & check-pointing has unstable performance Typical solutions Use Flash to provide more IOPS to single threaded Slave Use Flash for faster random access to read and write database files SchoonerSQL SchoonerSQL is designed for fast storage (such as Flash memory) to reduce writes, increase flushing and checkpoint efficiencies, executing more read and write IOs in parallel. Slave parallelism and vertical scalability helps avoid sharding and provides factors of better price/performance, order of magnitude when compared with disks p Schooner 2011 Schooner Information Information Technology, Technology. p20 All rights reserved.

21 #4 High Availability (HA) Async/ semi-sync Issue: MySQL provides weak out-of-the-box availability Issue: Replication and application connections are not failed over Sync Issue: Requires failover of application connections Typical solutions Use a proxy Use Virtual IPs (MMM) SchoonerSQL for mission-critical applications Includes integrated VIP management and automatic failover Global transaction IDs in binary log allow sync, semi-sync* and async replication connections to be automatically repaired/ redirected p Schooner 2011 Schooner Information Information Technology, Technology. p21 All rights reserved.

#4 High Availability (HA): SchoonerSQL Availability Base Sync replicason (LAN) Auto client connecson failover Sync node failures (up to 7) Auto sync connecson repair Fault tolerance (sync - > async

22 #4 High Availability (HA): SchoonerSQL Availability Base Sync replicason (LAN) Auto client connecson failover Sync node failures (up to 7) Auto sync connecson repair Fault tolerance (sync - > async - > sync) Async WAN connecson repair WAN level failover Two Ser failure detecson Self healing p Schooner 2011 Schooner Information Information Technology, Technology. p22 All rights reserved.

23 #5 Server Sprawl, Inefficient Hardware USlizaSon Async/ semi-sync/ sync Issue: Software bottlenecks force premature sharding Issue: Servicing reads or taking backup Slave commits on Sysbench on Slave conflicts with single 6,000,000 5,326,066 threaded Slave 5,080,958 Issue: DRBD stand-by servers Typical solutions Use a Slave solely for backups Add Slave servers commit/1800s 5,000,000 4,000,000 3,000,000 2,000,000 1,000,000 1,693,476 1,782,231 SchoonerSQL Provides high consolidation via high vertical scalability and 2-10X faster Slave replication 0 Percona Schooner ASYNC Schooner SYNC Stock p Schooner 2011 Schooner Information Information Technology, Technology. p23 All rights reserved.

24 #5 Server Sprawl, Inefficient Hardware USlizaSon SchoonerSQL VerScal Scalability UPlizaPon (CPU threads) CPU Scalability Total concurrent connecpons SchoonerSQL scales on mul9- cores & Flash IOPS Bandwidth (MBps) IO Scalability Total concurrent connecpons Network Scalability Read IOPS Write IOPS Network in Network out Benchmark: 5000 warehouse TPCC- MySQL p Schooner 2011 Schooner Information Information Technology, Technology. p24 All rights reserved Total concurrent connecpons

25 #6 Full and Incremental Backup Async/ semi-sync Issue: Slave instance may lag due to backup Sync Issue: Flow control may be triggered slowing down the commits Typical solutions Reserve a slave solely for backup (non-sync mode) Schedule or execute backup during periods with low write activity Throttle down backup speed (increasing the time taken to backup) Separate storage device and controller for backup target SchoonerSQL Slave parallelism reduces or eliminates these issues Schooner backup includes adaptive throttling to reduce contention p Schooner 2011 Schooner Information Information Technology, Technology. p25 All rights reserved.

26 #7 WAN and MulS- Data Center Deployments Semi-sync/ Sync Issue: Increases in network latency slow down commits Issue: Failure detection over higher latency networks is slow Typical solutions Use semi-sync or async within DC (or with metro-area networks) Use async for high latency networks (WAN) SchoonerSQL Use sync and/or async within DC (or with metro-area networks) Use async for WAN (automatic failover supported) High throughput maintained across WAN, as permitted by network bandwidth & quality p Schooner 2011 Schooner Information Information Technology, Technology. p26 All rights reserved.

27 #7 WAN and MulS- Data Center Deployments: SchoonerSQL Synchronous Cluster WRITES Synchronous Cluster Read Master REPL REPL REPL MASTER WRITES Parallel Async REPL MASTER REPL REPL Read Master Read Master Read Master Data Center #1 Read Master Data Center #2 Read Master p Schooner 2011 Schooner Information Information Technology, Technology. p27 All rights reserved.

28 #7 WAN and MulS- Data Center Deployments: SchoonerSQL SchoonerSQL asynchronous replication performance p Schooner 2011 Schooner Information Information Technology, Technology. p28 All rights reserved.

29 #8 Online Schema Updates Async/ semi-sync/ sync Issue: Certain schema changes take minutes-hours and lock table for the duration (blocking write transactions that write to this table) Issue: Adding index has similar effects Sync Issue: Requires extra machinery if async is not supported Typical solutions Use Flash memory for small-medium tables Leverage one of several solutions (open-ark, pt-online-schema..) SchoonerSQL Supports asynchronous and synchronous for an instance. Fully compatible with existing mechanisms to update schema. p Schooner 2011 Schooner Information Information Technology, Technology. p29 All rights reserved.

30 #9 Online Maintenance and Upgrades Async/ semi-sync/ sync Issue: Application failover is required before taking a MySQL instance offline Sync Issue: To service load during maintenance, a temporary server may need to be used and require sufficient manual work Typical solutions Use scripts, manual steps SchoonerSQL GUI and CLI includes features to migrate an instance to another server and moving application connections. SchoonerSQL supports automated full and incremental database provisioning and recovery. Automation reduces errors. p Schooner 2011 Schooner Information Information Technology, Technology. p30 All rights reserved.

31 #10 Minimize AdministraSon Async/ semi-sync/ sync Issue: MySQL requires considerable configuration and administration for replication, failure-detection, failover, backup/restore Typical solutions Add MySQL experienced members on the dev/ops team SchoonerSQL Auto provisioning of a Peer/ Slave Mark a sync instance as Master Auto-sync after an instance is restarted Schedule full & incremental backups Alerts for notification State and progress of startup and shutdown p Schooner 2011 Schooner Information Information Technology, Technology. p31 All rights reserved.

#10 Minimize AdministraSon SchoonerSQL: GUI for Management Integrated GUI simplifies administration Powerful 1-click actions for On-line provisioning of

instances Easy Server Management Assign VIPs to Masters, Read Masters and Asynchronous Masters and Slaves Create Synchronous and Asynchronous groups or

32 #10 Minimize AdministraSon SchoonerSQL: GUI for Management Integrated GUI simplifies administration Powerful 1-click actions for On-line provisioning of servers and MySQL instances On-line database migration, upgrades Master role is set on an instance with a click Create / Start / Stop / Remove MySQL instances Easy Server Management Assign VIPs to Masters, Read Masters and Asynchronous Masters and Slaves Create Synchronous and Asynchronous groups or clusters Change the configuration parameters through GUI p Schooner 2011 Schooner Information Information Technology, Technology. p32 All rights reserved.

Bytes In & Out kb/s Integrated full & incremental online backup Scheduled backup ( daily, monthly) Supports full database restore

33 #10 Minimize AdministraSon SchoonerSQL: Monitoring & Backup Schedules Monitoring and optimization: Extensive displays with resource utilization statistics Physical (cores, storage, network) and logical (buffers, locks, ) CPU, Disk, RAM usage IO Read and Write kb/s Bytes In & Out kb/s Integrated full & incremental online backup Scheduled backup ( daily, monthly) Supports full database restore Adaptive backup that minimizes effect on database p Schooner 2011 Schooner Information Information Technology, Technology. p33 All rights reserved.

#10 Minimize AdministraSon SchoonerSQL: Alerts SchoonerSQL provides email based alerts that are very useful in monitoring the database environment.

34 #10 Minimize AdministraSon SchoonerSQL: Alerts SchoonerSQL provides based alerts that are very useful in monitoring the database environment. Alerts include name, date & time, severity, description and have configurable thresholds. Sample alerts Instance created/deleted Instance up/down Instance attached/detached Group created/removed Async failover VIP configuration p Schooner 2011 Schooner Information Information Technology, Technology. p34 All rights reserved.

35 #11 MySQL Master- Master Setup (AcSve/Passive) Async/ semi-sync Issue: Require quick failover upon active Master s failure Async Issue: May loose transactions upon active Master s failure Typical solutions Configure two MySQL instances as Master-Master (setup to replicate to and from each other) Use external failure-detection and load (re-) direction mechanisms (e.g. MMM, Flipper, HAProxy) SchoonerSQL SchoonerSQL sync cluster setup is similar to an active-passive Master-Master setup. Automatic failure detection and application failover is integrated in the solution. p Schooner 2011 Schooner Information Information Technology, Technology. p35 All rights reserved.

Master Read Master SchoonerSQL Read Master Read Master SchoonerSQL Instantaneous Failover p36

36 #11 MySQL Master- Master Setup (AcSve/Passive) Synchronous Cluster WRITES Synchronous Cluster WRITES WRITES Read Master REPL REPL REPL MASTER Read Master REPL REPL WRITES MASTER Read Master Read Master SchoonerSQL Read Master Read Master SchoonerSQL Instantaneous Failover p Schooner 2011 Schooner Information Information Technology, Technology. p36 All rights reserved.

37 #12 MySQL with DRBD Setup Async Issue: Possibility of data loss when active Master fails & immediate failover is required Issue: Reconnecting Slaves to new Master is not straightforward Typical solutions Use semi-sync replication in v5.5 Use DRBD to replicate at physical storage block device level SchoonerSQL Instead of wasting resources on a stand-by and long failover time (recovery and warm-up), SchoonerSQL sync cluster provides logical replication (avoiding corruption propagation in DRBD) with no data loss, instantaneous failover and automatic failover of replication connections (sync or async). p Schooner 2011 Schooner Information Information Technology, Technology. p37 All rights reserved.

38 #13 Resilience Sync Issue: Sensitive to N/W quality, splits cluster at any fault Issue: Read capacity compromised Typical solutions Semi-sync falls back to async mode Async Slaves disconnect without affecting the Master, and reconnect at a later time SchoonerSQL Sync falls back to async* without affecting the Master or compromising the read capacity * As of SchoonerSQL p Schooner 2011 Schooner Information Information Technology, Technology. p38 All rights reserved.

39 #14 Point In Time Recovery (PITR) Sync Issue: Binary logs within a cluster may not contain transactions in the same sequence. PITR becomes difficult if the same instance that created backup files is unavailable. Typical solutions Backup database and binary log for all or majority of cluster instances (increases disk space requirements and may cause slow down during backup) SchoonerSQL SchoonerSQL Slave instances using any replication type commit in the same order as Master, even when parallelizing writes. Global transaction IDs help stitch state of any cluster member. Backup from one instance of a cluster is sufficient. p Schooner 2011 Schooner Information Information Technology, Technology. p39 All rights reserved.

40 #15 Delayed Slave Sync Issue: Instances in the cluster are in lock-step with Master and do not read binary log (as an async Slave does) SchoonerSQL SchoonerSQL supports multiple replication types in the same database cluster. An async Slave instance can be used for this purpose. p Schooner 2011 Schooner Information Information Technology, Technology. p40 All rights reserved.

41 #16 Very Large Databases Async/ semi-sync Issue: Working set may be larger than main-memory -> slow Slave replication Issue: Large databases take longer to backup Commits / sec TPCC- mysql 0.5 TB Master Slave Typical solution 500 Throttle backup and control database size Use snapshots for backup 0 Schooner Async Percona Async SchoonerSQL Adaptive backup helps with file copy based backup Parallel Slave replication helps to hide high rate of reads Gains seen hard disks as well as Flash p Schooner 2011 Schooner Information Information Technology, Technology. p41 All rights reserved.

42 #17 Automated ReplicaSon Failover Async/ semi-sync Issue: MySQL does not include failover of replication Typical solutions Use custom external tool-kits Manual work when instances fail SchoonerSQL Integrated support for failover of all replication types p Schooner 2011 Schooner Information Information Technology, Technology. p42 All rights reserved.

43 #17 Automated ReplicaSon Failover (with Sync replicason) Synchronous Cluster WRITES Synchronous Cluster WRITES WRITES Read Master REPL REPL REPL MASTER Read Master REPL REPL WRITES MASTER Read Master Read Master SchoonerSQL Read Master Read Master SchoonerSQL p Schooner 2011 Schooner Information Information Technology, Technology. p43 All rights reserved. Instantaneous Failover

44 #17 Automated ReplicaSon Failover (with Async replicason) 1/2 Synchronous Cluster WRITES Synchronous Cluster Read Master REPL REPL REPL MASTER WRITES Async REPL REPL MASTER Read Master Read Master Data Center #1 Read Master Data Center #2 Read Master p Schooner 2011 Schooner Information Information Technology, Technology. p44 All rights reserved.

#17 Automated ReplicaSon Failover (with Async replicason) 2/2 Synchronous Cluster WRITES Synchronous Cluster Read Master REPL REPL WRITES MASTER Async REPL REPL MASTER Read Master Read

45 #17 Automated ReplicaSon Failover (with Async replicason) 2/2 Synchronous Cluster WRITES Synchronous Cluster Read Master REPL REPL WRITES MASTER Async REPL REPL MASTER Read Master Read Master Data Center #1 ReplicaPon Failover Read Master Data Center #2 Read Master p Schooner 2011 Schooner Information Information Technology, Technology. p45 All rights reserved.

46 #18 Mixed Hardware Async/ semi-sync Issue: Smaller hardware for Slave causes it to lag Sync Issue: Cluster executes commits at the pace of the weakest H/W Typical solutions Use better (or identical) hardware for Slave servers Use Flash memory in Slave servers (alleviate single threaded Slave) SchoonerSQL SchoonerSQL sync commits at the pace of weakest H/W SchoonerSQL async with parallel replication has higher chances of staying close with Master s commit speed p Schooner 2011 Schooner Information Information Technology, Technology. p46 All rights reserved.

47 #19 Virtualized or Cloud Environments Async/ semi-sync/ sync Issue: IO latency and throughput is typically poor Sync Issue: Frequent failure detections stemming from resource starvation Typical solutions Working-set or database is maintained in main-memory (avoid read IOs) Databases are heavily sharded (to reduce read and write IOs) SchoonerSQL Support sync only on well provisioned servers, typically with elevated failure detection timeouts. Async provides speedup (parallel threads hide longer latencies) p Schooner 2011 Schooner Information Information Technology, Technology. p47 All rights reserved.

48 #20 ElasScity Requirements Async/ semi-sync/ sync Issue: Dynamically add/remove Slaves based on load or trends Sync Issue: Disables an instance while a new instances is provisioned Typical solutions Manual work, scripts, proxies SchoonerSQL Sync instance is online while provisioning another instance A click in the GUI provisions a Slave that starts servicing read load. A click removes an instance from the cluster Dynamically add virtual IPs that load balance between instances p Schooner 2011 Schooner Information Information Technology, Technology. p48 All rights reserved.

49 Part Three What is SchoonerSQL? SchoonerSQL is a complete distribution of MySQL+InnoDB mysqld smells & feels the same 100% client compatible, uses same database files Installer Cluster manager GUI, CLI Administer and monitor Backup & schedules System and MySQL metric collection & display Utility to capture an incident (optionally call-home) High performance & high availability Minimizes replication administration Automatic app failover Automatic repl connection repair Single click provisioning Online upgrades Online maintenance Elastic (user-driven) cluster Alerts p Schooner 2011 Schooner Information Information Technology, Technology. p49 All rights reserved.

SchoonerSQL Benefits Summary High Availability No service

Instant automasc fail- over On- line upgrade and migrason

5 WAN/DR auto- failover High Performance and Scalability

5 Highest performance synchronous and asynchronous

Financial Services, EducaSon High volume web sites

lost data Highest data consistency Ease of AdministraPon No

of- the- box Product Full MySQL + InnoDB: not a toolkit Free

50 SchoonerSQL Benefits Summary High Availability No service interrupson for planned or unplanned database downsme Instant automasc fail- over On- line upgrade and migrason 90% less downsme vs. MySQL 5.5 WAN/DR auto- failover High Performance and Scalability 4-20x more throughput/server vs. MySQL 5.5 Highest performance synchronous and asynchronous replicason clusters Compelling Economics TCO 50% cheaper than MySQL 5.5 Broad Industry Deployment ecommerce, Social Media, Telco, Financial Services, EducaSon High volume web sites Geographically distributed websites High Data Integrity No lost data Highest data consistency Ease of AdministraPon No error- prone manual processes Monitoring and OpSmizaSon Out- of- the- box Product Full MySQL + InnoDB: not a toolkit Free your staff to build your business, not a custom database 100% MySQL Enterprise InnoDB CompaPble p Schooner 2011 Schooner Information Information Technology, Technology. p50 All rights reserved.

51 Thank You!

Performance comparisons and trade-offs for various MySQL replication schemes

Performance comparisons and trade-offs for various MySQL replication schemes Darpan Dinker VP Engineering Brian O Krafka, Chief Architect Schooner Information Technology, Inc. http://www.schoonerinfotech.com/