Mysql Replication: Pros and Cons

MySQL Replication: Pros and Cons
Achieve Higher Performance, Uptime, Reliability and Simplicity

for Real-World Use Cases.
Darpan Dinker @darpandinker

VP of Engineering
Schooner 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
©
p22012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
p2 All rights reserved.
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
©
p32012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
Part One
•  Concepts that effect MySQL replication

–  Parallelism
–  Flow control
–  Consistency & Serializability
•  Quick tour of replication schemes for MySQL

–  Asynchronous
–  Semi-synchronous
–  Synchronous
©
p42012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
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 ?
©
p52012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
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

8,000,000
commit/1800s
4,000,000
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 SYNC Stock 5.5.21
ASYNC
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
©
p62012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
Flow Control
©
p72012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
Flow Control in ReplicaSon
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
parallel async replication & slave-lag
reduce slave-lag –  Action: use similar H/W within
a cluster
©
p82012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
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
©
p92012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
Things to Watch Out for in Parallel ReplicaSon ImplementaSons
TransacSon Ordering (1/2): Master
(TransacSons on Master)

T2
T1
T3 T4
T5
T1 T2
T3
Commit order
T1 T2 T3 T4 T5
(In InnoDB and binary log)
©
p10
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
Things to Watch Out for in Parallel ReplicaSon ImplementaSons
TransacSon Ordering (2/2): Slave or 2nd Master
(order in relay log or sync replicaSon buffers)
T5 T4 T3 T2 T1
T1 T2
T3
Commit order
T5 T4 T3 T2 T1
(In InnoDB and binary log)
©
p11
2012
| © 2011
Schooner
Schooner
Information
Information
Technology,
Technology.
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
©
p12
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#1 MySQL Asynchronous ReplicaSon
Read version based on tx=50

Read Stale data on Slave
Master mysqld No flow control Slave mysqld
CorrupPon
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
©
p13
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#2 MySQL Semi-‐synchronous ReplicaSon

No flow control
Master mysqld Slave mysqld
CorrupPon
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
©
p14
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#3 SchoonerSQL Synchronous ReplicaSon
Master mysqld Log for tx=100 pushed to Slave Slave mysqld
Slave ACK for tx=100 Repl.apply(100)
Tx.Commit(101)

No flow control tx=100
tx=101
CorrupPon
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
©
p15
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
QualitaSve Comparison
MySQL 5.5 SchoonerSQL MySQL 5.5 SchoonerSQL XtraDB Cluster SchoonerSQL

Asynchronous Asynchronous Semi-‐ Semi-‐ Synchronous Synchronous
Synchronous 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
©
p16
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
Part Two
20 real-world use cases: which replication

mechanisms to choose and why?
©
p17
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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.
©
p18
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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
©
p19
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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
–  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
©
p20
2012
disks
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#4 High Availability (HA)
–  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
–  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
©
p21
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
©
p22
2012
| © Schooner
2011 Schooner
Base
Information
Information
Technology,
Sync replicaSon (LAN)
Technology.
Auto client connecSon

failover
Av
Sync node failures (up to

ail
7)
abi
#4 High Availability (HA): SchoonerSQL
Auto sync connecSon

lit
repair
y
Fault tolerance (sync -‐>

async -‐> sync)
Async WAN connecSon

repair
WAN level failover
Two Ser failure detecSon
Self healing
#5 Server Sprawl, Inefficient Hardware USlizaSon

–  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
–  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 SYNC Stock 5.5.21
ASYNC
•  SchoonerSQL
–  Provides high consolidation via high
vertical scalability and 2-10X faster Slave replication
©
p23
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#5 Server Sprawl, Inefficient Hardware USlizaSon
SchoonerSQL VerScal Scalability
CPU Scalability IO Scalability

10000
1600
9000
1400
UPlizaPon (CPU threads)
8000
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 connecPons
Total concurrent connecPons
Network Scalability
30
SchoonerSQL scales on 25

Bandwidth (MBps)
20
mul9-‐cores & Flash 15

