20 Real-World Use Cases to help pick a better MySQL Replication scheme (2012)

MySQL Replication: Pros and ConsAchieve Higher Performance, Uptime, Reliability and Simplicity for Real-World Use Cases.Darpan DinkerVP of EngineeringSchooner Information Technology

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 © 20122011 Schooner Information Technology. All rights reserved. p2 | © Schooner Information Technology, p2

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

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

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 ? © 20122011 Schooner Information Technology. All rights reserved. p5 | © Schooner Information Technology, p5

Answer to Parallelism: SchoonerSQL Slave commits on Sysbench Slave commits on DBT2 6,000,000 11,174,862 5,326,066 12,000,000 5,080,958 5,000,000 10,000,000 9,456,770 Commit/ 3900 sec 4,000,000 8,000,000 commit/1800s 6,000,000 3,000,000 4,000,000 3,235,410 3,239,277 2,000,000 1,693,476 1,782,231 2,000,000 1,000,000 0 Percona 5.5.20 Stock 5.5.21 Schooner SYNC Schooner 0 ASYNC Percona 5.5.20 Schooner Schooner Stock 5.5.21 ASYNC SYNC TPCC-mysql Throughput @ 5000W 2500 2200 2190 2000 2-10X throughput on Commits / sec 1500 1598 SchoonerSQL Slaves 1000 700 Master Slave 500 0 Schooner 5.1.3 Async Percona 5.5.20 Async © 20122011 Schooner Information Technology. All rights reserved. p6 | © Schooner Information Technology, p6

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

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 © 20122011 Schooner Information Technology. All rights reserved. p9 | © Schooner Information Technology, p9

Things to Watch Out for in Parallel Replication ImplementationsTransaction Ordering (1/2): Master (Transactions on Master) T2 T1 T3 T4 T5 MASTER #1 T1 T2 T3 Commit order T1 T2 T3 T4 T5 (In InnoDB and binary log) © 2012 Schooner Information Technology, p10 All rights reserved. p10 | © 2011 Schooner Information Technology.

Things to Watch Out for in Parallel Replication ImplementationsTransaction Ordering (2/2): Slave or 2nd Master (order in relay log or sync replication buffers) T5 T4 T3 T2 T1 MASTER #2 T1 T2 T3 Commit order T5 T4 T3 T2 T1 (In InnoDB and binary log) © 2012 Schooner Information Technology, p11 All rights reserved. p11 | © 2011 Schooner Information Technology.

MySQL Replication 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 © 2012 Schooner Information Technology, p12 All rights reserved. p12 | © 2011 Schooner Information Technology.

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

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

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

Qualitative Comparison MySQL 5.5 SchoonerSQL MySQL 5.5 SchoonerSQL XtraDB Cluster SchoonerSQL Asynchronous Asynchronous Semi- Semi- Synchronous Synchronous Synchronous Synchronous*Parallel replication(for same schema) N Y N Y Y YThroughput Medium High Medium High Medium HighHigh network latency tolerant Y Y N N N NMulti-level failure detection N Y N Y N YGlobal transaction IDs N Y N Y N YCapacity with transient failures Y Y Y Y N YCommit consistency Y Y Y Y N YAuto recovery with high consistency Medium High Medium High Medium HighAuto replication failover and repair N Y N Y Y YLarge update/ insert/ LOAD INFILE Y Y Y Y N YUnexpected aborts& deadlocks N N N N Y NMulti-Master Cluster N N N N Y N * Future release © 2012 Schooner Information Technology, p16 All rights reserved. p16 | © 2011 Schooner Information Technology.

#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. © 2012 Schooner Information Technology, p18 All rights reserved. p18 | © 2011 Schooner Information Technology.

#2 Read Scaling • Async/ semi-sync/ sync Sysbench Read/Write 300000 – Issue: Scale read queries for a read Reads/s intensive application 250000 Writes/s 200000 150000 • Typical solution 100000 – MySQL replication allows unlimited 50000 number of Slaves 0 1 2 4 8 Nodes in Schooner Cluster • SchoonerSQL – Schooner sync supports consistent reads from up to 7 Slaves – Schooner async allows same unlimited number of Slaves © 2012 Schooner Information Technology, p19 All rights reserved. p19 | © 2011 Schooner Information Technology.

