Bayou system Architecture

1
Bayou system Architecture

• Atul Deopujari,
• Umesh Bywar,
• Sandip Matte
• Guide Prof. Sridhar Iyer

2
Introduction

• System to support collaboration among mobile
  users
• Motivation

Officer
Replica laptop
Reconciliation
read/write
Replica OfficePC
Replica PC
Reconciliation
read/write
Secretary
3
Outline of talk

• Bayou Architecture
• Writes in Bayou
• Conflict detection and resolution
• Handling server corruption

4
Bayou Architecture

• Flexible client-server architecture
• Read-any/write-any weakly consistent replication
• Peer-to-peer reconciliation protocol for
  propogation of updates
• Dependency checks on each write
• Merge procedure to resolve conflicts

5
Writes in Bayou

• Nominal update
• make initial updates to the database
• Dependency check
• detect conflict involving the write
• Merge procedure
• resolve any detected conflicts

6
Storage system in Bayou
Ordered Log Of Updates
Database
Servers must agree on the set of writes stored in
their logs
7
Handling of writes at server
Client / application
Update
Server
8
The Anti-Entropy protocol

• Anti-entropy(S,R)
• Get R.V from receiving server R
• now send all write unknown to R
• w first write in S.write-log
• while (w) do
• if R.V(w.server-id) lt w.acceptstamp
• w is new for R
• send-write(R,w)
• w next write in s.write log
• END

9
Conflict Detection and Resolution

• Dependency check precondition for performing
  the update.
• Consists of application-supplied query and its
  expected result.
• If the application of the query to the current
  state of the database does not produce the
  expected result then there is a conflict.
• Merge procedure for resolving the conflict.
• Using some application specific knowledge it
  resolves the conflict and produces a revised
  update to be applied

10
Conflict Detection and resolution(Contd.)

• A typical Bayou write   
• Bayou_write(update, depen_check,mergeproc)
• IF(DB_Eval(depen_check.query)ltgt
• depen_check.expected_re
  sult)
• resolved_update interprete(mergeproc)
• ELSE
• resolved_updateupdate
• DB_Apply(resolved_update)

11
Example Bayou_write

• Bayou_write( update insert, Monday, 130
  p.m.,
• 60 min. Budget Meeting,
• depen_checkquery, SELECT key FROM Meetings
  WHERE
• day Monday AND start lt 230 p.m. AND end gt
  130 p.m,
• Mergeproc ALTERNATES(Monday, 300 p.m.),
• (Tuesday,130 p.m.)
• Run depen_check for each entry in ALTERNATES
• and return the one which satisfies the check as
• resolved_update
• )
• IF (resolved_update) //no alternate is
  selected
• resolved_updateinsert, ErrorLog, Monday, 130
  p.m., 60 min, Budget Meeting
• return resolved_update

12
Write Stability

• A write log is maintained at each server to store
  the writes performed at the server.
• A write is said to be stable when its position
  remains fixed in the write log.
• How to decide whether a write is stable?
• Through communication between each pair of
  servers
• Bayou uses primary commit scheme

13
Primary Commit Protocol

• There is a replica (server) which is called as
  primary. When the primary receives a write it
  assigns a Commit Sequence Number (CSN) and marks
  the write as commited.
• Whenever the primary communicates with other
  server (receiver) it checks the receivers logs
  and forwards the writes missing at the receiver.

14
Primary Commit Protocol
Replica 1
Primary replica
Assign CSN
Replica 2
Propagate this committed write
15
Propogation of committed writes

• Anti-entropy (S, R)
• Get R.V and R.CSN from receiving server R
• first send all the committed writes that R does
  not know
• If R.CSN lt S.CSN then
• w first committed write that R does not know
  about
• While (w) do
• If w.accept-stamp lt R.V(w.server-id) then
• R has the write but does not know it is
  committed
• Send CommitNotification
• Else
• Sendwrite(R,w)
• End
• End
• w first tentative write
• now send all the tentative writes
• While (w) do
• If R.V(w.server-id) lt w.accept-stamp then
• Sendwrite (R,w) w next write in S.write log
• End

16
Write log management

• Writes cannot exist in the write log forever.
• Writes can be discarded from the log once that
  write propagates to all other replicas.
• But a replica disconnected for a long time can
  cause the other replicas to grow indefinitely.
• Hence, in Bayou, each replica decides when to
  purge an entry in the write log

17
Write Log truncation

• Any server can truncate a prefix of its write log
  at certain intervals of time.
• Since this will create problems during
  reconciliation, another version vector (alongwith
  the CSNs) is maintained for the purged entries.
• During the anti-entropy process, the sender
  checks if it has purged any write which is not
  known to the receiver.
• If so the whole database at the server has to be
  transferred to the receiver.

18
Dealing with server corruption

• Security hazards
• what corrupt servers can do
• Countermeasures

19
Security hazards

• Portable machines are more susceptible to attacks
• Corrupt clients cannot be trusted
• Servers can be corrupt
• Standard security techniques cannot be used
  because of above hazards

20
What corrupt servers can do

• A server could fabricate new writes or modify
  existing writes
• An intermediate server could change meta-data of
  writes accepted by other servers
• A server could create incorrect meta-data for
  writes accepted by other servers
• A server could return incorrect answers to client
  read requests

21
Online rejection of some server misbehavior
client
Accepting server
Intermediate server
22
Auditing accepting server
client
Accepting server
23
Detection of corrupt server
24
References

• The Bayou Architecture Support for data sharing
  among mobile users
• -A. Demers, K. Petersen, et.al.
• Flexible update propagation for weakly consistent
  replication
• -K. Petersen, M. Spreitzer, et.al.
• The case for non-transparent replication
  examples from Bayou
• -D. Terry, K. Petersen, et.al.
• Managing update conflicts in Bayou A weakly
  connected replicated storage system
• -D. Terry, M. Theimer, et.al.
• Dealing with server corruption in weakly
  consistent, replicated data systems.
• - M. Spreitzer, M. Theimer, et.al.