Contenu connexe Similaire à 20 Real-World Use Cases to help pick a better MySQL Replication scheme (2012) (20) 20 Real-World Use Cases to help pick a better MySQL Replication scheme (2012)1. MySQL Replication: Pros and Cons
Achieve Higher Performance, Uptime, Reliability and Simplicity
for Real-World Use Cases.
Darpan Dinker
VP of Engineering
Schooner Information Technology
2. p2 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p2
© 2012 Schooner Information Technology, p2
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
3. p3 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p3
© 2012 Schooner Information Technology, p3
• 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
• 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
20 Real-World Use Cases
4. p4 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p4
© 2012 Schooner Information Technology, p4
• Concepts that effect MySQL replication
– Parallelism
– Flow control
– Consistency & Serializability
• Quick tour of replication schemes for MySQL
– Asynchronous
– Semi-synchronous
– Synchronous
Part One
5. p5 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p5
© 2012 Schooner Information Technology, p5
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 ?
6. p6 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p6
Answer to Parallelism: SchoonerSQL
2-10X throughput on
SchoonerSQL Slaves
1,693,476
5,326,066
5,080,958
1,782,231
0
1,000,000
2,000,000
3,000,000
4,000,000
5,000,000
6,000,000
Percona 5.5.20 Schooner
ASYNC
Schooner SYNC Stock 5.5.21
commit/1800s
Slave commits on Sysbench
3,235,410 3,239,277
11,174,862
9,456,770
0
2,000,000
4,000,000
6,000,000
8,000,000
10,000,000
12,000,000
Percona 5.5.20 Stock 5.5.21 Schooner SYNC Schooner
ASYNC
Commit/
3900
sec
Slave commits on DBT2
2200
1598
2190
700
0
500
1000
1500
2000
2500
Schooner 5.1.3 Async Percona 5.5.20 Async
Commits
/
sec
TPCC-mysql Throughput @ 5000W
Master
Slave
7. p7 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p7
© 2012 Schooner Information Technology, p7
Flow Control
8. p8 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p8
© 2012 Schooner Information Technology, p8
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
Flow Control in Replication
9. p9 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p9
© 2012 Schooner Information Technology, p9
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
10. p10 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p10
© 2012 Schooner Information Technology, p10
Things to Watch Out for in Parallel Replication Implementations
Transaction Ordering (1/2): Master
T5
T3
T1
T4
T2
Commit order
T3
T1 T2
T1 T2 T3 T4 T5
(In InnoDB and binary log)
(Transactions on Master)
MASTER
#1
11. p11 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p11
© 2012 Schooner Information Technology, p11
Things to Watch Out for in Parallel Replication Implementations
Transaction Ordering (2/2): Slave or 2nd Master
T1
T2
T3
T4
T5
Commit order
T3
T1 T2
T5 T4 T3 T2 T1
(In InnoDB and binary log)
(order in relay log or sync replication buffers)
MASTER
#2
12. p12 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p12
© 2012 Schooner Information Technology, p12
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
13. p13 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p13
#1 MySQL Asynchronous Replication
• 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
• 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
Master mysqld Slave mysqld
Relay
log
InnoDB
Tx log
DB
MySQL
Bin log
InnoDB
Tx log
DB
Last tx=100 Last tx=100 Last tx=70 Last tx=50
Log events pulled by Slave
Tx.Commit(101) Repl.apply(51)
tx=101 tx=101 tx=51 tx=51
Read version based on tx=50
Read Stale data on Slave
No flow control
Corruption
Master failure = mess
Data loss
Single-threaded Slave
14. p14 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p14
#2 MySQL Semi-synchronous Replication
• 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
• 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
Master mysqld Slave mysqld
Relay
log
InnoDB
Tx log
DB
MySQL
Bin log
InnoDB
Tx log
DB
Last tx=100 Last tx=100 Last tx=100 Last tx=50
Log for tx=100 pulled by Slave
Tx.Commit(101) Repl.apply(51)
tx=101 tx=101 tx=51 tx=51
Read version based on tx=50
Slave ACK for tx=100
Read Stale data on Slave
No flow control
Corruption
Master failure = mess
Data loss
Single threaded Slave
15. p15 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p15
#3 SchoonerSQL Synchronous Replication
• Tightly-coupled master/slave
relationship
• After commit, all Slaves guaranteed to
receive and commit the change
• Slave in lock-step with Master
• 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
Master mysqld Slave mysqld
InnoDB
Tx log
DB
MySQL
Bin log
InnoDB
Tx log
DB
Last tx=100 Last tx=100 Last tx=100
Log for tx=100 pushed to Slave
Tx.Commit(101)
tx=101
tx=100
Read version based on tx=100
Slave ACK for tx=100 Repl.apply(100)
Read Stale data on Slave
No flow control
Corruption
Master failure = mess
Data loss
Single threaded Slave
16. p16 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p16
Qualitative Comparison
MySQL 5.5
Asynchronous
SchoonerSQL
Asynchronous
MySQL 5.5
Semi-
Synchronous
SchoonerSQL
Semi-
Synchronous*
XtraDB Cluster
Synchronous
SchoonerSQL
Synchronous
Parallel replication (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
Multi-level failure detection N Y N Y N Y
Global transaction 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 replication 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
Multi-Master Cluster N N N N Y N
* Future release
17. p17 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p17
© 2012 Schooner Information Technology, p17
20 real-world use cases: which replication
mechanisms to choose and why?
Part Two
18. p18 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p18
© 2012 Schooner Information Technology, p18
#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.
19. p19 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p19
© 2012 Schooner Information Technology, p19
#2 Read Scaling
0
50000
100000
150000
200000
250000
300000
1 2 4 8
Nodes in Schooner Cluster
Sysbench Read/Write
Reads/s
Writes/s
• Async/ semi-sync/ sync
– Issue: Scale read queries for a read
intensive application
• Typical solution
– MySQL replication allows unlimited
number of Slaves
• SchoonerSQL
– Schooner sync supports consistent reads from up to 7 Slaves
– Schooner async allows same unlimited number of Slaves
20. p20 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p20
© 2012 Schooner Information Technology, p20
#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
21. p21 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p21
© 2012 Schooner Information Technology, p21
#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
22. p22 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p22
© 2012 Schooner Information Technology, p22
#4 High Availability (HA): SchoonerSQL
Base
Sync
replication
(LAN)
Auto
client
connection
failover
Sync
node
failures
(up
to
7)
Auto
sync
connection
repair
Fault
tolerance
(sync
->
async
->
sync)
Async
WAN
connection
repair
WAN
level
failover
Two
tier
failure
detection
Self
healing
23. p23 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p23
© 2012 Schooner Information Technology, p23
#5 Server Sprawl, Inefficient Hardware Utilization
• Async/ semi-sync/ sync
– Issue: Software bottlenecks force premature sharding
Issue: Servicing reads or taking backup
on Slave conflicts with single
threaded Slave
– Issue: DRBD stand-by servers
• Typical solutions
– Use a Slave solely for backups
– Add Slave servers
• SchoonerSQL
– Provides high consolidation via high
vertical scalability and 2-10X faster Slave replication
1,693,476
5,326,066
5,080,958
1,782,231
0
1,000,000
2,000,000
3,000,000
4,000,000
5,000,000
6,000,000
Percona 5.5.20 Schooner
ASYNC
Schooner SYNC Stock 5.5.21
commit/1800s
Slave commits on Sysbench
24. p24 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p24
© 2012 Schooner Information Technology, p24
#5 Server Sprawl, Inefficient Hardware Utilization
SchoonerSQL Vertical Scalability
0
200
400
600
800
1000
1200
1400
1600
1 4 16 64
Utilization
(CPU
threads)
Total concurrent connections
CPU Scalability
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
1 4 16 64
IOPS
Total concurrent connections
IO Scalability
Read IOPS
Write IOPS
0
5
10
15
20
25
30
1 4 16 64
Bandwidth
(MBps)
Total concurrent connections
Network Scalability
Network in
Network out
SchoonerSQL scales on
multi-cores & Flash
Benchmark: 5000 warehouse TPCC-MySQL
25. p25 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p25
© 2012 Schooner Information Technology, p25
#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
26. p26 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p26
© 2012 Schooner Information Technology, p26
#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
27. p27 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p27
© 2012 Schooner Information Technology, p27
MASTER
Read Master
READS
REPL
Read
Master
Read Master
REPL
READS
READS
READS
Data Center #1
WRITES
WRITES
REPL
Synchronous
Cluster
MASTER
Read Master
READS
REPL
Read
Master
Read Master
REPL
REPL
READS
READS
READS
Data Center #2
Synchronous
Cluster
Parallel
Async
#7 WAN and Multi-Data Center Deployments: SchoonerSQL
28. p28 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p28
© 2012 Schooner Information Technology, p28
#7 WAN and Multi-Data Center Deployments: SchoonerSQL
SchoonerSQL asynchronous replication performance
29. p29 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p29
© 2012 Schooner Information Technology, p29
#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.
30. p30 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p30
© 2012 Schooner Information Technology, p30
#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.
31. p31 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p31
© 2012 Schooner Information Technology, p31
#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
32. p32 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p32
© 2012 Schooner Information Technology, p32
#10 Minimize Administration
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
33. p33 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p33
© 2012 Schooner Information Technology, p33
#10 Minimize Administration
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
34. p34 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p34
© 2012 Schooner Information Technology, p34
#10 Minimize Administration
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
35. p35 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p35
© 2012 Schooner Information Technology, p35
#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.
36. p36 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p36
© 2012 Schooner Information Technology, p36
#11 MySQL Master-Master Setup (Active/Passive)
MASTER
Read Master
READS
REPL
Read
Master
Read Master
REPL
READS
READS
READS
SchoonerSQL
WRITES
WRITES
REPL
Synchronous
Cluster
MASTER
Read Master
READS
Read
Master
Read Master
REPL
READS
READS
READS
SchoonerSQL
WRITES
WRITES
REPL
Synchronous
Cluster
Instantaneous Failover
37. p37 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p37
© 2012 Schooner Information Technology, p37
#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).
38. p38 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p38
© 2012 Schooner Information Technology, p38
#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
39. p39 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p39
© 2012 Schooner Information Technology, p39
#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.
40. p40 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p40
© 2012 Schooner Information Technology, p40
#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.
41. p41 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p41
© 2012 Schooner Information Technology, p41
#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
• Typical solution
– Throttle backup and control database size
– 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
2200
1598
2190
700
0
500
1000
1500
2000
2500
Schooner 5.1.3
Async
Percona 5.5.20
Async
Commits
/
sec
TPCC-mysql Sample @ 0.5 TB
Master
Slave
42. p42 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p42
© 2012 Schooner Information Technology, p42
#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
43. p43 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p43
© 2012 Schooner Information Technology, p43
#17 Automated Replication Failover (with Sync replication)
MASTER
Read Master
READS
REPL
Read
Master
Read Master
REPL
READS
READS
READS
SchoonerSQL
WRITES
WRITES
REPL
Synchronous
Cluster
MASTER
Read Master
READS
Read
Master
Read Master
REPL
READS
READS
READS
SchoonerSQL
WRITES
WRITES
REPL
Synchronous
Cluster
Instantaneous Failover
44. p44 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p44
© 2012 Schooner Information Technology, p44
#17 Automated Replication Failover (with Async replication) –
1/2
MASTER
Read Master
READS
REPL
Read
Master
Read Master
REPL
READS
READS
READS
Data Center #1
WRITES
WRITES
REPL
Synchronous
Cluster
MASTER
Read Master
READS
REPL
Read Master
REPL
READS
READS READS
Data Center #2
Synchronous
Cluster
Async
45. p45 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p45
© 2012 Schooner Information Technology, p45
#17 Automated Replication Failover (with Async replication) –
2/2
MASTER
Read Master
READS
Read
Master
Read Master
REPL
READS
READS
READS
Data Center #1
WRITES
WRITES
REPL
Synchronous
Cluster
MASTER
Read Master
READS
REPL
Read Master
REPL
READS
READS READS
Data Center #2
Synchronous
Cluster
Replication Failover
46. p46 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p46
© 2012 Schooner Information Technology, p46
#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
47. p47 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p47
© 2012 Schooner Information Technology, p47
#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)
48. p48 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p48
© 2012 Schooner Information Technology, p48
#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
49. p49 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p49
© 2012 Schooner Information Technology, p49
What is SchoonerSQL ?
Part Three
• 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
50. p50 | © 2011 Schooner Information Technology. All rights reserved.
© 2012 Schooner Information Technology, p50
SchoonerSQL Benefits Summary
• 4-20x more throughput/server vs. MySQL 5.5
•Highest performance synchronous and
asynchronous replication clusters
High Performance and Scalability
• No service interruption for planned or
unplanned database downtime
•Instant automatic fail-over
• On-line upgrade and migration
• 90% less downtime vs. MySQL 5.5
• WAN/DR auto-failover
High Availability
Ease of Administration
• No error-prone manual processes
• Monitoring and Optimization
• No lost data
• Highest data consistency
High Data Integrity
• Full MySQL + InnoDB: not a toolkit
• Free your staff to build your business,
not a custom database
•TCO 50% cheaper than MySQL 5.5
Compelling Economics
Out-of-the-box Product
100% MySQL Enterprise
InnoDB Compatible
Broad Industry Deployment
• eCommerce, Social Media, Telco, Financial
Services, Education
• High volume web sites
• Geographically distributed websites
Notes de l'éditeur
Seed questions:
Where did get the name Schooner?
What is the migration path from MySQL to SchoonerSQL?
What about from another database distribution like Oracle database, IBM DB2, or Microsoft SQL server?
*Recap at end