Lazy Database Replication with Snapshot Isolation

1
Lazy Database Replication with Snapshot Isolation

• Khuzaima Daudjee
• kdaudjee_at_db.uwaterloo.ca
• Joint work with Kenneth Salem
• David R. Cheriton School of Computer Science

2
Database Replication

• Centralized System

• Replicated System

transactions
transactions
transactions
DB
DB
DB
3
Eager vs. Lazy Replication

• Eager Protocols

• Lazy Protocols

R1
R1
T1
T1
R2
R2
T2
4
Transaction Isolation vs. Performance
Isolation Level
Strong Isolation Low Performance
Weak Isolation High Performance
Performance
5
Snapshot Isolation (SI)
Rx
Wx
Rx
Wx
time
commit(T1)
start(T2)
start(T2)
commit(T2)
? SI allows any earlier database state to be seen
6
Concurrent Transactions Under SI

• Two transactions that write at least one common
  data item
• First-Committer-Wins (FCW) rule

time
Rx Wy
commit(T1)
start(T1)
T2
Wy
Ry Wx
7
Replica Inconsistency Under SI
Site S2
Site S1
time
time
T1
T3
T1
T3
T2
T2
T3 sees commit(T1) and commit(T2) DB state
T3 sees only commit(T1) DB state
8
Replica Consistency a sequential solution
At every replicated site
time
T1
T2
T3
T3 sees commit(T2) and commit(T1) DB state
sequential order does not leverage weaker
isolation level
9
Transaction Inversion
client
T2
T1
Lazy Replicated System
T1 Reserve
T2 Status
T1s update
DB
DB
10
Strong SI
commit(T1)
start(T2)
time
T2
T1
sees latest DB state
11
Strong SI and Scalability
client
T2
T1
Lazy Replicated System
T1 Reserve
T2 Status
12
Strong Session SI
client session A
client session B
time
commit(T1)
start(T3)
commit(T2)
start(T3)
strong session SI imposes constraints between
start and commit operations within a session
13
Lazy Master Architecture
Secondary Sites
Clients
Primary Site
(orders updates)

Update Transactions
Lazy Update Propagation
14
Transaction Relationships

• ? start(T1) lt commit(T2)
• ? commit(T2) lt start(T3)
• start(T1) lt commit(T2) lt start(T3)
• commit(T1) lt commit(T2)

time
T2
T1
T3
commit(T2)
commit(T1)
15
Global SI
Clients
Secondary Site
Primary Site
trans
propagate in timestamp order
schedule updates in order of start and commit ops
T1
16
Enforcing Strong Session SI

• Each secondary database state tracks the primary
  database state
• ? completeness Zhuge et al
• Inversions are possible since secondary DB state
  may lag behind
• Session guarantees need to be enforced by
  ensuring that transaction T2 sees the database
  state installed by T1

17
Algorithm Strong Session SI
Secondary Site
Primary Site
T1
Client
T1
T2
T1s update
block
?
18
Performance Throughput
19
Performance Response Time
20
Summary

• Global SI in lazy replicated systems fully
  leverage concurrency controls to maintain
  consistent replicas
• Strong session SI a useful and practical way to
  avoid transaction inversions in lazy replicated
  database systems
• Architecture and algorithms for global SI, strong
  SI and strong session SI in lazy replicated
  systems