Network in
10
Network out
5
0
Benchmark: 5000 warehouse TPCC-‐MySQL 1 4 16 64
©
p24
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
p24 All rights reserved. Total concurrent connecPons
#6 Full and Incremental Backup
–  Issue: Slave instance may lag due to backup
•  Sync
–  Issue: Flow control may be triggered slowing down the commits
–  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
©
p25
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#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
–  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
©
p26
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#7 WAN and MulS-‐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 REPL
Master REPL Master
MASTER MASTER
Read Master Read Master

Data Center #1 Data Center #2
©
p27
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#7 WAN and MulS-‐Data Center Deployments: SchoonerSQL
SchoonerSQL asynchronous replication performance
©
p28
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#8 Online Schema Updates

–  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
–  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.
©
p29
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#9 Online Maintenance and Upgrades

–  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
–  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.
©
p30
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#10 Minimize AdministraSon

–  Issue: MySQL requires considerable configuration and administration
for replication, failure-detection, failover, backup/restore
–  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
©
p31
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
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
©
p32
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
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
©
p33
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
SchoonerSQL: 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
©
p34
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#11 MySQL Master-‐Master Setup (AcSve/Passive)
–  Issue: Require quick failover upon active Master’s failure
•  Async
–  Issue: May loose transactions upon active Master’s failure
–  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.
©
p35
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#11 MySQL Master-‐Master Setup (AcSve/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

SchoonerSQL SchoonerSQL
Instantaneous Failover
©
p36
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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
–  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).
©
p37
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#13 Resilience
•  Sync
–  Issue: Sensitive to N/W quality, splits cluster at any fault
–  Issue: Read capacity compromised
–  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
©
p38
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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.
–  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.
©
p39
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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.
©
p40
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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
©
p41
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#17 Automated ReplicaSon Failover
–  Issue: MySQL does not include failover of replication
–  Use custom external tool-kits
–  Manual work when instances fail
•  SchoonerSQL
–  Integrated support for failover of all replication types
©
p42
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#17 Automated ReplicaSon Failover (with Sync replicaSon)
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

SchoonerSQL SchoonerSQL
Instantaneous Failover
©
p43
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#17 Automated ReplicaSon Failover (with Async replicaSon) –
1/2
Synchronous
Synchronous
Cluster
READS
READS WRITES READS READS
READS READS
REPL
Read
Async
REPL REPL REPL
Master REPL
MASTER MASTER

©
p44
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#17 Automated ReplicaSon Failover (with Async replicaSon) –
2/2
Synchronous
Synchronous
Cluster
READS
READS READS READS
READS READS

Read
REPL WRITES Async
REPL
Master REPL REPL
MASTER MASTER

ReplicaPon Failover
©
p45
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#18 Mixed Hardware
–  Issue: Smaller hardware for Slave causes it to lag
•  Sync
–  Issue: Cluster executes commits at the pace of the weakest H/W
–  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
©
p46
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#19 Virtualized or Cloud Environments

–  Issue: IO latency and throughput is typically poor
•  Sync
–  Issue: Frequent failure detections stemming from resource starvation
–  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)
©
p47
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
#20 ElasScity Requirements

–  Issue: Dynamically add/remove Slaves based on load or trends
•  Sync
–  Issue: Disables an instance while a new instances is provisioned
–  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
©
p48
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
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)
©
p49
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
SchoonerSQL Benefits Summary
High Availability High Data Integrity

•  No service interrupSon for planned or •  No lost data
unplanned database downSme •  Highest data consistency
• Instant automaSc fail-‐over
•  On-‐line upgrade and migraSon
•  90% less downSme vs. MySQL 5.5
•  WAN/DR auto-‐failover Ease of AdministraPon
•  No error-‐prone manual processes
High Performance and Scalability •  Monitoring and OpSmizaSon
•  4-‐20x more throughput/server vs. MySQL 5.5
• Highest performance synchronous and
asynchronous replicaSon 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 CompaPble
Services, EducaSon
•  High volume web sites
•  Geographically distributed websites
©
p50
2012
| © Schooner
2011 Schooner
Information
Information
Technology,
Technology.
Thank You!
www.schoonersql.com
@schoonerinfo

Mysql Replication: Pros and Cons

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mysql Replication: Pros and Cons

Transféré par

Droits d'auteur :

Formats disponibles

MySQL Replication: Pros and Cons

Achieve Higher Performance, Uptime, Reliability and Simplicity

Darpan Dinker @darpandinker

