database replication policies for dynamic content applications
DESCRIPTION
Database Replication Policies for Dynamic Content Applications. Gokul Soundararajan , Cristiana Amza, Ashvin Goel University of Toronto EuroSys 2006: Leuven, Belgium April 19, 2006. Dynamic Content Web Server. Dynamic Content Web Server. Today’s Server Farms. - PowerPoint PPT PresentationTRANSCRIPT
Database Replication Policies for Dynamic Content ApplicationsGokul Soundararajan, Cristiana Amza, Ashvin GoelUniversity of TorontoUniversity of Toronto
EuroSys 2006: Leuven, BelgiumEuroSys 2006: Leuven, Belgium
April 19, 2006April 19, 2006
2
Dynamic Content Web Server
Internet
Application Server
Web Server
Database Server
3
Dynamic Content Web Server
Internet
Application Server
(Stateless)
Web Server
(Stateless)
Database Server
(Stateful)
4
Today’s Server Farms
Data centers can run multiple applications E.g., IBM/HP
Service providers can multiplex resources E.g., applications have peaks at different times
Challenge: database server becomes the bottleneck
Internet
Application Server
(Stateless)
Web Server
(Stateless)
Database Server
(Stateful)
5
Motivation Scale the database backend on clusters
Handle more clients Run multiple applications Handle failures in the backend
Our approach: Database replication Dynamic replica allocation
Adapt to changing load or failures
6
Database Replication Read-one, write-all Plattner & Alonso, MW 04 Lin et. al, SIGMOD 05 Amza et. al, ICDE 05
Scaling for E-Commerce (TPC-W)
7
Dynamic Replication
Assume a cluster hosts 2 applications App1 (Red) using 2 machines App2 (Blue) using 2 machines
Assume App1 has a load spike
1 2 3 4
Replica SetApp1 = {1,2} Replica SetApp2 = {3,4}
8
Dynamic Replication
Choose nr. of replicas to allocate to App1 Say, we adapt by allocating one more replica
Then, two options App2 still uses two replicas (overlap replica sets) App2 loses one replica (disjoint replica sets)
1 2 3 4
Replica SetApp1 = {1,2} Replica SetApp2 = {3,4}
9
Dynamic Replication
Choose nr. of replicas to allocate to App1 Say, we adapt by allocating one more replica
Then, two options App2 still uses two replicas (overlap replica sets)App2 still uses two replicas (overlap replica sets) App2 loses one replica (disjoint replica sets)
1 2 4
Replica SetApp1 = {1,2,3} Replica SetApp2 = {3,4}
3
10
Dynamic Replication
Choose nr. of replicas to allocate to App1 Say, we adapt by allocating one more replica
Then, two options App2 still uses two replicas (overlap replica sets) App2 loses one replica (disjoint replica sets)App2 loses one replica (disjoint replica sets)
1 2 3 4
Replica SetApp1 = {1,2,3} Replica SetApp2 = {4}
11
Challenges
Adding a replica can take time Bring replica up-to-date Warm-up memory
Can avoid adaptation with fully-overlapped replica sets
Disjoint Full OverlapSLOW Adaptation
NO Adaptation
12
Challenges
However, overlapping applications compete for memory causing interference
Can avoid interference with disjoint replica sets
Disjoint Full OverlapNOInterference
HIGH Interference
13
Challenges
However, overlapping applications compete for memory causing interference
Can avoid interference with disjoint replica sets
Disjoint Full OverlapNOInterference
HIGH Interference
Tradeoff between adaptation delay and interference
14
Insight for Dynamic Content Apps Database reads are much heavier than writes
Reads are multi-table joins Writes are single row updates
Overlapping reads – high interference Overlapping writes – little interference
15
Insight for Dynamic Content Apps Database reads are much heavier than writes
Reads are multi-table joins Writes are single row updates
Overlapping reads – high interference Overlapping writes – little interference
Solution: Separate reads and overlap writes
16
Our Solution – Partial Overlap
Reads of applications sent to disjoint replica sets Avoids interference
Read-Set Set of replicas where reads are sent
1 2 3 4
Read-SetApp1 = {1,2} Read-SetApp2 = {3,4}
17
Our Solution – Partial Overlap
Writes of apps sent to overlapping replica sets Reduces replica addition time
Write-Set Set of replicas where writes are sent
1 2 3 4
Read-SetApp1 = {1,2}Write-SetApp1 = {1,2,3}
Read-SetApp2 = {3,4}Write-SetApp2 = {2,3,4}
18
Optimization
For a given application, Replicas in Write-Set – Fully Up-to-Date Other Replicas – Periodic Batch Updates
1 2 3
Fully Up-to-date
4PeriodicUpdates
19
When do we adapt? Add when application’s requirements not met
Due to either load spikes or failures Remove when replica not needed Application requirements defined through a
Service Level Agreement (SLA)
20
Resource Manager Feedback Loop
Global Resource Manager
Monitor
Analyze
Request Add/Remove
Execute
21
Resource Manager Feedback Loop
Global Resource Manager
Monitor
Analyze
Request Add/Remove
Execute
When does the feedback loop end?
22
Possible Oscillations Change not seen
immediately Replica addition takes
time Bring replica fully up-to-
date, warm-up memory May trigger more adds Oscillations cause
interference between applications
Global Resource Manager
Monitor
Analyze
Request Add/Remove
Execute
23
Avoiding Oscillations Delay-Awareness
Use load-balance as heuristic for stabilization after replica addition
Removes are conservative Tentative removes
Global Resource Manager
Monitor
Analyze
Request Add/Remove
Execute
24
Cluster Architecture
`
`
Web/Application
Servers
Users
Resource Manager
Auctions Query Scheduler
E-Commerce Query Scheduler
Database Tier
25
Experimental Setup Hardware
AMD Athlon 2600+ running at 2.1 Ghz 512 MB of RAM 60 GB Hard Drive
Software RedHat Fedora Core 2 Linux Apache 1.3.31 with PHP 4.0 MySQL 4.0.16 with InnoDB tables
Benchmarks TPC-W: E-Commerce Retail Store RUBIS: Online Bidding
26
Outline of Results Defined SLA in terms of query latency bound
Query latency < 600 ms Cluster Size
Up to 8 database replicas 10 web/application servers
Experiments Interference between Workloads Adapting to Load Changes Adapting to Faults
27
Disjoint
1 2
28
Partial Overlap
1 2
29
Full Overlap
1 2
30
Interference
00.5
11.5
22.5
33.5
44.5
5
Disjoint PartialOverlap
Full Overlap
Incr
ease
in L
aten
cy
TPCW RUBIS
31
Adaptation to Load Changes
32
Adapting to Load Changes Three schemes
Disjoint – 4/4 Dynamic allocation using Partial overlap Full Overlap – 8/8
33
Disjoint
TPC-W RUBIS
34
Full Overlap
TPC-W RUBIS
35
Partial Overlap
TPC-W RUBIS
36
Adaptation to Faults
37
Adaptation to Faults
38
More Results - In the Paper More complex load scenarios
Including overload Effect of delay-awareness
Avoiding oscillations
39
Conclusion Database replication
Handle more clients Dynamic replica allocation
Handle multiple workloads with different peaks Handle faults
40
Thanks!