#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 © 2012 Schooner Information Technology, p20 All rights reserved. p20 | © 2011 Schooner Information Technology.

#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 © 2012 Schooner Information Technology, p21 All rights reserved. p21 | © 2011 Schooner Information Technology.

Base Sync replication (LAN)p22 | © 2011 Schooner Information Technology. Auto client connection failover© 2012 Schooner Information Technology, p22 All rights reserved. Sync node failures (up to 7) #4 High Availability (HA): SchoonerSQL Auto sync connection repair Fault tolerance (sync -> async -> sync) Async WAN connection repair WAN level failover Two tier failure detection Self healing

#5 Server Sprawl, Inefficient Hardware Utilization • 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,000,000 5,080,958 – Issue: DRBD stand-by servers 4,000,000 commit/1800s 3,000,000 • Typical solutions – Use a Slave solely for backups 2,000,000 1,693,476 1,782,231 – Add Slave servers 1,000,000 0 Percona 5.5.20 Schooner Schooner Stock 5.5.21 ASYNC SYNC • SchoonerSQL – Provides high consolidation via high vertical scalability and 2-10X faster Slave replication © 2012 Schooner Information Technology, p23 All rights reserved. p23 | © 2011 Schooner Information Technology.

#5 Server Sprawl, Inefficient Hardware UtilizationSchoonerSQL Vertical Scalability CPU Scalability IO Scalability 10000 1600 9000 1400 8000 Utilization (CPU threads) 1200 7000 1000 6000 IOPS 5000 800 4000 Read IOPS 600 3000 Write IOPS 400 2000 200 1000 0 0 1 4 16 64 1 4 16 64 Total concurrent connections Total concurrent connections Network Scalability 30 SchoonerSQL scales on 25 Bandwidth (MBps) 20 multi-cores & Flash 15 Network in 10 Network out 5 0 Benchmark: 5000 warehouse TPCC-MySQL 1 4 16 64 © 2012 Schooner Information Technology, p24 All rights reserved. p24 | © 2011 Schooner Information Technology. Total concurrent connections

#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 © 2012 Schooner Information Technology, p25 All rights reserved. p25 | © 2011 Schooner Information Technology.

#7 WAN and Multi-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 © 2012 Schooner Information Technology, p26 All rights reserved. p26 | © 2011 Schooner Information Technology.

#7 WAN and Multi-Data Center Deployments: SchoonerSQL Synchronous Synchronous Cluster Cluster READS WRITES READS READS READS READS WRITES READS READS Parallel READS REPL Async REPL Read Read REPL REPL Master REPL REPL Master MASTER MASTER Read Master Read Master Read Master Read Master Data Center #1 Data Center #2 © 2012 Schooner Information Technology, p27 All rights reserved. p27 | © 2011 Schooner Information Technology.

#7 WAN and Multi-Data Center Deployments: SchoonerSQL SchoonerSQL asynchronous replication performance © 2012 Schooner Information Technology, p28 All rights reserved. p28 | © 2011 Schooner Information Technology.

#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. © 2012 Schooner Information Technology, p29 All rights reserved. p29 | © 2011 Schooner Information Technology.

#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. © 2012 Schooner Information Technology, p30 All rights reserved. p30 | © 2011 Schooner Information Technology.

#10 Minimize Administration • 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 © 2012 Schooner Information Technology, p31 All rights reserved. p31 | © 2011 Schooner Information Technology.

#10 Minimize AdministrationSchoonerSQL: 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 © 2012 Schooner Information Technology, p32 All rights reserved. p32 | © 2011 Schooner Information Technology.

#10 Minimize AdministrationSchoonerSQL: 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 © 2012 Schooner Information Technology, p33 All rights reserved. p33 | © 2011 Schooner Information Technology.

#10 Minimize AdministrationSchoonerSQL: Alerts • SchoonerSQL provides email 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 © 2012 Schooner Information Technology, p34 All rights reserved. p34 | © 2011 Schooner Information Technology.

