Database replication policies for dynamic content applications Gokul Soundararajan, Cristiana Amza, Ashvin Goel University of Toronto Presented by Ahmed Ataullah Wednesday, November 22 nd 2006

2 The plan Motivation and Introduction Motivation and Introduction Background Background Suggested Technique Suggested Technique Optimization/Feeback ‘loop’ Optimization/Feeback ‘loop’ Summary of Results Summary of Results Discussion Discussion

3 The Problem 3-Tier Framework 3-Tier Framework –Recall: The benefits of partial/full database replication in dynamic content (web) applications –We need to address some issues in the framework as presented in ‘Ganymed’ Problem: Problem: –How many replicas do we allocate? –How do we take care of overload situations while maximizing utilization and minimizing the number of replicas? Solution: Solution: –Dynamically (de)allocate replicas as needed

4 Assumptions Query Load: Query Load: –Write queries are short, sweet and simple –Read queries are complex, costly and more frequent Infrastructure: Infrastructure: –Replica addition is time consuming and ‘expensive’ –Machines are flexible in nature Replica Allocation vs. Replica Mapping Replica Allocation vs. Replica Mapping –Assume an intelligent middleware is present

5 Replica Allocation Full overlapping allocation Full overlapping allocation –All databases replicated across all machines in the cluster Disjoint allocation (no overlapping) Disjoint allocation (no overlapping) (A two database Scenario: Global replica pool not shown) RS = Read Sets, WS=Write Sets : Ratio of WS to RS may be misleading in the above diagram A B

6 Partial Overlapping Allocation Only share write sets. Read sets do not overlap Only share write sets. Read sets do not overlap A B (A two database scenario) RS = Read Sets, WS=Write Sets

7 Dynamic Replication (Eurosys 2006 Slides) Assume a cluster hosts 2 applications Assume a cluster hosts 2 applications –App1 (Red) using 2 machines –App2 (Blue) using 2 machines Assume App1 has a load spike Assume App1 has a load spike

8 Dynamic Replication Choose # of replicas to allocate to App1 Choose # of replicas to allocate to App1 –Say, we adapt by allocating one more replica Then, two options Then, two options –App2 still uses two replicas (overlap replica sets) –App2 loses one replica (disjoint replica sets)

9 Dynamic Replication Choose # of replicas to allocate to App1 Choose # of replicas to allocate to App1 –Say, we adapt by allocating one more replica Then, two options Then, two options –App2 still uses two replicas (overlap replica sets) –App2 loses one replica (disjoint replica sets)

10 Dynamic Replication Choose # of replicas to allocate to App1 Choose # of replicas to allocate to App1 –Say, we adapt by allocating one more replica Then, two options Then, two options –App2 still uses two replicas (overlap replica sets) –App2 loses one replica (disjoint replica sets)

11 Challenges Adding a replica can take time Adding a replica can take time –Bring replica up-to-date –Warm-up memory Can avoid adaptation with fully-overlapped replica sets Can avoid adaptation with fully-overlapped replica sets

12 Challenges However, overlapping applications compete for memory causing interference However, overlapping applications compete for memory causing interference Can avoid interference with disjoint replica sets Can avoid interference with disjoint replica sets

13 Challenges However, overlapping applications compete for memory causing interference However, overlapping applications compete for memory causing interference Can avoid interference with disjoint replica sets Can avoid interference with disjoint replica sets Tradeoff between adaptation delay and interference

14 Our Solution – Partial Overlap Reads of applications sent to disjoint replica sets Reads of applications sent to disjoint replica sets –Avoids interference Read-Set Read-Set –Set of replicas where reads are sent

15 Our Solution – Partial Overlap Writes of apps also sent to overlapping replica sets Writes of apps also sent to overlapping replica sets –Reduces replica addition time Write-Set Write-Set –Set of replicas where writes are sent

16 Optimization For a given application, For a given application, –Replicas in Write-Set – Fully Up-to-Date –Other Replicas – Periodic Batch Updates

17 Secondary Implementation Details Scheduler(s): Scheduler(s): –Separate read-only from read/write queries –One copy serializability is guaranteed Optimization: Optimization: –Scheduler also stores some cached information (queries, write sets etc,) to reduce warm-up/ready time. –Conflict awareness at the scheduler layer

18 Replica Allocation Logic Measure Average Query Latency by solving: WL= (alpha) L + (1 – alpha) WL L is the current query latency and alpha a constant. Note: Responsiveness/stability both depend on alpha Stability Delay ?

19 Results It works…

20 One last interesting issue WL= (alpha) L + (1 – alpha) WL – –L is the current query latency and alpha a constant

21 Discussion Questionable Assumptions Questionable Assumptions –Are write requests really (always) simple? –Scalability beyond 60 replicas (is it an issue?) How closely does this represent a real data center situation? How closely does this represent a real data center situation? –Load contention issues –Overlap assignment –Determination of alpha(s) Actual cost savings vs. Implied cost savings Actual cost savings vs. Implied cost savings –Depends on SLA etc. –Depends on hardware leasing agreements The issue of readiness in secondary replicas The issue of readiness in secondary replicas –What level of ‘warmth’ is good enough for each application. Can some machines be turned off? –What about contention in many databases trying to stay warm. Management concerns Management concerns –Can we truly provide strong guarantees for keeping our end of the SLA promised?