• Quick tour of MySQL asynchronous, semi-synchronous and

• 20 real-world use cases: which replication mechanisms to choose

• High write rate • MySQL Master-Master

• Concepts that effect MySQL replication

• Quick tour of replication schemes for MySQL

• Commodity hardware: 4-10 core processors

• Hard-disks have >5ms latency (random)

• Flash memory offers >50k IOPS

Slave commits on Sysbench Slave commits on DBT2

Commit/ 3900 sec

2-­‐10X throughput on Commits / sec

SchoonerSQL Slaves 1000

No flow control With flow control

• Serializability: a transaction schedule is serializable if its outcome

• MySQL Slave is single threaded, i.e. executes and commits in a

• SchoonerSQL Slave (async/semi-sync*/sync)

(TransacSons on Master)

(order in relay log or sync replicaSon buﬀers)

Read version based on tx=50

InnoDB MySQL Log events pulled by Slave Relay InnoDB

• Loosely coupled master/slave • Read on slave can give old data

Read version based on tx=50

• Semi-coupled master/slave relationship • Read on slave can give old data

Read version based on tx=100

Read Stale data on Slave

• Tightly-coupled master/slave • Read on slave gives latest committed

MySQL 5.5 SchoonerSQL MySQL 5.5 SchoonerSQL XtraDB Cluster SchoonerSQL

Throughput Medium High Medium High Medium High

MulS-­‐level failure detecSon N Y N Y N Y

Global transacPon IDs N Y N Y N Y

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

20 real-world use cases: which replication

• Async/ semi-sync/ sync Sysbench Read/Write

• Typical solution 100000

– MySQL replication allows unlimited

• Async/ semi-sync/ sync

• SchoonerSQL for mission-critical applications

p22 All rights reserved.

Sync node failures (up to

Auto sync connecSon

Fault tolerance (sync -­‐>

Async WAN connecSon

WAN level failover

Two Ser failure detecSon

• Async/ semi-sync/ sync

– Issue: DRBD stand-by servers

– Add Slave servers 1,000,000

CPU Scalability IO Scalability

SchoonerSQL scales on 25

mul9-­‐cores & Flash 15

Read Master Read Master

SchoonerSQL asynchronous replication performance

• Async/ semi-sync/ sync

• Async/ semi-sync/ sync

• Async/ semi-sync/ sync

• Integrated GUI simplifies administration

• Easy Server Management

• Monitoring and optimization:

•  Quick tour of MySQL asynchronous, semi-synchronous and

•  20 real-world use cases: which replication mechanisms to choose

•  High write rate •  MySQL Master-Master

•  Concepts that effect MySQL replication

•  Quick tour of replication schemes for MySQL

•  Commodity hardware: 4-10 core processors

•  Hard-disks have >5ms latency (random)

•  Flash memory offers >50k IOPS

2-‐10X throughput on Commits / sec

•  Serializability: a transaction schedule is serializable if its outcome

•  MySQL Slave is single threaded, i.e. executes and commits in a

•  SchoonerSQL Slave (async/semi-sync*/sync)

•  Loosely coupled master/slave •  Read on slave can give old data

•  Semi-coupled master/slave relationship •  Read on slave can give old data

•  Tightly-coupled master/slave •  Read on slave gives latest committed

MulS-‐level failure detecSon N Y N Y N Y

•  Async/ semi-sync/ sync Sysbench Read/Write

•  Typical solution 100000

–  MySQL replication allows unlimited

•  Async/ semi-sync/ sync

•  SchoonerSQL for mission-critical applications

Fault tolerance (sync -‐>

•  Async/ semi-sync/ sync

–  Issue: DRBD stand-by servers

–  Add Slave servers 1,000,000

mul9-‐cores & Flash 15

•  Async/ semi-sync/ sync

•  Async/ semi-sync/ sync

•  Async/ semi-sync/ sync

•  Integrated GUI simplifies administration

•  Easy Server Management

•  Monitoring and optimization:

•  Integrated full & incremental online backup

•  SchoonerSQL provides email based alerts that are very useful in

•  Async/ semi-sync TPCC-‐mysql Sample @ 0.5 TB

•  Async/ semi-sync/ sync

•  Async/ semi-sync/ sync

•  SchoonerSQL is a complete •  High performance & high