#11 MySQL Master-Master Setup (Active/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. © 2012 Schooner Information Technology, p35 All rights reserved. p35 | © 2011 Schooner Information Technology.

#11 MySQL Master-Master Setup (Active/Passive) Synchronous Synchronous Cluster READS WRITES Cluster READS WRITES READS READS READS WRITES READS READS READS REPL REPL WRITES Read Read REPL REPL Master Master REPL MASTER MASTER Read Master Read Master Read Master Read Master SchoonerSQL SchoonerSQL Instantaneous Failover © 2012 Schooner Information Technology, p36 All rights reserved. p36 | © 2011 Schooner Information Technology.

#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). © 2012 Schooner Information Technology, p37 All rights reserved. p37 | © 2011 Schooner Information Technology.

#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 5.1.5 © 2012 Schooner Information Technology, p38 All rights reserved. p38 | © 2011 Schooner Information Technology.

#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. © 2012 Schooner Information Technology, p39 All rights reserved. p39 | © 2011 Schooner Information Technology.

#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. © 2012 Schooner Information Technology, p40 All rights reserved. p40 | © 2011 Schooner Information Technology.

#16 Very Large Databases • Async/ semi-sync TPCC-mysql Sample @ 0.5 TB 2500 – Issue: Working set may be larger than 2200 2190 main-memory -> slow Slave replication 2000 1598 Commits / sec – Issue: Large databases take longer 1500 to backup Master 1000 700 Slave 500 • Typical solution 0 – Throttle backup and control database size Schooner 5.1.3 Percona 5.5.20 Async Async – Use snapshots for backup • 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 © 2012 Schooner Information Technology, p41 All rights reserved. p41 | © 2011 Schooner Information Technology.

#17 Automated Replication 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 © 2012 Schooner Information Technology, p42 All rights reserved. p42 | © 2011 Schooner Information Technology.

#17 Automated Replication Failover (with Sync replication) Synchronous Synchronous Cluster READS WRITES Cluster READS WRITES READS READS READS WRITES READS READS READS REPL REPL WRITES Read Read REPL REPL Master Master REPL MASTER MASTER Read Master Read Master Read Master Read Master SchoonerSQL SchoonerSQL Instantaneous Failover © 2012 Schooner Information Technology, p43 All rights reserved. p43 | © 2011 Schooner Information Technology.

#17 Automated Replication Failover (with Async replication) –1/2 Synchronous Synchronous Cluster Cluster READS WRITES READS READS READS WRITES READS READS READS READS REPL Read Async REPL REPL Master REPL REPL MASTER MASTER Read Master Read Master Read Master Read Master Data Center #1 Data Center #2 © 2012 Schooner Information Technology, p44 All rights reserved. p44 | © 2011 Schooner Information Technology.

#17 Automated Replication Failover (with Async replication) –2/2 Synchronous Synchronous Cluster Cluster READS WRITES READS READS READS READS READS READS READS REPL WRITES Read REPL Master REPL REPL MASTER MASTER Read Master Read Master Read Master Read Master Data Center #1 Data Center #2 Replication Failover © 2012 Schooner Information Technology, p45 All rights reserved. p45 | © 2011 Schooner Information Technology.

#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 © 2012 Schooner Information Technology, p46 All rights reserved. p46 | © 2011 Schooner Information Technology.

#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) © 2012 Schooner Information Technology, p47 All rights reserved. p47 | © 2011 Schooner Information Technology.

#20 Elasticity 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 © 2012 Schooner Information Technology, p48 All rights reserved. p48 | © 2011 Schooner Information Technology.

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

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

Thank You!www.schoonersql.com@schoonerinfo

http://www.scoop.it	111
http://webcache.googleusercontent.com	1
http://www.linkedin.com	1

20 Real-World Use Cases to help pick a better MySQL Replication scheme (2012)

by Darpan Dinker on Apr 13, 2012

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 113

Statistics

20 Real-World Use Cases to help pick a better MySQL Replication scheme (2012) Presentation Transcript